How to secure an Ubuntu Apache web server | Hacker News Reader

How to secure an Ubuntu Apache web server

nwlinux.com

53 pointszacharytamas26 comments

Most of these tips are really wrong:

* Why using an embedded board for firewall? I can see using an hw firewall, but only in very limited corner cases (i.e. when it does inspection in ASIC)

* what has ssh to do with apache?

* having 10 (wow! Look at me!) desktops and keeping one for 5 tail windows is the perfect recipe to NOT notice anomalies.

* ...

Total rubbish IMHO.

it's ironic that fail2ban will probably not ban anyone if you are running ssh on a non-standard port

it's also nice to be able to block an entire country like china. what if you have customers in china..?

There are my thoughts:

Fail2Ban - "It updates firewall rules to reject the IP address." stopped reading here, NOTHING changes my firewall rules, I do.

Non standard ports - I run on my server sshd on port 22, never had a single problem, yes sometimes I get some attempts, denyhosts helps but it is a problem for those days you type your own password wrong too many times. Also totally unrelated to apache.

Hardware firewall - Not knowing much about this I can't say much either, but my bet is that for a simple server it is overkill.

Virtual hosts - Useless thing in my opinion.

PhpMyAdmin - Don't use it.

Updates - I'm ok with this one, but you can't just update somethimes things break.

Check logs - Not a bad idea at all but not like that, get something to look for suspicious patterns or you will go insane.

.htaccess - Block addresses? Seriously? With htaccess? I would go with firewall rules, and a complete country? Don't like that idea.

One advantage of a non-standard SSH port is it cuts down on log file clutter and sends the script kiddies elsewhere to look for their low hanging fruit. But, as you say, nothing to do with Apache.

Both you and Kijin above have strongly suggested not using PhpMyAdmin.

Are there better alternatives for managing my mysql databases?

I use the command line too, but MySQL Workbench using SSH tunnelling might be a good solution:

http://dev.mysql.com/doc/workbench/en/wb-manage-db-connectio...

The command line?

You don't want to make any of your administration tools on your production server, or any server for that matter, visible to the world.

Your options thus are: 1. Don't use them in the first place 2. Restrict who can access them (eg. IP whitelist) and how (eg. VPN, on the local network)

It's not really about what you use, but what steps you take to make sure no one else can use it against you.

Navicat is a good option, far better than PHPMyAdmin imo.

One thing to be aware of though - when dumping a database, it doesn't use extended inserts when creating a backup file. This can have a ridiculous impact on restore time. For example, a 500MB database I'm working with takes about 10 minutes to restore locally via extended inserts. It takes over an hour w/out them.

> Check logs - [...] get something to look for suspicious patterns or you will go insane.

Any suggestions for this? Thanks.

This article's title should have been "8 things the author did to secure their specific Ubuntu server."

It's strange that it the link got so many votes. While the article has a few points about security, it's nowhere sufficient enough to be considered acceptable reading material for improving your site or server's security. (case in point: complete lack of anything on their list addressing integrity of your files/content, also nothing about backups)

It would be a shame if anyone from HN took the approach the author describes in the above article and felt any sense of increased security on their site or about to be launched web app (there is a whole heck of a lot more out there than "install a few things, make a few tweaks, look what i did")

  Do it now! Modify /etc/ssh/ssh_config.

Correct me if I'm wrong, but shouldn't it be:

  Do it now! Modify /etc/ssh/sshd_config.

You're right, of course.

Ignoring my opinion of _not_ using a non-standard port, I would update both of the files you listed.

One on the server, to switch to the new port. And one on the client, to modify (or create) a configuration section that (among previous options) now lists a non-default port.

Who in his right mind would want to give the port manually on ever connection attempt? :)

Another way (for the client after setting the server up):

Create the file ~/.ssh/config, then fill it like this:

Host mymachineip

Port 443

"Invest in a good hardware firewall." <= this one always makes me laugth even more so when it lists linux based firewalls afterwards "anyways" (not that ipfilter is any bad or less secure than anything else)

Love the "watch the log real time" too :-)

I hate the praise that fail2ban gets. It is useful, but it is not securing anything really, unless maybe you run a public ssh box that has other users who have bad passwords. It will keep the logs cleaner though. A better way to secure SSH on a web server would be to restrict access by firewall and/or disallow password logins.

Agreed, password SSH logins belong nowhere on a box that needs to be secured. Shared key authentication (with a passworded private key) is a lot more secure.

This is mostly useless advice. Some are simpletons of a hardening Linux. But come on, what's to have a hardware firewall instead of netfilter? Even it does not mention about ids/ips configurations.

The article raises some common-sense good points, but as others have noted, a lot of it is crappy advice.

> When a user points their computer towards your server, they generally use your ip address. If they have malicious intentions, they will go fishing for your phpmyadmin, mail, or other vulnerable services.

A malicious person can just as easily go fishing for vulnerable web-accessible pages using your domain name. example.com/phpmyadmin is no more secure than 12.34.56.78/phpmyadmin.

> 5. Block access to phpmyadmin

Nope, just don't install it in the first place. Especially if you're going to access it remotely over plain HTTP. If you really absolutely want to use phpmyadmin, put it in its own virtual host that is only accessible from localhost. Then tunnel into your server to access it.

> 8. Use .htaccess ... to block a range of IP addresses

Using .htaccess to block IPs? Whoa, wrong tool for the job. You might have no other choice if you're on a shared server, but there are much better IP blocking solutions if you're setting up your own Linux server.

Thanks for the corrections and opinions on the article. For someone just getting into Ubuntu and Linux, these are the basics from my perspective. While best practices are always disputed in I.T., I appreciate the continued discussion.

Is there any logic to blocking China or a specific country? Is that where most malicious attacks come from?

If you run a sever with port 22 open, you'll notice about 10 people an hour trying to log in via SSH. These are mostly bots from China trying quick ways to get into your server.

The solution is to change SSH from port 22 to something above 10000...blocking China is just stupid (proxy, anyone?)

pfSense is FreeBSD.

Who voted for such link?

As someone who is bootstrapping a web app all alone I really appreciated this. I know a few people are getting hung up on some "wrong" points but after looking into it I have to say that obviously one shouldn't just implement these measures exactly as written. Everyone's mileage will vary. The point is to consider these options and implement them in a smart way. That means keeping SSH on 22 if using fail2ban. Sure, SSH and Apache don't have much to do with each other but any thinking person gets the point: you're running a web server on apache and access it over ssh all the time, therefore make sure to secure that connection regardless of your chosen web server software.

I dont get all the negativity. Those are some common sense things that can be easily overlooked. I thinking blocking entire countries may not be smart for business but you never know who might want that. I'd also add disabling the root user, installing a software firewall like ufw, and invest in an SSL cert (they're not that expensive compared to the losses you could incur should some ass decide to attack your server). Thanks for this. Merry Christmas.

Exactly. When I came across this earlier I took them with a grain of salt. They probably shouldn't be implemented exactly as written because as you said your mileage will vary. Everyone's stack is a little bit different and have their own sets of weaknesses and considerations.

ugh, securing ubuntu is like using a fishnet to carry water. why just not use a distro that was meant to be used on the server, and not userfriendly desktop with server label glued as an afterthought?

Reply on news.ycombinator.com