[clue-tech] port access protocol restriction?

[Jim Ockers]

Hi David,

> Jim Ockers wrote:
> > Does anyone know how, using Linux of course, to restrict traffic
> > that passes through a Linux NAT router/firewall by protocol?
> 
> You mean filter at layer 7, or application protocol (as opposed to IP 
> protocol number, for example).  If you really need that this might be a 
> good place to start:
> 
> http://l7-filter.sourceforge.net/L7-HOWTO-Netfilter

Actually that's exactly what I was looking for, thanks!  We can allow
only IMAP on port 143 and reject other protocols like HTTP, using their
code.

> What's your security policy (and why)?  I ask because without a "these 
> users can't be allowed to do this because..." type statement, security 
> like this gets stupid really quickly.  Seriously.  I use an app that 
> requires me to use 5 passwords to get to, and I run citrix to run citrix 
> to run citrix to run the app.  I'm allowed access to anything I need on 
> all the networks involved, but bad policy says that I can only go one 
> hop at a time.  Hmm... I should probably rattle my cup on the bars over 
> that.

Well we're evil you know.

Just kidding.  The business request is to "restrict internet access" to
"e-mail only" unless the customer is paying us for internet access.  This
is for expensive satellite links and it's even more expensive for us if
the satellite users are browsing the web or doing other high-bandwidth 
activity.  We are trying to make sure that our expensive satellite 
connections are not losing us money because people are getting web access
in spite of the port restrictions.

The L7 filter you describe would help us make sure that if we allow e-mail
access only (by contract), they can only do e-mail, and they can't set up
a proxy server or special web site.  If they want to pay extra for full 
internet access, we're happy to accomodate of course.

> 'Course maybe you have to write your own IMAP proxy.  Oh, of course not:
> 
> http://www.imapproxy.org/
> 
> But maybe you have to add support for your policies.  (And if you're 
> trying to use it as a security app when it wasn't designed that way, 
> better audit the code.)

Thanks for the tip Dave - this list is great.

Regards,
Jim

-- 
Jim Ockers, P.Eng. (ockers at ockers.net)
Contact info: please see http://www.ockers.net/