[ previous ] [ next ] [ threads ]
 
 From:  Peter Curran <peter at closeconsultants dot com>
 To:  "Bart Simpson" <easytoker at fastmail dot fm>, m0n0wall at lists dot m0n0 dot ch
 Cc:  m0n0wall dash dev at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall-dev] Features -suggestions-design
 Date:  Thu, 1 Jul 2004 14:58:23 +0100
On Wednesday 30 June 2004 22:16, Bart Simpson wrote:
> 1. application level gateway (Socks5) with authentication, granular
> controls as in time,date etc... Today's firewalls need more then just
> packet
> filtering. Most use a combo of application/packet-filter
>

Interesting observation.  Socks is an example of a circuit or transport 
gateway.  Jolly useful for authentication, but no better than a packet filter 
when it comes down to looking at the actual content of an application session 
(to do intelligent URL filtering, filter active content, check viruses, etc).

It would be useful to have time based rules, but these could probably be done 
using  packet filters as easily as a CLG such as Socks.

If you go down the Socks route, then there is a performance penalty to pay.  
If you go for the functionality of application proxies, and start doing some 
content checking/filtering then there is a severe performance penalty.  If 
the platform is big and meaty then this probably doesn't matter.  My platform 
is a Soekris Net4501 and I think it will barf if you feed it a proxy-based 
environment.  A Net4801 may be bettter.

> 2. More of a unified approach to authentication/identification. Most of
> us are moving away from radius and using LDAP as the authentication
> method as one server can auth./ident and provide directory access for
> the company. OpenLDAP and Netscape would be a great choice for
> compatibility engines.  This can be through a encrypted tunnel.
>

Interesting.  m0n0 is really aimed at the SOHO or small business market.  I 
don't think they are deploying LDAP any time soon.

I think you could just as easily argue for the introduction of kerberos, given 
that is now widely used.

However, support for a wider range of authentication services could be useful, 
so I see your point.

> 3. Real time data, especially for VPN tunnels. Who are they..user/Group,
> where are they coming from, where are they going, what time did they
> connect/how long have they been connected and a way to view the raw data
> after the encrypted packets are unwrapped. Nortel contivity switch does
> a great job of this as well as checkpoint NG. The ability to disconnect
> a vpn tunnel manually or via a timer....user Greg or group greg can only
> stay connected for 30mins at a time, or vpn tunnels from ip. x.x.x.x or
> from x.x.x.x to x.x.x.x can stay connected for 1 hr.
>

Yes - this sounds a good idea.  I would add similar functionality to the 
captive portal as well.

> 4. Highly redundant (Clusters) with load balancing and full
> fail over...even vpn tunnels. Our checkpoint can do this and its very
> neat and reduced customer calls by 60%. If a user is vpn'ed into server
> A and server A fails then Server B,C,D... will pick up the tunnel
> without the user having to dial back in or any user intervention for
> that matter. You have to sync the state tables amongst the clusters.
> The latter is done on the private rail or can be done via serial.
> OpenBSD PF has a module for this,,pfsync. Perhaps the HUT project could
> help with this on the freebsd code. The ability to add or remove a node
> from the gateway
> cluster via admin interface. Rainfinity and server iron does a great job
> of this.
> Hut project ....http://www.bsdshell.net/
>

Sounds like OpenBSD with pfsync and carp would be useful.

> 5. Integral and performance Monitoring / Notification. The MIDAS project
> would be a nice incorporation.
> http://midas-nms.sourceforge.net/
>
> 6. One does not always want data acquisition on a firewall, however
> there
> are certain instances where it is very rewarding. It's nice to have
> real time info. on those dam scripts kiddies. Perhaps a prelude
> solution. It would be nice to see the real time data via the admin
> interface but
> storing that info on a firewall is outright ludicrous. I would push
> that data to a storage center such as a prelude console for data
> forensics.
>
> 7. A user interface via.. application instead of WEB. Checkpoint slays
> the competition in this. As a network security engineer i can't
> understand why anyone wants a web interface...yes its easy but at the
> cost of security...even on the internal rail.  Also writing a
> application GUI
>  interface would make real time data acquisition feasible instead of
>  doing html updates ever X
> seconds. Boa-constructor might be a good RAID for this and python's
> power would shine. The Gui could use sshd as its underlying interface so
> a ui daemon interface
> would not have to be reinvented.
>

This sounds similar to the 'interesting exchange of views' in a recent 
soekris-tech thread.  Could you explain why running a gui via https is less 
secure than tunneling an X session over SSH, or using a protocol like 
checkpoint's (which I think is just using secure sockets as well).??

Lots of 'network security engineers' are popping up all over with similar 
comments.  Well, I am a network security engineer with 10+ years experience 
not just of deploying firewalls, but also building them.  I quite like the 
m0n0 GUI and have no issues over security.  What I would add, however, is 
client-side authentication so that I can use a cert rather than name/pass for 
access.

> 8. Switch the core to OpenBSD. Its a firewall right? OpenBSD just has
> better code audits and they are the ones that own the frontier when it
> comes to security and reliability. Just makes since when you building a
> firewall to use the best options. I would at least dump IPF for PF as PF
> is just amazing with its flexibility, scalability, ability and onslaught
> of perfection. We reduced our cost by 35% by just using PF. Our traffic
> ambiguous errors are over. We have never failed a audit using open, and
> as a admin
> / engineer you sleep better @ night knowing that your gates are
> protected by the best
> of the best. Personally i think freebsd does a better job in situations
> like http servers
> and i use them as such.  It's rather simple semantics, use the best in
> the field you are working on and open is the leader in security.  IMHO!
>
Agreed

Peter




-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.