Lewis Edwards wrote:
> First, let me thank you for an excellent product and all the work you put
> into maintaining it.
> 
> I have a web server in a DMZ with only port 80 open to the world.  Right
> now, someone can telnet to port 80 and poke around with my Apache
> installation. Given the right person and the wrong installation, this can
> cause a lot of problems.  If m0n0wall had stateful (or dynamic) packet
> filtering then port 80 would only accept HTTP connections and the sysadmin
> could sleep (a little) easier.
> 
> Naturally, I have no idea how to implement this myself (hence my use of
> m0n0wall and my e-mail to this list) but I think it would be a useful topic
> for future development.  Of course, if such functionality already exists and
> I've completely overlooked it, I'd appreciate a push in the right direction.

Sounds like you want a proxy level firewall that analyzes the traffic 
and makes decisions based on the protocol itself.  You tend to get into 
some VERY expensive solutions when you need to go that far.  They can 
analyze SMTP, HTTP, SQL, rtsp, ping, etc and can even deny a connection 
to an SMTP server if characters are coming in one at a time(like what 
would happen if someone is telneting to the smtp port and typing). 
Nothing against m0n0wall or any other open source firewall solution but 
I have not seen any open source firewalls that even come close to 
reaching that kind of level of inspection/control and don't expect to 
see it anytime soon.

 From what I have seen in the past, stateful firewalls usually meant 
that they could keep track of packet level states so that the low level 
rules can allow an incoming connection and then have another rule that 
can match connections already established.  This way you did not need to 
write rules for both directions for an outgoing connection.  I am sure 
vendors are starting to blur that definition though.

 From my experiences proxy level firewalls have many pro's and con's 
though.  They can make sure as best they can that http traffic conforms 
to the standards(header sizes, etc) but the downside is that they 
conform to the standards at the time that they were developed.  As new 
additions are created to the standards they tend to lag behind so you 
end up sometimes not being able to use new additions to http, smtp, sql, 
etc for quite some time.

When WEBDAV came out it took some proxy level firewalls a long time to 
implement that so anyone using WEBDAV extensions to http would not get 
through the firewall.

Then again TCP level issues have cropped up in the past too...
When ECN came out some vendors enabled that by default(redhat, etc). 
Some of the firewalls that analyze the TCP headers for non-conformance 
to standards did not know about the ECN TCP option so it thought they 
were suspect and blocked them.