I've setup a port knocking scheme to protect port 22 using iptable rules. On top of that I've setup some "honey pot" rules to disable port knocking for the client for several minutes if they hit common ports that are not used (port 21 for example) or ports around the knocking sequence. This seems to work well (I believe it's a better option than changing the port to something obscure). For SSHD password logins are disabled anyway - an encrypted private/public key combo is required.
On this page there is a "drip pan" scheme that if unused ports are hit the client cannot communicate with anything (even open ports) for 60 seconds. My biggest concern is "--hitcount 3" seems to be triggered by any simple request to a single port.
So my question is, what do you think about this kind of setup? Is the "drip pan" too much on a web server, or just right? Other than keeping a drop in-out policy and only opening what is needed, do you guys have any other firewall security advice?
Edit: I'm using CentOS 5.7. We're assuming as "secure as possible within reason". A server would have to pass PCI/SAS compliances (and other similar standards). Focus would be the firewall, not necessarily vulnerabilities with individual services that could come be discovered (that's another topic). Anything that I'm missing related to the firewall or anything on the outside. Want to make it as difficult as possible for an attacker to gain access.
Completely subjective opinion here, but I've never been that interested in port-knocking.
Feels a bit like a kluge and I've always worried that there'll be that time when it flat out stops working as expected or I discover an edge case that locks me out of my system.
I find with password authentication disabled and SSH keypairs only, I rarely see the same bot try the port more than a few times. It's just not practical when there's so many other hosts out there to try and own. Until people stop permitting root SSH logins and give up on password authentication altogether, the low-hanging fruit is still there and ripe for the picking for the cyber criminals.
At the firewall, I do usually drop connections to TCP 22 except from a few locations as I'm rarely anywhere where I'd need to be able to access a box directly (I'll just VPN to a location that can).
I'm assuming this is a Web server, yes? Invest some time into understanding the requirements of your Web applications. Your typical stateful firewall is next to useless to defend against attacks that happen over port 80 like SQL injection, XSS, and the like.
I'd also setup some robust logging (log all your SQL queries if you're running a database; setup a remote syslog for your firewall logs, web server logs, auth.log, system logs, webserver logs, etc.)
I would setup a proxy server on another host (if you can) and drop outbound everything from your Web server at the firewall. When/if your box gets owned, the attacker won't be able to make a direct TCP/UDP connection out on the Internet (usually one of the first things an attacker will want to do is get a shell to your system) and if you're alerting is in place, you'll know right away.
The only only outgoing HTTP traffic that should be permitted should exit out via the proxy server and you should (for a server at least) have a whitelist of domains that are ok (like package management repos).
Doing that will go a long way; assume you will get owned and plan and defend accordingly.