Shaggy wrote: - packet

hosted — Thu, 21 Oct 2010 09:58:46 +0000

Shaggy wrote:

- packet filters on all servers - publicly exposed and not. The filter drops all requests that aren't expected... i.e.
allow all to/from port 80/443 if you're running a web service (on standard ports)
allow all to/from port 25/465/587 if you're going to handle incoming mail
allow your-workstation to/from port 5432 for postgres connects.
etc.

forgot 3306 for mysql connection

JeevesBond

pr0gr4mm3r — Thu, 15 Jul 2010 01:08:00 +0000

JeevesBond wrote:

Certificates for SSH connections have some advantages over passwords: the certificates get installed on a machine and you never need to type your password again; certain attacks on your server (like brute-forcing your SSH password) become a lot harder if you're using certificates. There are the obvious disadvantages of the key being in a file though (someone could get the file off your computer, you might leave it on a machine by accident and such).

When I have password authentication enabled, I get brute force warnings all day (fail2ban is good, BTW). I would highly recommend disabling password authentication for SSH and use public/private keys instead. If you are concerned by somebody getting a hold of your private keys, you can put a passphrase on it, or you can hard-code your IP address in the authorized_hosts file on the server, so if would only accept the private key from your location (not a good idea if your IP address changes often).

JeevesBond wrote:

11. Maybe change SSH from port 22 to 22222 for security reasons.
This is security through obscurity but probably won't hurt, just don't rely on it to actually stop a determined cracker.

Yes, but it stops all the bots. When I have SSH on port 22 with password auth enabled, I get those fail2ban warnings all day - probably all from automated bots or something. Either switching the ports of disabling password auth (see above) stops those attempts cold.

A few more things to add from

Shaggy — Tue, 13 Jul 2010 19:42:45 +0000

A few more things to add from experience...
- Keep up to date on the system patches.
- multi factor authentication - or at least SSH keys rather than passwords...
- limit su / sudo to users you know to keep authentication measures strong...
- I always preferred to log everything remotely (or at the very least syslog and access logs).
- Run Bind sandboxed - at least in a chroot
- Don't allow forwarded queries - i.e. don't answer queries for domains you aren't authoritative for
- If you are going to allow the bind service be accessible to the outside world (which you would need to do if you are going to run your own authoritative servers) keep a keen eye on the security bulletins. Bind9 is/was miles ahead of Bind8 in terms of security - but it's still one of those services that is often attacked.

- I did end up running SSH on a non-standard port, mostly because the number of attempts to get in was consuming far too many resources - so I just dropped all traffic coming in on port 22 and 'they' seemed to move on. I think a number of other people also see this problem. All this protects you from are the super lazy.

With these, if you do make a mistake and start a service you didn't mean to, you still appear covered to the outside world at least. It's also interesting to keep statistics of what you drop. If you have something someone wants, you'll usually be able to predict security bulletins based on the increase in probes to the different blocked ports.

- anyone caught scanning ports was dropped in the drop from all list, cleared out weekly.

- Intrusion detection is also excellent to have - Trying to detect intrusions manually just isn't sustainable.

- None of this covers hints on securing the web services you will be offering via apache httpd or tomcat. Running out of date popular blog / discussion board software is usually an open invitation...

Haven't got the time for a

jeevesbond — Tue, 13 Jul 2010 04:14:00 +0000

Haven't got the time for a full security review, but two things off the top of my head:

Use a system like fail2ban, it's not a substitute for good security policies but will stop attackers constantly polling your server for vulnerabilities.
Certificates for SSH connections have some advantages over passwords: the certificates get installed on a machine and you never need to type your password again; certain attacks on your server (like brute-forcing your SSH password) become a lot harder if you're using certificates. There are the obvious disadvantages of the key being in a file though (someone could get the file off your computer, you might leave it on a machine by accident and such).

5. install Bind9 and utils - By default the cache is installed and active?

Not sure I understand the question, if you mean 'does the DNS server remember addresses it's looked up' then the answer is yes.

If you have a domain registrar that does DNS then setting up a DNS server probably won't be required.

6. I need to set up my primary DNS server and configure my nameserver addresses / CNAME records to point to my IP address?

See above, you may not need to.

7. I could setup an additional secondry DNS server using my second IP address?

Yes. Not sure why you'd need to though, if the DNS is down the most likely cause is that the whole server has died, in that case having a secondary DNS won't help you.

I would save doing this for when/if you're setting up a dedicated DNS server in the future.

10. I need to activate the pre-installed firewall and only allow access on port 80 (http) and port 22 (SSH)?

How would anyone query your DNS server?

11. Maybe change SSH from port 22 to 22222 for security reasons.

This is security through obscurity but probably won't hurt, just don't rely on it to actually stop a determined cracker.

Hope this helps!