setting up a ubuntu 10 web server
I have just started renting my first VPS.
I ordered it installed with Ubuntu 10. I did not opt to have any plesk license or any other server management system like Webmin to be installed either simply because I want to learn how it is all put together.
My questions are really, am I doing things correctly? This what I have done so far:
- install apache2
- create a new SSH user
- Stop root access in SSH
- configure the root directory to be in home/
- install Bind9 and utils - By default the cache is installed and active?
- I need to set up my primary DNS server and configure my nameserver addresses / CNAME records to point to my IP address?
- I could setup an additional secondry DNS server using my second IP address?
- add a virtual host to apache configuration file with any additional configuration
- add more DNS zones for every domain I have and add these additional domains to my apache config file as virtual hosts.
- I need to activate the pre-installed firewall and only allow access on port 80 (http) and port 22 (SSH)?
- Maybe change SSH from port 22 to 22222 for security reasons.
- install MySQL
- install PHP5
- Maybe install Tomcat6 if I want to use Java
- Maybe install FFMPEG if I want to use video
In terms of security what else do I need to consider?
JeevesBond posted this at 04:14 — 13th July 2010.
He has: 3,956 posts
Joined: Jun 2002
Haven't got the time for a full security review, but two things off the top of my head:
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.
See above, you may not need to.
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.
How would anyone query your DNS server?
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!
a Padded Cell our articles site!
pr0gr4mm3r posted this at 01:08 — 15th July 2010.
He has: 1,502 posts
Joined: Sep 2006
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).
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.
Shaggy posted this at 19:42 — 13th July 2010.
They have: 121 posts
Joined: Dec 2008
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.
- 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.
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...
hosted posted this at 09:58 — 21st October 2010.
They have: 37 posts
Joined: Oct 2010
- 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
Humor is just another defense against the universe.
Want to join the discussion? Create an account or log in if you already have one. Joining is fast, free and painless! We’ll even whisk you back here when you’ve finished.