1

I am about to deploy a web application (in a couple months) with the following set-up (perhaps anyways):

Ubuntu Lucid Lynx with:

  1. IP Tables firewall (white-list style with only 3 ports open)
  2. Custom SSH port (like 31847 or something)
  3. No "root" SSH access
  4. Long, random username (not just "admin" or something) with a long password (65 chars)
  5. PostgreSQL which only listens to localhost
  6. 256 bit SSL Cert
  7. Reverse proxy from NGINX to my application server (UWSGI)
  8. Assume that my colo is secure (Physical access isn't my concern for the time being)
  9. Application-level security (SQL injection, XSS, Directory Traversal, CSRF, etc)
  10. Perhaps IP masquerading (but I don't really understand this yet)

Does this sound like a secure setup? I hear about people's web apps getting hacked all the time, and part of me thinks, "maybe they're just neglecting something", but the other part of me thinks, "maybe there's nothing you can do to protect your server, and those things are just measures to make it a little harder for script kiddies to get in". If I told you all of this, gave you my IP address, and told you what ports were available, would it be possible for you to get in (assuming you have a penetration testing tool), or is this really protected well.

4 Answers 4

2
  1. If the 3 ports are 80/443/22, then you're good ;)
  2. That doesn't really help, as SSH server identifies itself upon 'knocking' so tools like NMap will tell you what really runs on that high port anyway. Security-by-obscurity is fairly worthless.
  3. If you mean no remote root login then yes, it helps. If you mean you have another account with UID of 0, then it's less good. Have another non-priv account that's used to connect, then su/sudo to actual root only when needed.
  4. Long passwords are impossible to remember, so you're gonna store it somewhere. At that point might as well disable password logins altogether and go certificate only. This BTW, solves 99% of all SSH knocking attempts.
  5. If your DB listens locally, why listen on a network socket at all? Why not go through a filesystem socket? Not only it's more secure (nothing listening) but if you're connecting from a local source anyway, it's actually faster (no networking protocols overhead)
  6. SSL certs are often misconfigured. Make sure domains and dates are set up correctly.
  7. Even if physical security isn't much of a concern, you still might prevent your own 'brainfarts' like reboot upon 'ctrl-alt-del', and automatic locking of a logged in, idle terminal.
2
  • 1
    I was about to answer with something very similar. And to add use a file system checker like osiris. Use a VPN to connect to the ssh server on the box: openvpn is easy enough to setup. 100% agreed: Security by obscurity is NO security.
    – Leo
    Oct 5, 2010 at 18:25
  • thanks. The 3 ports were 80/443/xxxxx but after the lectures about "security through obscurity" I think I'll stick with 80/443/22 and RSA auth only.
    – orokusaki
    Oct 5, 2010 at 19:41
1

www.insecure.org is a great place to start looking for vulnerability testing software, and of course google.

Off the top of my head a few tools come to mind... - nmap - metasploit - saint - burp suite - lan guard

One this to remember when securing anything connected to the web... It can never be fully secured until it's unplugged from the internet. It sounds like you are taking all of the appropriate steps to keep the script kiddies out, and probably most automagic h4ck tools. But remember, with the right motivation/talent/time there's nothing you can do to protect yourself from "unauthorized access".

1

That's a great start, but remember that your precautions need to be re-evaluated as often as they're tested.

Consider DenyHosts, SentryTools, and/or whichever other monitoring tools strike your fancy.

1

I'd test with Nessus, and if you're feeling adventurous then try Nikto.

Also, get an IDS in front of it, like Snort.

You may want to alert your ISP that you are doing vulnerability testing, depending on your setup.

Looks like you are on the right track.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .