We continue the cycle of Friday's articles " X through the eyes of a C ++ programmer" ( 1 , $$ ). This time under the cut you are waiting for the impressions of an inveterate C ++ programmer from the world of administration. Pain, suffering, joy and other emotions, as always, are rendered by spoilers.

I hope it will be interesting for professional administrators to look at the attempts of C ++ nickname, and C ++ developers will learn something new for themselves.

Hosting

Having raised my mind and calculator, it turned out that it is much cheaper and easier to buy hosting from one of the hosting providers. So if you deploy the server in "home conditions", then you have to spend money on UPS, static external IP, the machine itself and other trifles, like electricity.


Buy hosting turned out to be easy, it turned out that overseas is two times cheaper than ours. After weighing all the pros and cons, Ubuntu OS 14.04 was chosen.


After purchasing the hosting and selecting the OS from the drop-down list, server setup over SSH began.

Bash Vulnerability and SSH

So I was lucky that the beginning of my admin's practice did not fall during the period of finding a heap of critical vulnerabilities in bash. Being under the general impression, I decided to minimize the use of the shell in all services starting from SSH. Under the distribution got a welcome message at login (message of the day). Also in SHH I turned off X forwarding and PAM, banned root, changed the default port, allowed authorization only on asymmetric keys + any small things.


In the process, I discovered

ssh -L _:localhost:5432 me@top-me.org -N 

Great thing for database administration and other trifles: nothing has changed on the remote machine, but you can already reach the localhost ports of the remote machine as the ports on your machine.


Another nice chip turned out that `tail` can take multiple input files and display them simultaneously in the console.

Iptables

All my few familiar admins set up firewalls. In the beginning, I did not expect a big PROFIT, but I went on about the tradition. According to the first manuals, it seemed that Iptables is a monster and cannot understand it. However, after a short time, the tool opened its secrets:

• You can log requests on closed ports
  
  ... what's the point?

  There is not much sense, but you can find out interesting things. It turned out that the favorite port of fraudsters is 5060. IP telephony (SIP protocol) works by default on this port.
  
  
  
• You can ban users
  
  ... felt the power and glad?

  Yes. I made a special rule where all hacking attempts fell (calls on a closed port, TCP packets, spoofing). Five attempts - and in the ban for 10 minutes. And the unfortunate scrappy at this moment, getting to the open port, will receive the answer that the port is closed.
  
  
  
• You can disable Forwarding
• You can prohibit the protocols partially, etc.

Iptables is a smart thing!


Well, for those who want to check the ban on iptables:

• We knock on the closed port a couple of times: top-me.org:8080
• We check that we are banned: http://top-me.org

Nginx

By nginx a huge number of configuration manuals, with many of them in Russian. Unfortunately, this is a problem - some of the articles are written by people who have met with nginx only in theory.

Examples of bad advice:

• It was recommended to write "expires modified 30d;". The author assured that this means that the resource will be re-crafted by the client, if it has changed or if 30 days have passed. And this is not how it works !
  
  ... guilty himself, it cannot work like this!

  Yes, somehow I was stupid
• It was recommended to block all people / bots that came from porno resources!
  
  ... in theory, useful advice!

  Yeah, but only when moving from Yandex Search, a lot of slag is sent in the headers, and the word "sex" is found there surprisingly often!

In Nginx, everything is logical and reasonable. However, all the advice from the articles should be checked by official documentation. Yes, and it does not guarantee 100% performance.

We tighten the nuts

I think many have seen the web server, giving by mistake file with PHP code. I wanted to protect myself from such configuration errors, so I configured nginx and php interpreter to run under different users. A script was written that exposes the rights to files and directories so that nginx does not have access to php directories, and php does not have access to static resources.

Elusive joe

There is a question that has been tormenting me for a long time.

Suppose I somehow protected myself from network access and made life difficult for a hacker. However, what prevents the hoster from viewing my files and data ? Yes, it sounds like a joke about the Elusive Joe, which the hoster is not needed for nothing, but still ...

Results

I recommend trying each server administration. A great opportunity to get new friends-tools, to discover something new in old ones, to think about issues that have never occurred to us before.

A bonus for developers will be a large number of examples of how configs should look in programs and useful ideas for configs in projects.