This may be kind of a stupid question, but here goes:
Say I'm running a FreeBSD webserver (w/apache). I've managed to close ALL open ports (including SSH/telnet and portmapper), excepting '80' that apache is listening on. A netstat -a shows me nothing open.
Discounting DoS/DDoS or holes in apache, is there really a reason to run a firewall on a box like this? If nothing is listening on any ports but 80, what function will a firewall perform (like ipf (pf now I guess))? Some super-sekrit port-opening prevention?
The TCP/IP stack isn't really vulnerable to say, the Ping of Death or something like, and there are no sessions to hijack (w/this particular website), so I'm at a loss as to what a firewall would do. Or am I just beating a dead horse, so to speak?

Well, the best installation would be to have a seperate firewall box upstream from your server (cool graphics to follow

(internet) =====> (firewall) -------> (webserver)

If you don't have ports open, you can't attack them. That's as simple as it is. But it may be good just to keep people from scanning and probing the box.

Also, you can set it up to help protect from becoming the man in the middle of an attack; i.e. Someone magically roots your box through an insecure CGI script, manages to open a remote shell on a high port. Now if you had a firewall, they still couldn't get in to use the shell they uploaded for you. But also, say they begin using your box to jump to others - not good...

If you have one box (a webserver) behind a firewall and you are already managing the webserver well, then a firewall is still necessary to block individual IP addresses that may be attacking open ports.

However, if you can add filtering rules on the webserver using firewall-like filtering software AND you have plenty of CPU and memory to handle the processing load, then a firewall is not necessary.

Having an extra and unnecessary firewall in place that is not well configured or managed is more dangerous than having no firewall when the firewall is just protecting one server.

I tend to disagree with LivinFree and think that firewalls are good, but not necessary 'the best' solution. The best solution depends on your configuration, your time, how much time you want to spend managing servers, etc.

If you have 100 or 1000 servers to manage then a firewall is much more critical than if you have to manage a single web server. And, as stated, if the web server has plenty of horse power, has IP filtering software at the kernel level, and is well managed, a firewall is an extra expense that adds minimal value for a potential large management expense.

Don't be fooled by buzzwords and seduced by technology, good process and well thought out architectures bring more security than adding more gizmos.

This is/was a purely theory-based question. The server farms I manage get both treatments (invidual 'hardening', and a cluster of high performance firewalls) because a) no single solution will ever be totally secure, and b) not all attacks come from filtered IPs. This is common knowledge. I guess what my question should have been is this:
Excluding any form of packet based denial of service (wherein a target's service is denied due to an overwhelming amount of 'bad' traffic), can a unix system be attacked using TCP/IP, if no programs are listening? I guess a case in point would be the old Ping of Death, where nothing had to be listening on the host (besides a conformant TCP stack), but a specially malformed ICMP echo request would crash the system. I may be groping in the dark for something that has no real answer, or no 'easy' answer, but I have just been wondering on what avenues an exposed system is open to attack.
If no daemons or other programs are listening on a given port, does the OS and it's TCP stack just ignore inbound packets destined for that port? Is there a special 'dead packet zone'? I could probably look this up in the source, but I'm not exactly a hotshot C coder (in fact, I might go as far as to say I suck worse than a 1st year CS student .

Good question.

If I'm not mistaken, unless specifically denied or not configured in the kernel (ICMP) an IP interface properly configured with ifconfig will respond to ICMP ECHO_REQUESTS independent of sockets bound to listening processes.

Having said that, it is not difficult to install kernel level filtering software on most of our favorite UNIX systems to stop this 'normal' behavior. "Deny ICMP filters" are fairly common practice these days.

I see Neo's point here in what 'the best' config would be. I guess I just like seperating each service in it's own area - For example, my ideal config for most (but not all) situations would be to have a seperate fileserver, web server, firewall, etc. That way, you could perform mainenance on your webserver without downing your whole network. But, then again, if the only external contact you've got is the webserver, it wouldn't make any difference - either it's up, or it's down.

I guess the question about attacking a box without any open ports could be a very tricky one. The best thing I can think of is a simple DoS. Packet the heck out of the machine, and if nothing else, it at least absorbs your bandwidth. You really can't do that much about it, except try to block it as far upstream as possible. But an "exploit" should never work against a non-listening port. If no process is spawned upon connection (like in inetd), and no process is already listening, what exactly could you possibly attack?

Thanks...that was exactly what i was looking for
I figured that if there was no prog attached, or no socket listening, that nothing would be able to happen (excepting Neo's answer). I was just making sure the kernel didn't carry any 'built-in' functionality, as far as answering calls on non-open ports were concerned. And apparently, the answer is, excepting ICMP, no. Thanks Guys!