up vote 3 down vote favorite
1
share [g+] share [fb]

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.

link|improve this question
100% accept rate
2  
'Good firewall security advice' will depend entirely on what you're trying to protect, what your threat environment is and how much resource you have. If you expand on any of these, people might be able to give specific answers to help solve your specific problem. – growse Sep 23 '11 at 22:44
Good advice, I'll add to the question. – Luke Sep 23 '11 at 22:45
feedback

1 Answer

up vote 7 down vote accepted

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.

link|improve this answer
That's a lot of good advice. Never thought of using a proxy as a security barrier before. If the web application had to make outgoing requests, should it do it directly or through the proxy? What about protecting user input sent through the proxy server, like if they managed to gain access to the proxy? – Luke Sep 23 '11 at 23:04
I would funnel all outbound TCP connections either through an HTTP proxy or a socks proxy (depending on what you're doing, of course). You can harden your proxy alot better than you can harden a Web application server because a) you don't have to expose it to the outside b) an attacker is 9 times out of 10 going to assume that he/she can establish a direct outbound connection and once that gets denied by your firewall, you can react accordingly to thwart the attack (that's a whole other chapter). – gravyface Sep 23 '11 at 23:08
if they by some chance discovered that there was a proxy before you were alerted and attempted to use it, your Squid alerting would tell you that somebody was trying to access a forbidden domain not in your whitelist. – gravyface Sep 23 '11 at 23:09
When you say firewall, are you talking about more than just iptables? Do you mean the application server is physically connected and routed through the proxy server? An example of an outbound connection would be to Authorize.net's API through HTTPS. But we also have a user-defined notification service through HTTP (so white-lists may be difficult). I may have to move the notification service to a different server though. – Luke Sep 23 '11 at 23:17
Yes, a separate, physical firewall. Well worth the investment. – gravyface Sep 24 '11 at 2:33
feedback

Your Answer

 
or
required, but never shown
discard

Not the answer you're looking for? Browse other questions tagged or ask your own question.