[ previous ] [ next ] [ threads ]
 
 From:  "Bart Simpson" <easytoker at fastmail dot fm>
 To:  "Peter Curran" <peter at closeconsultants dot com>, 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, 01 Jul 2004 14:37:42 -0700
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).

**Actually circuit level gateways (can provide) more content control
over the transport of the datagram packet to a degree. I do agree with
you that most things can be achieved with a packet filter.  Yes the
authentication of a session is very, very useful.  One of the biggest
boons of having a application level gateway is that a user or groups can
use applications via socks, if permitted by the admin :)...good old
auth., however the simplistic nature is rather the sticking point for
me. Instead of having to create special rules / filters, mappings (port
forwarding) etc... on the firewall for every darn app management / users
need one can simply just sockify the app. The latter makes for a much
cleaner firewall rule set instead of a copious cluster F**** of a bunch
of rules. Its just too easy to forgot to remove not needed rules that
were setup for temp access. Sockify it, give the user permission to use
the socks daemon and forget about it. The only clean up that would be
needed in situations were temp access is granted is to have the user
removed from the granted access auth list...and this cold be
automatically done as in date,time etc...  Turnover ration in companies
makes this nice too. Just remove the user..done.! Also a socks daemon
can provide monitoring and reporting of activity on a broader scope than
that of most packet filters. I think there is a socks daemon on SF that
is modular and can take plugins. It should be feasible for a programmer
to develop a plugin that uses the sock daemons ability to look at the
datagram on a high level and provide content screening as in virus
detection etc... IMHO. 


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. 

** I Never consider security to be a penalty even if the penalty is the
cost of performance. IMHO
Computers are relatively affordable these days. In my theocracy i would
rather add another node to the the cluster or a bigger beefer node then
sacrifice my data. I would have to say that personally i really don't
recognize a big difference in resources running a socks server as
opposed to a packet filter. Where i do recognize a difference is when a
packet filter has hundreds of filters or even thousands to
process....yes even with grouping. A socks server as mentioned above
will help keep all those unneeded rules out therefore helping to
maintain a minimal and well groomed filter list. Sometimes it seems
admins go out of there way to make the whole security process cumbersome
and convoluted.  A well defined and groomed list is easy to make
policy's with instead of make policies around.  Most of the time the
performance hit is the socks daemon, or any "networking" daemon,
handling memory allocation improperly or pissing in the mbuf/nbuf pool.
Openbsd manages the latter better than any other .....IMHO and keeps
those renegade daemons from exploiting pointers. A properly written
socks daemon does not have these problems.  Anyway...we had to add
another node to our cluster as the company is growing and performance
was showing to take a slight hit......a point of good graphs and
monitoring..... after adding a few hundred users via DS3 WAN connection.
I built the new server for around $350, AMD athlon 2 gighz / 256 ddr
2100, including the 128 mg CF where openbsd runs from. $350 for added
performance is nothing...IMHO Most  mom and pop shops will never have
any issues.  I also have openbsd with PF and a socks daemon running on a
net4501 providing protection and contivity for 150 nodes with about 60
concurrent connections via...T1 without any issues.   Again just my
experiences!




> 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.

** actually you would be surprised how many small business today want
ldap. Its cheaper to maintain and more flexible. Also since one server/s
can provide auth, directory info etc... is economical ..less power,,
space etc. We have quite a few small business that are asking us to
transfer them from radius to ldap and since openldap is free the dont
fret over proprietary code that drans there wallet with licenses. 
Actually ,IMHO, kerberos is a cluster F****  Never really like it. 
 

> 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. 

* yea the whole system in general would shine with accountability. 
Thats the only thing that saved our arse when the code red worm hit.  We
had the gates locked up but remote employees were vpn'ed in with
infected machines and we were able to identify the user-to-ip etc.. and
kill the sessions and lock the user account out until their machine was
fixed.

> 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. 

* PF is so bad ass and its future bright. There needs to be some work in
the high availability world for it, probably through modules, but the
foundation is there instead of an afterthought like the rest. 

> 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.



**Http was designed for what and when?  To render and display txt... and
it was designed in the beginning stages of the NET before the need of
security was foreseen.  Today it is a crucial and utterly invaluable to
the survival of the nodes/networks attached to it.  As an engineer the
design for me has to start with intent...the foundation.  You know the
saying, dont build your house in the sand but rather a concrete
foundation. So, by design http is a security flaw in todays world and no
amount of afterbirth patches such as https will properly address it. You
have to have the foundation first... again Openbsd mentality. I hate our
engineers that always address everything with a patch/layer instead of
doing it right the first time by design.  Secondly..anyone with a web
browser or http/s protocol tool can launch attacks with the greatest of
ease. Even if you have the internal rail restricted it provides a simple
way of intrusion that could be eliminated. Some say i am a little
paranoid but then again i am home on the weekends instead of in the data
center trying to figure out who hacked me or why the system is crashing.
:) Having a client that is handed out to only a few makes it quite
feasibly inapproachable from the masses.  

Http/s updates makes great overhead and quite devastating to real time
data monitoring. We had one of the first nokia boxes that used this
method.  It was fine until the box was under some real pressure with
tunnels, connections et... SSH as a protocol is designed for this and
has better reliability over shitty networks.  The most important factor
and the reason i was looking at open ssh, it's already written and ...by
the best security folks, is that it was DESIGNED from ground up with the
intent of SECURTY and not a afterthought patch. As an Security engineer
don't think with the mindset of why is it less secure , the word less
says its insecure..right?,  Think with the  mindset of potential. Our
job is to eliminate all foreseeable possibilities to the best of our
knowledge and we know http is not a security protocol *by default and
design* like the ssh protocol. Its a firewall right? Why not make a
security device as secure as possible? Also sshd mitigates the damage in
case an exploit was found as it runs with priv separation and is
designed to run in a (jail) natively..without hacks or patches.  Count
the past..maybe even present http/s exploits , now the openssh exploits.
Does not the latter just make sense? I am not a duck tape kind of
person, if i am going to do something i will try my best to do it right.

Tunneling X over ssh? Your are not tunneling X at all.  The X protocol
is nasty, bloated and insecure. Your communicating pure ssh. The GUI is
in this case a ssh client , nothing else, and communicates using the ssh
protocol to communicate to the sshd daemon on the firewall. The only
thing X would be responsible for is simply displaying and managing the
Client GUI ...if on unix host as i wanted to write it with WX-Python for
cross platform compatibility but thats for a programmer to evaluate as i
don't have a coder mentality. And with ssh you can have that cert method
you want :) 


> 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

*YEP   

Peter

Nice conversing with you peter, have a gret day.











On Thu, 1 Jul 2004 14:58:23 +0100, "Peter Curran"
<peter at closeconsultants dot com> said:
> 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.
>