Hacker News new | comments | show | ask | jobs | submit login
How to set up a safe and secure Web server (arstechnica.com)
345 points by chinmoy on Nov 28, 2012 | hide | past | web | favorite | 143 comments



It's also a good idea to install (and configure) at least some basic IDS like tripwire. You should probably have it do checks on a cron job as well as doing chkrootkit.

Also a good idea to have your log files backed up somewhere else where your server does not have sufficient access to delete (or modify) them.

Also if you have multiple web apps running, chroot them if at all possible so that if something does break out it can't (so easily) wreak havok over your entire filesystem.

If you are using PHP also bare in mind that a common default is for all sessions to be written to /tmp which is world read and writeable. So if others have access to your server they can steal or destroy sessions easily.

I also didn't see mention of an update strategy for security updates. You can use apticron to email you with which updates are available and which are important for security.

You can set updates to go automatically (I recommend security only) but if you are more cautious you might want to test on a VM first. But keep an eye on them! This is very important, especially if you are managing wordpress etc through apt.

And so many other things that I have probably forgotten.

Having some form of audit (that tripwire can provide) is vital in those "oh fuck" moments where something doesn't seem quite right and you start wondering if you have been pwned but have no real way of actually knowing.


  > If you are using PHP also bare in mind that a common default is for all sessions to be written to /tmp which is world read and writeable. So if others have access to your server they can steal or destroy sessions easily.
I'm slightly confused by this, within the context of this article. Yes, /tmp is readable and writable by all, but that doesn't mean that everything in it is readable or writable to other people. The sessions that PHP creates will be owned by the webserver user (nobody/www-data/something else), and shouldn't be readable or writable by other users.

This is still a problem with shared hosting, where you might have multiple websites running on the same server. One shared host would be able to read another's sessions, because they are all running under the webserver's user. This[1] suggests overriding the session_set_save_handler and writing to a resource that only you control, such as your DB.

[1] http://phpsec.org/projects/guide/5.html


Yes, that's precisely what I meant. I shouldn't post when I'm tired :)


> You should probably have it do checks on a cron job as well as doing chkrootkit.

http://securityreactions.tumblr.com/post/36736148501/rkhunte...

I know it's a meme-grade blog but it really fits.


For anyone that wants more resources like this, I've found articles in Linode's library to be very helpful: http://library.linode.com/lamp-guides


I live (and die) be these guides.


haha! yes me too. so great!


Thanks so much for these links. Got a server coming for Christmas (best present evah!!1!) and was worried that I'd get completely lost trying to configure it blindly. Will definitely refer back to these on that jolliest of days


"...being locked to IIS as a Web server (or dependent on crippled Windows ports of better Web servers) means you'll be playing in the bush leagues. IIS is found running many huge and powerful websites in the world, but it's rarely selected in a vacuum..."

I sense a little bit of bias.

As a multiplatform developer I can think of a number of reasons why someone might opt to go the Windows Server route. ASP.NET MVC 4 is a first class framework and many prefer it over other popular alternatives on other platforms such as Django, Rails, and Cake. In addition, Visual Studio is arguably the best IDE available and publishing to an IIS server is dead simple.

As for cost, full versions of Visual Studio and Windows Server can both be obtained for free through the DreamSpark program for college students and through the similar BizSpark program for startups and small businesses.


I tried to read the Bizspark FAQ, and now my head hurts. But anyways, what I think I was able to get out of it is that:

1. You have to apply. 2. You have to be approved, which takes a minimum of 5 business days, and you may not get approved. 3. At some point you "graduate" and lose your licenses and have to pay for software. The faq does not say when this graduation happens, but I seem to remember hearing something about 6 months.

So, no it is not really free. And it is definitely harder to get it than simply typing:

sudo apt-get install apache2


Unless something has changed:

1. It does take a few days.

2. You do need to be approved. I've heard of plenty of people signing up and getting approved, not about anyone who hasen't. I don't think it's a problem to get approved assuming you're really a startup. And for the record, you don't need to give them almost any information, save a website and filling out a few forms.

3. It lasts for 3 years. I think there's also a limit on how profitable you can be and still be eligible for the program, but it's something high. E.g., if you're making 1 million dollars in profit already, you're not eligible.

All in all, I sense from your tone that you're really looking down on this. But Microsoft is basically giving away thousands of dollars of software to any startup that wants it. Not just servers, but also Windows, the Office Suite, etc. This is a great opportunity and startups that aren't taking advantage of it are missing.


(2) there are in fact people that got disproved, with the most common reason being that they didn't want to provide details about what they actually want to build.

Also people discussing the Spark programs never mention one basic fact - in many countries starting a company is a bureaucratic nightmare and it's not free of charge either. You also need to pay an accountant too, as bookkeeping can get complicated even if you don't have any revenues, depending on the local legislation.

The Spark programs are basically incompatible with most startups, considering how most startups are started - an individual or a bunch of people starting something and experimenting on the side.

> Microsoft is basically giving away thousands of dollars of software to any startup that wants it

Price does not necessarily correlate with provided value, but rather with the scarcity of a resource in the context of supply/demand and the scarcity of many Microsoft licenses is rather artificial.

I use "thousands of dollars of software" every day for free, without having to be approved, without bureaucracy and without a 3-years ticking time bomb.


BizSpark membership lasts for up to three years. In the three months up to the end of the membership, you 'graduate' and get access to discounted msdn subscriptions and support.

You also get to keep any software downloaded during the time you were a member. This includes licensing for servers in production.

There is a fairly clear explanation at http://www.microsoft.com/bizspark/about/Graduation.aspx


I have a win 8 professional license from DreamSpark(my university had to apply for this). The license I got was valid for 2 years, and I graduate in 6 months. So, it's not really hard like you say.


Except that all usage of licenses from DreamSpark must be non-commercial, without ifs and buts. Students are also a minority.


True, but if you really wanted to go MS, you can just find a student willing to download and host it for you elsewhere..


If pushing a new website to the webserver is the best argument of WAMP over LAMP, it sounds a bit odd. Pushing a new simplistic website to a LAMP (default one click installed), has as much difficulty as pushing files to a directory (/var/www). Even if Visual Studio gives a one-button-system, I would still not call that a killer feature over placing files in a directory.

When one pick between WAMP and LAMP, the question one should ask is if a) what framework matches best with the developers skill/knowledge and what features the site is going to have, b) what performance requirements are there, and c) what legacy code will have to run along side. Everything else is just buzz.


Small comment as I agree with your statement in general. Ease of deployment has never been an issue as they are all very straightforward.

The A in WAMP/LAMP is for Apache, so that does not apply here. I'm not sure what the acronym is for Windows/IIS/<database>/.NET.


Why?

The article's target audience is not professional sysadmins, but people who would like to set-up a server and tweak it for their needs.

>> I can think of a number of reasons why someone might opt to go the Windows Server route.

Sure, but practically speaking this happens most often in the corporate env. See above re target audience.

>> can both be obtained for free through the DreamSpark program for college students and through the similar BizSpark program for startups and small businesses.

Why would anyone do this? Just type in terminal three commands and you are done. I am honestly curious - why would anyone use IIS except it mandatory per corporate P&P...?


The thing I dislike most is that with Python/PHP/Ruby/Perl, developing on Windows is an option. If you choose the MS stack, you are totally locked into Windows unless you are lucky enough that Mono work (unlikely for new things).


Do those versions let you use the products on production web servers though?


Isn't that what "full versions" means?


Not sure if you're being sarcastic or not, but "no".

Whether or not a particular software can be used in a commercial context has more to do with licensing than how "full version" it is. In fact, even Trial versions of softwares can often be used in a commercial context during the trial period.

Versus, say, the full version of VMware Player, which while full featured and having no trial period, is prohibited via license to be used commercially.


Yes.


If you want a safe and secure Web server, use what your distribution gives you. Don't add third party sources if you can avoid it, ie. don't need features < 1 year old. It's hardly safe and secure if it's not had long enough for people to find problems with it anyway.

Instead, go with what your distribution gives you. The people who put your favourite distribution together work on making the system safe and secure as a whole. People who don't think it is safe and secure file bugs and they get fixed. And you have one place to get all your updates in case fixes are needed.

If you start adding third party sources, you're on your own as to managing any implications of the way you've put it together. Just because each individual component is safe and secure doesn't mean that it is as a whole. For example, Ubuntu add hardening (AppArmor) for various server daemons which you won't get if you just download apache from the project website.

If you need a guide on putting a system together yourself, then you aren't someone who can manage these implications yourself, and you're trusting the guide author in not having made any mistakes. Are you really in a position to judge his competence?

Just use your distribution's standard web server and you'll get your safe and secure Web server in one command.


By all means, buy the car with the best safety record. But you still need to fasten your seatbelt, buy and properly install car seats for your kids, and, above all, learn how to drive safely.

My point is that there is more to security than installing an OS and running regular updates.


I disagree with that. Apache's defaults on most distros isn't secure. Even 'enterprise' level distributions often fall into the following traps when packaging Apache:

1-> auto indexing enabled (should be disabled)

2-> user directories enabled (should be disabled)

3-> server signatures 'on' (should be 'off')

4-> server tokens set to 'full' (should be 'prod')

5-> hidden (dot prefixed) files not always blacklisted as unauthorised files in Apache config

6-> same as above for editor specific back up files (eg file~). But this is only an issue for people who bulk upload or edit files on the live server (very naughty).

7-> having less optimal SSL configurations (Apache's default SSL set up isn't PCI compliant).

(IIRC there's a couple of other Apache tweaks, but that's just off the top of my head)

Then you have issues with PHP (eg logging to STDOUT so web users can view PHP errors).

And that's just covering the webserver configuration. There's still holes that need plugging if you actually want to run a secure web server; one of my favourite tools for that is using fail2ban which will auto-blacklist IPs in iptables (Linux firewall) based on if certain attacks are detected. For example it can prevent brute force attacks on SSH brute force attacks (which negates the need to run denyhosts as recommended in the article), HTTP auth, FTP, mail servers, etc.

And touching on SSH, many data centres will enable root log ins on their OS pre-installs by default. Your first job on any such box will be creating a user account and then disabling root log ins (PermitRootLogin no -> /etc/ssh/sshd_config).

Then there's a whole stack of optimisations you can run on iptables to adaptively prevent port scanning, forged TCP/IP packets and such like.

Also many distributions ship FTP, which is insecure by default. Anyone sys admin requiring FTP hosting would be better off using a chrooted SFTP environment (so the security benefits of SSH plus the sandboxed (chroot) environment that FTP often benefits).

Let's also not forget the plethora of internal services (databases, MTAs (mail servers), etc). If you're reading this article then you're probably not a trained systems administrator or not working for a large enough company where each server is running in it's own environment. Thus your MySQL / Postgre / whatever databases are running on your webservers. So you need to ensure that your database is only listening on localhost (127.0.0.1). Same applied for your MTA, unless you are intentionally providing a mail services (it is advisable to have an MTA installed even if you're not providing mail services because you can then set up daemons like fail2ban to automatically e-mail you when attempted break ins happen; which will in turn allow you to spot any determined hackers and permanently ban their IP from your box).

And lastly, if you're really paranoid, run your webserver inside a Linux/UNIX container (FreeBSD Jail, Solaris Zone, Linux OpenVZ) instead of inside a virtual machine as there have been hacks where attackers can break out of the VM and gain access to the host system (as of yet, I've not heard such attacks from containers, but if anyone has any evidence of that then I'd love to know). Running inside a container will give your webserver the sandboxed environment to work with plus an easy route for backups / snapshotting meaning minimal downtime and data loss should the worst happen and your server does become compromised.

(source: http://www.youtube.com/watch?v=hCPFlwSCmvU - it's a plugged vulnerability, but it will give you an idea about the kind of issues VMs face when compared to containers)

In short; distribution's don't ship secure defaults. They ship a happy medium between usability and security. However if you have an internet facing box (particularly one not hidden behind a hardware firewall, as many budget set ups are not), then the happy medium isn't secure enough.


I'd say that most of your points are debatable. They can be divided into two groups:

1) Changes that give you relatively little gain from a security point of view at the cost of massive usability. I'd be happy to run production servers without these changes, and so I claim that these are debatable.

2) Changes that stop inexperienced admins accidentally compromising their servers, at the cost of usability/complexity. Debatable because they're less about security and more about not shooting yourself in the foot. Eg. fail2ban. I use ssh keys only. Brute forcing my ssh won't work, and I'd prefer to not allow outsiders to cause firewall rule changes on my servers based on a script that parses log strings with regular expressions. I trust ssh's security more than I trust fail2ban in not having a vulnerability.

> And lastly, if you're really paranoid, run your webserver inside a Linux/UNIX container

This is pretty much what AppArmor hardening does. LXC (Linux containers) are implmented via AppArmor. A compromised httpd daemon restricted in this way won't be able to much anyway (eg. open outbound ports or go to other areas of the filesystem). And this is what Ubuntu ships by default for many daemons.

> Also many distributions ship FTP, which is insecure by default.

Nowadays this stuff is only installed if you requested it, which is different from "ship"ing it. If you use distribution defaults, you won't have an FTP server installed. If you choose to install one, you'll get the weakness whether you use the distribution, tune it yourself or install from a third party source.

> In short; distribution's don't ship secure defaults. They ship a happy medium between usability and security. However if you have an internet facing box (particularly one not hidden behind a hardware firewall, as many budget set ups are not), then the happy medium isn't secure enough.

Secure enough for production. I have plenty of servers on distribution defaults that haven't been compromised (and I have experience in dealing with others' servers when they have been compromised, so I don't think I'm oblivious). You may prefer adding additional hardening, but it is unnecessary and relies on you knowing what you are doing.

Finally, you've missed my biggest point. For someone new to running servers on the Internet, who can he trust for guidance? You, me, a random guide on the Internet or a distribution vendor?


I don't think you've really read through the points I was raising as the vast majority of them were relating to hiding server based information from unauthorised users and preventing brute force attacks. Neither of those two have any impact on usability what-so-ever (that is, unless your 'user' is an attacker lol).

If you don't mind, I will address your points individually:

"Changes that give you relatively little gain from a security point of view at the cost of massive usability. I'd be happy to run production servers without these changes, and so I claim that these are debatable."

Which items specifically prevents usability? None of them do aside the FTP (but SFTP is supported by nearly every FTP client already) and turning off PHP error logging to STDOUT (really not recommended for production servers!). Everything else doesn't reduce usability for authorised users. And I resent the claim that there's little gain as even on my servers which have a low public profile, I get reports of multiple brute force attacks a week (on average, about separate 5 attacks a week, all of which I manually add to a permanent firewall blacklist when it becomes obvious that they're just retrying attacks everytime fail2ban's autoban expires).

"Changes that stop inexperienced admins accidentally compromising their servers, at the cost of usability/complexity. Debatable because they're less about security and more about not shooting yourself in the foot. Eg. fail2ban. I use ssh keys only. Brute forcing my ssh won't work, and I'd prefer to not allow outsiders to cause firewall rule changes on my servers based on a script that parses log strings with regular expressions. I trust ssh's security more than I trust fail2ban in not having a vulnerability."

You don't understand how fail2ban works if that's your primary concern. Fail2ban isn't public facing, it just monitors logs and then adds an iptables (or any firewall you chose) rules based on the results of the log files. It's iptables that is public facing and thus needs to be protected against vunrabilities; and iptables is proven technology already. What's more, preventing brute force attacks doesn't reduce usability nor prevent you from shooting yourself in the foot; preventing brute force attacks is the !!bare minimum!! you need to do if you have an internet facing server. This is security 101! I do agree with you that SSH keys are preferable to password log ins, but that also adds complexity and can reduce usability if users need access from multiple locations and platforms (there are workarounds, eg memory stick with the key on), and then you still have the issue of brute force attacks on every other log in service.

"This is pretty much what AppArmor hardening does. LXC (Linux containers) are implmented via AppArmor. A compromised httpd daemon restricted in this way won't be able to much anyway (eg. open outbound ports or go to other areas of the filesystem). And this is what Ubuntu ships by default for many daemons."

You missed the point about easy snapshotting though, which is why I raised the point about containers in the 1st place. I will grant you that you can have back up solutions on bare metal systems, but snapshotting is way more usable (which is ironic given that's been your key argument). Plus I did say that advice was for the paranoid (ie not really all that necessary unless you fancy tinkering).

"Nowadays this stuff is only installed if you requested it, which is different from "ship"ing it. If you use distribution defaults, you won't have an FTP server installed. If you choose to install one, you'll get the weakness whether you use the distribution, tune it yourself or install from a third party source."

You're just reiterating what I said though as I didn't say distributions install it by default. However you missed my point there as well, as I was describing how FTP isn't ideal for production systems (FTP sends clear text passwords and doesn't behave itself behind firewalls and/or NATing without adaptive routing (which means that FTPS often doesn't work behind some firewalls).). Thus chrooted SFTP is a much saner solution for production systems.

"Secure enough for production. I have plenty of servers on distribution defaults that haven't been compromised (and I have experience in dealing with others' servers when they have been compromised, so I don't think I'm oblivious). You may prefer adding additional hardening, but it is unnecessary and relies on you knowing what you are doing."

You've been lucky. But what your advocating is little more than 'security by obscurity' rather than pro-actively hardening your box. Having worked on a number of high profile web infrastructures (including farms that take web payments), I wouldn't be doing my job if I ignored my steps; in fact our business wouldn't exist as we would break UK laws.

The Apache configuration I described is ridiculously easy to set up, as is fail2ban. They are the bare minimum any web server should implement. Which is why I placed emphasis on them by placing those suggestions at the top of my post. However if we're going to advocate complacency in order to make our lives easy, then lets also not bother keeping our software up to date, because that's a real pain in the arse at times :p


Getting reports of brute force attacks is useful, but is not an indication of bad security. Hiding the reports under the carpet does not increase security either.

Preventing brute force attacks is not the bare minimum. The bare minimum is to not be vulnerable to brute force attacks in the first place. ssh already has built in protection for this, and it slows brute force attacks to the point where such an attack is impossible in practice, unless you have weak passwords. Mandate large enough keys only, ban passwords, and you're done. Allow password authentication is your real security vulnerability here. Patching over it with fail2ban just hides the issue.

I do understand how fail2ban works. "Just" monitoring logs isn't good enough. The data that appears in logs is not generally considered to be a security sensitive channel. It's string data with poorly defined delineation. It should not be trusted for automatic use, since every channel that dumps data into log files is not vetted for security.

> You've been lucky.

I disagree. You claim I'm advocating security by obscurity, but you're the one who seems to think that hiding version strings gains in security. That's security by obscurity, since you can determine the version of software by observing its behaviour (or just not caring and trying your attack anyway).

I'm not advocating complacency. We just disagree on what complacency is. I claim that if you keep your software up to date (easiest if you do follow distribution defaults), then you are sufficiently secure. The overwhelming majority of security compromises happen because people fail to run updates. The second largest cause is because of vulnerable misconfigurations that people have introduced. Only a tiny fraction of compromises come through a default distribution installation that your hardening would catch, and these holes are rapidly patched by vendors and a simple update will close them. I think that it is much more likely that you'll open the second cause (an introduced misconfiguration) if you try hardening and you don't know what you're doing. Which is why I recommend sticking to distribution defaults.


"Getting reports of brute force attacks is useful, but is not an indication of bad security. Hiding the reports under the carpet does not increase security either."

I didn't say reports increase security, and Fail2ban does more than just reporting, it actively blocks brute force attacks. It's a bit difficult us discussing the merits of certain security measures when you keep focusing on the irrelevant as if those were my security suggestions - it's almost as if you're trying to 'death by a thousand paper cuts' my whole post simply to win an internet argument <_<

"Preventing brute force attacks is not the bare minimum. The bare minimum is to not be vulnerable to brute force attacks in the first place. ssh already has built in protection for this, and it slows brute force attacks to the point where such an attack is impossible in practice, unless you have weak passwords. Mandate large enough keys only, ban passwords, and you're done. Allow password authentication is your real security vulnerability here. Patching over it with fail2ban just hides the issue."

For SSH, you'd be right. But as I've repeatedly said, not all services offer key based log ins and sometimes there's a business requirement for password log ins on systems that could be managed with keys. You're original arguments were about usability yet the arguments you're making now are the lest flexible suggestions raised thus far!

"I do understand how fail2ban works. "Just" monitoring logs isn't good enough. The data that appears in logs is not generally considered to be a security sensitive channel. It's string data with poorly defined delineation. It should not be trusted for automatic use, since every channel that dumps data into log files is not vetted for security."

Logs are fine for parsing as you have to be compromise before the logs are comprimised. But which point, it's already too late.

"I disagree. You claim I'm advocating security by obscurity, but you're the one who seems to think that hiding version strings gains in security. That's security by obscurity, since you can determine the version of software by observing its behaviour (or just not caring and trying your attack anyway)."

In theory I'd agree with you, however a great number of compromised systems were attacked by opportunists scanning version numbers looking for boxes to target with known vulnerabilities. Plus, and once again I'm having to repeat myself, those specific changes I advised are actually required to comply with many compliance laws (eg PCI compliance, required if you make finance transactions in the UK).

"I'm not advocating complacency. We just disagree on what complacency is. I claim that if you keep your software up to date (easiest if you do follow distribution defaults), then you are sufficiently secure. The overwhelming majority of security compromises happen because people fail to run updates."

There's no such thing as 'sufficiently secure' as that only depends on the attackers targeting your system. Today you might be 'sufficiently secure' because your box has not been spotted by any keen attackers, tomorrow might be different.

Also, I'd be more inclined to agree with you if all of the examples you've given weren't off topic from the points I raised or just incorrect (eg changing Apache config being dangerous and/or hard, fail2ban reducing usability, etc).

"The second largest cause is because of vulnerable misconfigurations that people have introduced."

I'd go along with that. I've often said 'users are the biggest security risks' :)

"Only a tiny fraction of compromises come through a default distribution installation that your hardening would catch, and these holes are rapidly patched by vendors and a simple update will close them."

None of the configurations I mentioned (bar the list of paranoid ones) fall into that category; non-optimal configuration isn't a hole that gets patched. Plus even if it was, it wouldn't be fixed with software updates as package managers tend to avoid over-writing live config files else they'd risk doing more damage than good.

"I think that it is much more likely that you'll open the second cause (an introduced misconfiguration) if you try hardening and you don't know what you're doing. Which is why I recommend sticking to distribution defaults."

You can't make a system less secure by changing the settings I recommended as the distro defaults are already on the most open defaults. Plus, and once again I'm repeating myself, the configurations I'm recommending are incredibly easy to implement.

I find it odd that we're actually arguing about whether it's worth making the most basic of changes based on the assumption that those people in question are stupid and their box will probably be ok. Surely a better approach would be to suggest optimisations; guiding them through the process if needs be? After all, it's too late to regret using the defaults if and when you get hacked (and in my line of work, I've had to fix quite a number of boxes where the sys admins have been content just running with the default settings).


"I find it odd that we're actually arguing about whether it's worth making the most basic of changes based on the assumption that those people in question are stupid and their box will probably be ok. Surely a better approach would be to suggest optimisations -guiding them through the process if needs be."

Not unless we're people with excellent reputations that "those people" can recognise, or it is possible to determine that people with these excellent reputations endorse our advice. Otherwise we're just adding to the muddle of information on the Internet, some of which is bad, some of which is good, and it is impossible for non-experts to tell the difference.

My argument is that the distribution is such a reputable source, and that a random article upvoted on HN isn't. If a distribution ships insecure defaults, then you should petition them to fix the defaults rather than publishing "fixes" elsewhere. You'll have to fight your corner, of course, against a bunch of people who might differ from you in your opinion about what is and isn't secure :)


I can see the logic in what you're saying, and in an ideal world I'd agree.


How does this look?

https://gist.github.com/c6fd22f73468b26e01b0

I built it from scratch (ish) so I know what all the parameters do.

Do you have more info on the SSL PCI compliance?


comment out Include conf/extra/httpd-autoindex.conf (line 101), and as you're now no longer using it, it might also be worth taking out autoindex_module from your LoadModule's (saves a small bit of memory, but there wouldn't be any noticeable performance benefits. But as you're not using it, there's no point loading it).

For SSL PCI compliance, have the following config as part of your SSL settings (which you've got commented out currently):

  SSLHonorCipherOrder On
  SSLCipherSuite ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH
  SSLProtocol -ALL +SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2
This should force Apache not to default to older insecure SSL protocols and disable SSL compression (HTTP compression via mod_deflate still works here) which leaves HTTPS open to attacks like BEAST.

Bare in mind I'm still testing the above code myself (funny enough, that's actually what I'm doing this very minute) as the BEAST vulnerability is still relatively new (or rather, new enough where it wasn't part of PCI compliance until the last month or so). I'll update this thread in the next few hours if that code doesn't work, but I can't see there being a problem as it follows the standards defined in Apache's manual.

Also make sure you have OpenSSL version 1.0.1 installed (required for TLS1.1 & 1.2). You can check this by running: openssl version from the command line. However if your system is built from a package manager and has been kept relatively up to day, then you shouldn't have a problem there.


OpenSSL 1.0.1 isn't required. but use the following SSLProtocol string instead:

  SSLProtocol ALL -SSLv2


This comment together with the ars article just gave me the biggest 90s flashback ever... really, so little has changed in over a decade???

Next up they just HAVE to show us how to setup our own quakeworld or UnrealTournament'99 or Quake3 server! ;-)


Well, rlpb's fundamental point is quite valid: Vendors have done tremendous work in making an OS secure out-of-the-box. I remember exposing default installations to the public Internet a decade or more ago and watching them get compromised in minutes, if not seconds. Virtually every platform required hardening, and the only thing protecting most ordinary users was the fact that exposure was intermittent via expensive, but quite public, dialup connections. Vendors began taking security more seriously by providing sensible defaults, but it's an ongoing battle with zero-day exploits being discovered far too frequently.


indeed. Windows has come a long way too. I'm not the biggest fan of Windows (strictly personal preference) but I used to love Windows 2000. It was clean, simple yet had a lot of power behind it. Yet Microsoft left telnet turn on by default (and this was back before most homes had routes and thus hardware firewalls).

It was an amazingly short sighted move, but such things were typical back then. And it's only from learning the hard way that we've managed to get to the stage we're at now.

However I think it's often forgotten that servers need a different set of security profiles depending on the server's role and where it is sat. For example, a webserver sat behind a hardware load balancer wouldn't necessarily need much SSH protection as the webfarm HTTP traffic should be on a different VLAN to the internal systems administration traffic (which in turn, would be another different VLAN to the company's staff VLAN). So it would be almost impossible to get access to an OpenSSH log in, let alone attack it. Where as most consumer VPS solutions put all their customer servers in the DMZ, which means it's up to the customer to provide software preventions to harden against access that would normally be protected with a complex hardware solution in more professional / clustered set ups.

And this is why you can't fully trust default configs; there simply is no "one size fits all" solution so package maintainers instead opt for the best compromises.


Ah well, it's rather a "how i set up a small web server for fiddling around with stuff" not so much a professional article about security. Sorry, but the first page is like "mhh, yeah, geeks hate MS, let's use the other choices" under the hood. Why? Because it doesn't really mention a technical choice against MS. Don't get me wrong i would never ever use Windows Server but when i'd write such an article i'd have to find at least a few technical pros and cons for the choices i preset. "Uhhh, the internet is more like a unixy thing" doesn't cut it.

This goes on with the choice for Ubuntu Server. Why? Is it an article about "safe and secure web server" or about "how does my grandma set up a server"? There are much more choices in terms of reliability and proven track record like FreeBSD, OpenBSD, Debian, RHEL/CentOS. The choice was made because it's easier to set up and apparently the author is too lazy to _really_ do his homework.

In the end, i'd say if the articles title would be "beginners guide how to setup a server" i wouldn't comlain..


As a professional developer and amateur sysadmin, I have to say Ubuntu is a great choice, and I will never use CentOS again. The main reason being how updated packages are in Ubuntu, and outdated in CentOS. I don't know about the other options.


Quick (non-security) updates means less testing and more potential bugs and security problems. This is fine for a dev workstation, but less fine for a production server. Personally I use Debian on my servers since it gives me a solid base I can trust and then I manually install the few pieces that I need more up to date versions of.

In my case that's Node.js, Redis, nginx and occasionally python 2.7, and of those I'd be installing Redis (I often run beta releases) and nginx (want to compile in my own modules) by hand on Ubuntu as well. Sure this is slightly more work, but it gives me more control and I feel a more stable server environment.


Quick updates also decrease the likelyhood that there will come a point in time when you say "damn, we really need the new version of XYZ, let's just compile it and install it ourselves...", which involves problems of its own: you now have to monitor security updates for those system components yourself, rather than simply running the package manager to pick up security updates. It's a tradeoff, and I think Ubuntu handles it fairly well: you can either get the regularly updated ones, or the long term releases.


I would much more care for timely security updates. Servers are the parts where you don't need the latest software, in my opinion. Not if it comes for less stability or security. In the best case i have a very secure default installation, install the software i need from updated repositories, let the server update itself (or let it remind me of updates) and be gone with touching the shell ever again. The goal is to have the server running safe and secure for years and not to have the latest pre-beta release versions of NoSQL-engine XYZ "just because". Personally on my Desktop i have been a Debian guy (and after that Ubuntu), but it all depends on the requirements.

My personal view:

- my personal server runs Debian but i would place ubuntu a second for a one-person thing with no personal data on it. I know it runs a stable and updated OS and it just runs and runs and runs. You need a newer software version? You can selectively take some from testing or even unstable if you have to. You still get timely updates and live in an eco-system that is largely seen as proven, stable, excellent. Ubuntu (afaik) only get's Debian testing packages anyway, but still needs to patch them or tweak them. Or you get non-upstream packages. Also my experience is that Debians configuration is quite secure by default. Whereas Ubuntu tries to make it easy for you but also more open to security flaws.

- for an enterprise i can totally see why many choose RHEL (because of support, fast security updates and great in-house know-how. Do you know how many kernel developers are employed by Ubuntu? You don't want to know.. I give a lot of Kudos to RedHat for being such an open and contributing company.)

- for a start-up i can totally see how FreeBSD might fit as an internet-facing frontend. It's a stable and fast workhorse, and you'll end up compiling, configuring, installing the core components of your system all the time anyway.

Talking about it i feel a bit sad of not mentioning Solaris anymore. Solaris "was" awesome.


Better hardware would be an HP Microserver (which should win the contest for "worst URL ever"):

http://h10010.www1.hp.com/wwpc/us/en/sm/WF05a/15351-15351-42...

Has ECC RAM support. Takes 4 3.5" hard disks, and runs very quiet and cool.


That is a truly frightening URL, makes me wonder what kind of CMS they are running that generates 100 character long URI (Vignette?).


This is the scary part IMO: http://h10010.www1.hp.com - If you go to http://www.hp.com/xxxxxx (the rest) or even http://h10010.www.hp.com/xxxxx, it's a 404. Even worse:

    curl http://www1.hp.com
    curl: (6) Could not resolve host: www1.hp.com; nodename nor servname provided, or not known


The HP Blog URLs are scary as well..


I looked at getting one of those. However, it seems like HP is sunsetting the Microserver line, which is a real shame.


Which is a good reason to get one now. I have one (running FreeBSD and ZFS), and it has been great. I does what I ask of a homeserver: it runs silently and is pretty good at saturating a 1Gb connection, the RAM really helps the performance. All at a great price.


I would have, but at the time I was looking to purchase (very recently) the hardware was already getting a little long in the tooth.

That combined with the costs of getting a static IP and a few other things I'd want for hosting @ home, and I decided to use a VPS instead.


Thanks for that link, looks like a real steal.

Do you have one of these? Can you answer some questions for me, as I'm just about ready to impulse buy!

Is it passively cooled? Is the "embedded raid" an actual RAID or some junk software emulation (I'll probably use ZFS anyway, and that should be used w/out hardware RAID)?

EDIT

Not passively cooled :( Full review here: http://www.silentpcreview.com/HP_Proliant_MicroServer


I think it's time articles like these start suggesting an infrastructure as code product, like chef or puppet, to do the heavy lifting.

I feel like doing this stuff by hand should be considered insecure and outdated..


All chef and puppet give you is a tool to setup 100 insecure and outdated servers, they don't help at all with the initial security decisions.


Any other tools or resources you'd recommend to a newbie web server admin? I've checked out a few books but it's hard to know what's being used in industry.


I'd recommend puppet or ansible.

http://ansible.cc/

http://puppetlabs.com/


If you don't know how to do it by hand, then puppet is just going to confuse you. Better to keep it simple when you're new at something.


Vurtualization is not for production. Why to have this useless layer, which messes up your CPU caches even more, interfere with you IO and complicates memory model? What for?

Virtualization was build for server providers to make easy money, not for server owners to gain performance advantages.

Vistualization is not for production. Production servers need less code, not more.

It is the same kind of mistake as JVM - we need less code, integrated with OS, not more "isolated" crapware which needs networking, AIO and really quick access to the code from shared libraries.

And, of course, a setup without middle-ware (python-wsgi, etc) and several storage back-ends (redis, postgres) is meaningless.

Update:

Well, production is not about having a big server which is almost always 100% idle, and can be partitioned (with KVM, not a third-party product) to make a few semi-independent virtual servers 99% idle. This is virtual, imaginary advantage.

On the other side, your network card and your storage system cannot be partitioned efficiently, despite all they say in commercials. And that VM migration is also nonsense. You are running, say, a MySQL instance. Can you migrate it without a shutdown and then taking a snapshot of an FS? No. So, what migration you're talking about? It is all about your data, not about having a copy of a disk-image.

It is OK to partition development, or 100% idle machines - like almost all those Linode instances, which have a couple of page request in a day - this is what it was made for, same as old plain Apache virtual-hosting. But as long as one needs performance and low latency, all the middle-men must go away.


You have no idea how modern virtualisation works. Go read about hardware assisted virtualisation on x86/x86-64.

Most server operators don't care about performance. They have performance coming out of their ears. They care about redundancy and maintenance, or to put another way cost centres.

Your post is on the wrong side of history. Virtualisation is being rolled out in a massive scale right now. Essentially you can abstract your entire physical infrastructure away from your logical infrastructure.

You have a physical server die? The HV has already moved the image to a new node and started it. Before you even receive the e-mail notification the new server is already booting.

So now a hardware failure goes from being a massive panic, to being a small annoyance. You pull the dead hardware from the rack, and plug a new generic node in and that now becomes available for the HV to use.

You want to back up a server? Take a copy of the ENTIRE image in one go. You want to deploy a template? Well that's trivial with images. You want to do change management with the servers? Just put the images in GIT. Boom done.

What you're suggesting is essentially taking the cheapest bits of server management (i.e. the physical hardware) and acting like they're the most expensive bits (i.e. people, time, and flexibility).


You know nothing about me.)

Automated server management has been done long before virtualization stacks emerge, and it about utilizing monitoring and network boot.

What virtualization stack Google uses on its servers? None.


Google doesn't need virtualisation because Google is already deploying a large number of identical nodes which can be easily pulled and replace (i.e. Google's infrastructure is identical to virtualisation, but without the need for it).

Most businesses don't have hundreds of identical servers and services. They have a few dozen very specific or niche ones which need high up-time. This is one area where virtualisation can play a great role.

Another example is someone like a host where they want to distribute resources without any human intervention (e.g. Virtual Private Servers, shared hosting, etc).

All in all you're now starting to see data centres turn into "dumb" hardware farms, with the logical design and deployment being handled up-stream. This even extends to things like networking (routes, switches, etc - all centrally controlled).


So, unless we are selling CPU hours, like owners of a mainframe or a hosting provider, we don't need any virtualization?

Is it possible that the inefficiency and added unnecessary complexity makes a virtualized servers unusable for the most common server's tasks, due to I/O interference and cache/memory access complications?)


I never said anything about selling CPU hours. It has nothing to do with that. In fact my example about organisations directly contradict that.

It has to do with organisation and about being able to abstract logical servers away from physical hardware.

There is very little inefficiency (see hardware assisted virtualisation point above) and very little overt complexity (go play with any modern HyerVisor solution).

As I said above you don't understand how virtualisation works. Your points about "I/O interference" and "cache/memory access complications" just make you sound ignorant.


Well, I'm really ignorant, when it comes to meaningless sentences like organisation and about being able to abstract logical servers away from physical hardware. You're probably right.

On the other hand, I'd been involved in a few projects, which includes optimization of a big centralized databases, so, I think, I know a bit about flows of data, access patterns and where the bottlenecks are (hint: around serializing and scheduling low-level I/O operations).

Try to look under the surface structure, which plain words are.)


You talk about edge cases. And you actually have yet to provide any data to back up your statement when it comes to penalty because of running it in a virtual environment.


Google might not run the vast majority of their services on VMs, but they do use virtualization (Xen AFAIK).

They even developed a cluster management tool for Xen/KVM: http://code.google.com/p/ganeti/


>Go read about hardware assisted virtualisation on x86/x86-64.

To further on this excellent and valid point, very cheap virtualisation was available on a lot of other very solid and very productive architectures and has been for decades; it was just x86 finally catching-up late. There are a whole lot of reasons speaking FOR virtualisation and only a few very specific applications where it might be a bad idea. I have no idea what OP up there is all about and against it, they make no sense.


How is this the top comment? I'm sure some of your points may be salient, but practical experience says virtualization works just fine for production. Same with the JVM.


1. at what cost? 2. just fine is not enough. 3. for some reasons all sites uses nginx, not jetty.)


Nginx and jetty are not the same thing. Nginx is a web server optimized to deliver content. Jetty is an application server built to run the applications. Both can be used together.

Also...Is Amazon EC2 considered virtualization for you?


Just fine is just fine for me, actually.


"just fine" is something all companies I have dealt with would agree with, at least when it comes to servers.

Running closer to the metal often means higher development costs, which vastly outweigh the performance overhead abstraction layers they incur.

You're right about some things getting messed up by virtualization, but you're over-estimating the impact this has on running an online service.


I agree with you. I don't understand how this comment got so high with such short-sighted arguments, I would expect people here to have a little more insight.


Use virtualization (or LXC containers) for ease of management and to better allocate complementary workloads according to the resources they require and to how redundant you need them to be.

Chances are your physical boxes will have one resource almost always 100% idle and having your workloads virtualized allows you to better use them.

Also, virtualization allows you to more easily fix problems - you just delete the box and rebuild it from a base image and the packages you need. Reimaging a physical box is a pain.

Obviously, if you are into HPC and very low-latency, you need physical hardware. You probably need some specialty networking hardware too and maybe less OS than most of us would like to have. But then we are no longer in the general purpose amd64 box world anymore.

I remember one instance where we were having some trouble with one batch-processing workload. The amd64 box we had for that was not enough, despite having much more memory and processing cores than its peers. I suggested we moved the workload to an almost abandoned Itanium box we had played with for some time. The HP machine crunched the workload more than 3 times as quickly. I noticed the working datasets could fit completely inside its (then) huge L3 cache (16MB, IIRC) but not in the 4MB of the amd64 machine, more or less eliminating the external memory bus penalties.


The first three paragraphs are just a marketing-speak.)

The last one is more interesting. Have you noticed that your solution was in a splitting workload, not in sharing it with other processes?

In general, splitting (dividing/partitioning/isolating) is a good idea, sharing (sharing resources) is a bad one.

Sharing, unless your data is read-only, like a txt segments of code, is a source of problems, not a solution. Partitioning, on the other hand, is a universal, natural way.


You cannot dismiss arguments as marketing-speak just because they don't fit your high-performance viewpoint, and "marketers" have made similar arguments in the past.

The first two paragraphs are about one benefit: using otherwise idle resources. At my lab, we have five powerful servers for data-processing experiments and non-time-critical analytics. Most of the time they sit completely unused. By installing Xen and running things in virtual machines, we have been able to also put tens of differently configured web servers for various small projects on each.

The third paragraph is also very valuable from experience. It has been very useful to keep documentation around how different servers are set up, and verifying that the actual setup still matches the documentation. This has been easiest to ensure by having scripts that create a new VM, install packages and make configuration changes - if in doubt, completely delete the VM and re-create it from scratch with a single command-line.


Most of the time they sit completely unused.


I think you overstate how much performance hit you get by running things virtually in ex. KVM or Xen. With the first, it's almost negligible, as you don't have to run a paravirtualized kernel in order to gain full access, so for Linux you are basically just limited by other factors, such as disk IO long before anything else start to kick in.

I don't buy your argument about latency one bit, do you have ANY data to back up your statement? You know - Google and many other big players run huge virtual machine clusters, you'd think they wouldn't if that almost unmeasurable difference in latency had an impact.

I would run KVM on top of a machine, even if there was only to be one VM on it, just because moving, backing up or scaling up or down can easily be done. You can also easily migrate the host to another physical machine if you are experiencing hardware issues, or just upgrading your rig. And yes, you can migrate a running server, I'm doing it all the time.

And yes, you can snapshot and take a backup of a running server, but what goes on inside of MySQL, or other applications for that matter, has nothing to do with the consistency of the disk image. When you snapshot a disk image, you naturally don't know whats in RAM.


but what goes on inside of MySQL, or other applications for that matter, has nothing to do with the consistency of the disk image.

All you can do is instruct MySQL to pause, flush all its write buffers, and then take a snapshot of FS, then move it on. But this procedure has nothing to do with whether or not it runs under, say, VmWare or not. It has anything to do with does this particular disk volume supports FS snapshoting.

The next question is - what use of that snapshot when your system crashes and you got lost all the changes made since the last snapshot? How a VMWare helps you here?

Now consider what a bottleneck naively virtualized (represented as a file in a host system) disk volumes become, when I/O operations on, say, your DB's physical (transaction) log got interfered by I/O operations of your syslog daemon, or whatever other activity is going on.

In a database world the solution is about decoupling, partitioning and avoiding any I/O sharing possible. So, virtualization is just another layer of complexity which makes everything less predictable and controllable.


Have you actually used any of the products you are talking about? You don't take the filesystem snapshots on the virtual machine, but of the disk image on the host, typically using LVM or something similar. What you want to do with this snapshot later on is up to you, normally people just export it to a remote location.

For total system failures you still need a proper backup solution on the machine. This is true even if it's dedicated hardware or a virtual machine.

You seem to always resort to talking about databases, and this might be true for huge centralized databases, but that is a pretty damn specific task. Also, I thought we were past the "put everything on one box"-model.

The complexity you talk about is just not there. It acts and feels just like a normal machine, and you have yet to provide any data that would support your claim, even for edge cases.

Something worth reading: http://en.wikipedia.org/wiki/X86_virtualization#Hardware_ass...


Since when does Google run huge virtual machine clusters?


I might have exaggerated a little, I have no idea how huge the virtual machine park is, but I would argue that they wouldn't invest in Ganeti with full-time employees if they weren't using it internally. During a talk, one of the developers said that they were running pretty large clusters.


EC2 seems to be doing fine on virtualization. A service of that kind would be impossible to run without a VM layer inbetween. So yes, you pay a performance penalty, but you get something in return: Flexibility. And for some use-cases flexibility is far more valuable than raw performance.


Bingo. And in the case of EC2 the economies of scale almost certainly outweigh the cost of a VM layer.


This sort of feels like an argument with someone who prefers to optimize the hell out of things in the best possible way. Thats a fair position to have and to take in this day and age.

What virtualization allows you to do is optimize the organizational responsibility. If I am developing internally on my VM, when it gets certified by ops management, and rolled out onto the live VM stack, I can be very sure what I am being responsible for; the ops also can be sure (because they maintain a huge VM filesystem, mostly) that they don't have to deal with things at a very thin slice.

For web operations, look, its simple: VM is good enough because there is so much overhead all over the typical web stack that a few frames of difference are, largely, irrelevant to the use case. Okay, don't put your multiplayer live realtime universe hashes in a VM; those belong bare metal. But the web front ends that are serving the same old content, over and again .. these are well worth putting in a package which can be massively deployed at whim.

A typically well-packed VM, consisting of only the hand-optimized built image of a development team with this in mind, can be a very, very tight package. I've seen reflectors and mongodb proxies and so on, packed into 256meg boot image that can be replicated simply by giving it a new name .. deploy 2,000 copies of these VM's, and you have a massive solution to the front-door problem..


> And that VM migration is also nonsense. You are running, say, a MySQL instance. Can you migrate it without a shutdown and then taking a snapshot of an FS? No.

Rubbish. I do this regularly.


We have an entire 2 million GBP VMware estate which I inherited

I agree entirely with this comment. Between lun size limits, license management (which is hell), the general additional work and the fact that the benefits are suspect, I agree.

Processes and multiprogramming were invented to virtualise batch machines. That's as far as it needs to go.

I'm not impressed with the industry trend.


Go to any big company's datacenter and you'll be sure to find some virtual machines that are in production. There is some performance penalty for sure, but the added flexibility and reliability covers that neatly. If your VM host seems to be failing, you can live migrate your VMs off that box and take it down for maintenance. That's not an option when running your services on bare metal. On flexibility side, it is very powerful to be able to allocate resources depending on need, not needing to buy specific hardware and hope that it's a good fit for the workload it runs.


Virtualization is most definitively not useless, as any sysadmin managing more than a couple servers will tell you. The advantages are so many that in fact it should be the default go-to option when provisioning a server (even a single-purpose one).

Many if not most of the production servers on the web run some sort of virtualization; Xen alone powers EC2, Rackspace, Linode, Rimuhosting and many others. In my experience it only adds about 3% of CPU overhead as a disadvantage.


This is a pretty bold statement to make considering the fact that there are a lot of companies who do use virtualization in production and do so quite successfully.


Not true, for a startup, virtualization is the most cost effective way of hosting applications/websites. We have a physical server with 32GB RAM and on it four virtual machines for different purposes. None of them breaks any sweat.


This guide doesn't cover important things like the firewall and blocking attackers (shorewall, fail2ban) and properly configuring mysql, php, etc.

If you have a small server, I'd really recommend checking out these scripts that assist with configuring and setting up a server very quickly: http://lowendscripts.com/wiki/shell_scripts

I personally used a fork of lowendscript last year to set up some servers, but if I had to set up a new server today, I'd check out some of the other other options at that link, like Minstall: https://github.com/maxexcloo/Minstall But this Xeoncross lowendscript fork is still very active: https://github.com/Xeoncross/lowendscript


Fail2ban is actually a vulnerability in itself.

Say I worked out your home IP (not hard), then sent a large number of failed SSH attempts with the IP address forged as yours. You are now locked out if your home server.


That's why I whitelist my IPs in $ignoreip in jail.conf.

Fail2ban is actually a vulnerability in itself.

That's a bit harsh. It's true that you may have to tweak some settings to prevent or minimize DoS attacks, but even that risk is a far cry from an attacker gaining a login or rooting the box. Fail2ban has proven to be safe and reliable in the years I've used it. Nonetheless, the old maxim holds true: Know your tools.


That's why I whitelist my IPs in $ignoreip in jail.conf.

If you are already able to whitelist your (valid) login points, why would you need fail2ban? Just whilteliste them in your firewall and/or /etc/hosts.allow.

Personally I've yet had anyone bruteforce my ssh-key (although, as I run Debian, that is just luck as it turned out...). Still, fail2ban wouldn't really have helped against an attacker that knows/can figure out my access token off line...


I need to support multiple roaming users. Manually maintaining whitelists would be a burden.

Fail2ban isn't a firewall. It monitors logs for suspicious activity and responds with an action (not limited to banning an IP). When you expose services publicly, it's one of many tools you can use to limit bad behaviour without penalizing or inconveniencing legitimate users. I also use iptables (including the recent and string modules), RBLs, and a host of other access controls. Security is a layered approach and redundancy isn't a bad thing.


Avoiding banning certain ips (to avoid denial of service) is a form of white listing. So either you're open to denial of service, or you're able to whitelist all essential access paths?


Only open SSH port over tun0 and use OpenVPN.

BAM.


True, but then they would have to know your home IP number which the login-spam bots won't.

I always make sure I have some access to a network KVM or remote console for my servers so I would be able to unblock myself.


I recently worked on a site run on such a server. I've set up my own servers before, and I think it can be fun, but this time it was the other guy's. I have to say it was pretty annoying because the little things that were not set up properly added up to a website that wouldn't deliver email, a shell environment with awful defaults...yuck. There was a lot of maintenance that was ignored because the guy just didn't have the time. Well, that's what commercial web hosts are for. It's amusing to think that some overburdened IT guys believe they're doing their clients a huge favor by running a vanilla web server in their network closet.


Pardon my stupidity, but how would one go about getting an IP address for a server installed at home? Is it a static IP address provided by my ISP, or something else ?


The messages that your computer sends to the internet include an IP address which the internet uses to send responses back to your computer. The problem is that these addresses are unstable -- your ISP reserves the right to change it, basically.

If you want to host a server from home, you have a few choices:

a) Obtain a static IP address from your ISP.

b) Obtain a domain name from a dynamic DNS provider and map that to your current IP address. Update the mapping as necessary.

c) Just use your existing IP address -- this is how P2P or Skype works, for example.


There is an alternative, one can create a IPv6 only service, as tunnels with static IP are commonly free.

Of course there is the downside that no one except those very few people that has ipv6 will be able to use that service, but it is free and it can be a very useful way to access a computer behind nat.


It really depends on the ISP. A static IP generally has to be requested, and at a cost. Additionally, some ISP's like to be restrictive blocking inbound low ports such as 25, 80, 443 - so hosting a web server off your home connection might be a problem depending on the ISP.


It's specifically against residential Comcast ToS, for example, to host a publicly-accessible website.


If you have a dynamic IP, Dyn offers DNS services[0] that let you tie a domain to it through them. I believe it requires you to install something on your machine that monitors your IP and reports it back.

Otherwise, you just use your IP and make sure to edit the DNS yourself when it changes.

[0]: http://dyn.com/dns/


Many routers have dynamic DNS support built in now. For example, my Asus RT-N66U supports several DDNS services including Dyn and a free one that Asus provides for its router customers at {yourcustomsubdomain}.asuscomm.com.

No big surprise here, since the router is really just a nice little Linux box.


Ah, I have an Asus RT-N16. DD-WRT is truly awesome!


That would be something like: http://dyn.com/support/clients/linux/ddclient/


By your ISP. Some plans come with a static IP by default, but many providers make you pay extra (or go onto a business plan if you tell them you want to run servers)


Article covers main parts of the webserver setup and gathers very interesting information scattered all over the Internet. All the nginx setup and config things are REALLY useful, all the more regarding the poor quantity/quality of resources one can find out there. Really useful to me. I wish I had one guide like this when I setup my own webserver. I made a tl;dr version but the main interesting parts stay all the nginx tricks for me http://tldr.io/tldrs/50b5ccb711c0ea5051000f29.



What is really amazing is that these sort of questions (and detailed answers) are not welcome on StackOverflow:

Locked: "This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: FAQ."

At least the list of references there is useful.


What kind of 'top' program is this shown in page 3 (direkt link to the image: http://cdn.arstechnica.net/wp-content/uploads/2012/11/webser...)




Thanks. Installed.



http://configserver.com/cp/csf.html

Another solution that is much easier to configure compared to iptables/fail2ban.


Personally, I'd just pay $10/month or whatever and spin up a cheap VM on Rackspace, EC2 or similar with 256MB of RAM and a few gigs of disk storage. A simple web server really doesn't need a full on server (or desktop, even).

It's a bit different if you're expecting said site to get 100K+ views per day or is going to host some big database, but even then I'd probably run it in the cloud to save on bandwidth costs.


Is there really any benefit to using nginx over Apache 2.4 (Event MPM)?


Frankly, articles like these are a deterrent to all but the most techie of people. Why go through all this and shell $270 when you can get an Amazon EC2 instance free for a year!


It's considerably more than $270 if you're using your own hardware. Consider bandwidth and energy costs.

I do wish the article gave more attention to VPS providers like AWS or Rackspace, but I don't see how anything in the article could discourage someone from administering their own server (that is, of the set of people who aren't already put off by scary command lines). 90% of the article is relevant to someone with a VPS.

FWIW, my current costs for a single dev server at Rackspace (initially Slicehost) are about $12-$20/month ($240 max for a year), which probably costs less than the electricity my current computer is using.


Did you read the article? You still need to setup nginx or apache or whatever on EC2. Page 2 onwards actually deals with these things


Yeah. So why pay $270?


Perhaps you need storage in terabytes for something. 12TB on your own machine is relatively cheap. On AWS, not so much. Read speed is another factor.


As far as being "the most techie of people", this article is actually quite basic and gives a very easy introduction.


Honestly, its a much easier setup on your own box. You have the option of a GUI, and I've found installing a linux distro on my own box to be much easier than figuring out EC2.


I'm not sure where a GUI comes in handy here - it's not like there's any good GUI (in the traditional sense) tools for fiddling with webserver config.

Even were I to want one on a webserver on the localhost I'd probably just install webmin or something, which you can do equally well on a VM somewhere else.


If you're not already comfortable with the command line, Ubuntu's package manager GUI is a hell of a lot more intuitive than apt-get. After that, a simple text editor is easier to work with than nano, emacs, vim, etc. for changing config files.

That said, I wouldn't use a GUI for such things, but I would still prefer my own box. The big power button is a lot easier than EC2s endless menus and options. I say this from the perspective of someone who's used EC2 for a couple of project - imagine someone who's never seen it before.


Am I the only one who thinks that SSD are useless since most of the time the processing will be bottlenecked by the network overhead?


Network overhead is just one bottleneck.

A harddisk seek + reading 1 MB sequentially is something like 30 times slower than SSD and 120 times slower than reading from RAM. Disk seeks are what really kills you, as a disk seek is 20 times slower than a roundtrip within the same datacenter.

Sending 1 MB of data over a 1Gbps network using a disk seek and a sequential read is 3.6 times slower than doing the same with SSD. For big files with a server that has to serve many concurrent requests you'll end up doing several disk seeks for the same file. And we've been talking about the ideal too, because data on disks can get fragmented and so reading from the same file does not guarantee a sequential read.

This is why Varnish does caching, even when serving static files. If you want high performance with low latency, then Varnish works better than something like Nginx.

As an example, right now I'm working on integrating with an OpenRTB ads exchange platform. My server has to respond within 100ms total roundtrip (with an upper bound of 200ms, but they complain if you consistently respond in over 100ms). It's enough to say that everything to be served has to be already in memory, as doing anything else means that window cannot be met (consider how a single disk seek can cost something like 10ms).

So yeah, SSDs can be useful.


Thank you for the explanation.


Unless you're purely serving static content, network bandwidth is not going to be your bottleck.

That's not really the point though, since the big motivator for SSDs isn't bandwidth, it's latency.


This article would make a really nice screencast that would be much more useful to newbie sysadmins.


How would a screencast be more useful?


not sure, but I wanted to say thanks for the C as a functional language links you replied with earlier. Comments are off after 14 days so I couldn't say thank you there. The closest was the function pointer one, but it still wasn't the one I remember.


It's much easier to see the workflow and listen to someone speak, than read a complex article.


sounds like an argument for a simpler article. I agree, the article is rubbish.


Nitpick:

> Temporary files usually start with a dot or a dollar-sign.. to make sure that Nginx never serves any files starting with either of those characters...

> location ~ ~$ { access_log off; log_not_found off; deny all; }

Wouldn't that regex match temporary files ending with ~ (as it should)?


nice introduction article (on mostly how to setup nginx); the title should reflect this instead of focusing on 'safe and secure' ... if one was to store something valuable (lets say cc info) you would want to go far beyond what this article covers. #justsayin


The only way to make a server 100% secure is to grind it into dust and fire it into a black hole.


What a bias. Using Debian and not even mentioning forks like Red Hat. Downvoted, never recommend.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: