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.