Администрирование глазами C++ программиста

Продолжаем цикл пятничных статей "X глазами C++ программиста" (1, $$). В этот раз под катом вас ждут впечатления заядлого С++ программиста от мира администрирования. Боль, страдания, радости и прочие эмоции как всегда вынесены под спойлеры.

Надеюсь будет интересно профессиональным администраторам посмотреть на потуги С++ника, ну а С++ разработчикам узнать для себя что-то новое.

Хостинг

Пораскинув мозгами и калькулятором выяснилось, что намного дешевле и проще купить хостинг у одного из хостинг провайдеров. Так если разворачивать сервер в «домашних условиях», то придется потратиться на UPS, статический внешний IP, саму машину и прочие мелочи, вроде электричества.

Купить хостинг оказалось легко, выяснилось что зарубежные раза в два дешевле наших. Взвесив все за и против была выбрана ОС Ubuntu 14.04

После покупки хостинга и выбора ОС из выпадающего списка, началась настройка сервера по SSH.

Bash уязвимость и SSH

Так уж мне повезло, что начало моей админской практики выпало не период нахождения кучи критических уязвимостей в bash. Находясь под общим впечатлением, решил минимизировать использование shell во всех сервисах начиная с SSH. Под раздачу попало приветственное сообщение при логине (message of the day). Так же в SHH выключил X forwarding и PAM, запретил root, сменил порт по умолчанию, разрешил авторизацию только по асимметричным ключам + всякая мелочёвка.

В процессе работы открыл для себя

ssh -L удаленный_порт:localhost:5432 me@top-me.org -N

Отличная вещь для администрирования баз данных и прочих мелочей: на удаленноё машине ничего не поменялось, однако ты уже можешь достукиваться до localhost портов удаленной машины как к портам на своей машине.

Ещё одной приятной фишкой оказалось, что `tail` может принимать несколько файлов на вход и показывать их одновременно в консоли.

tail -f /var/log/kern.log /var/log/auth.log /var/log/nginx/error.log /var/log/nginx/access.log

==> /var/log/kern.log <==
Mar 16 10:49:39 rating kernel: [2226306.618927] --- top-me.org: possible port scan--- IN=eth0 OUT= MAC=04:01:2a:64:3c:01:28:8a:1c:64:cb:f0:08:00 SRC=184.105.247.244 DST=80.240.141.163 LEN=30 TOS=0x00 PREC=0x00 TTL=56 ID=39877 DF PROTO=UDP SPT=48784 DPT=5351 LEN=10 
Mar 16 10:53:57 rating kernel: [2226564.521544] --- top-me.org: possible port scan--- IN=eth0 OUT= MAC=04:01:2a:64:3c:01:28:8a:1c:64:cf:f0:08:00 SRC=207.30.132.123 DST=80.240.141.163 LEN=72 TOS=0x08 PREC=0x00 TTL=42 ID=3852 DF PROTO=UDP SPT=53 DPT=11653 LEN=52 

==> /var/log/auth.log <==
Mar 16 11:01:17 rating sshd[31323]: Accepted publickey for ANONYMOUS from 66.66.66.66 port 66 ssh2: RSA 

==> /var/log/nginx/error.log <==
PHP message: redirecting to http://top-me.org/" while reading response header from upstream...

==> /var/log/nginx/access.log <==
66.66.21.66 - - [04/Mar/2015:12:29:25 +0300] "GET /land_job HTTP/1.1" 200 2601 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:36.0) Gecko/20100101 Firefox/36.0" "-"

Iptables

Все мои немногочисленные знакомые админы настраивают фаерволы. В начале, я не ожидал большого PROFITа, но пошёл на поводу у традиции. По первым мануалам казалось что Iptables монстр и в нем не разобраться. Однако, спустя небольшое время, инструмент приоткрыл свои тайны:

• Можно логировать запросы по закрытым портам
  ... а смысл?

  Смысла не много, но можно узнать интересные вещи. Так оказалось что любимый порт мошеников: 5060. На этом порту по умолчанию работает IP телефония (SIP протокол).

• Можно банить пользователей
  ... почувствовал власть и рад?

  Да. Сделал специальное правило, куда сваливались все попытки взлома (обращения по закрытому порту, кривые TCP пакеты, spoofing). Пять попыток — и в бан на 10 минут. А неудачливый ломальщик в этот момент, попадая на открытый порт, получит ответ что порт закрыт.

• Можно запрещать Forwarding
• Можно запрещать протоколы частично и т.д.

Iptables — шикарная штука!

Ну а для желающих проверить бан по iptables:

• Стучимся в закрытый порт пару раз: top-me.org:8080
• Проверяем что мы забанены: http://top-me.org

Nginx

По nginx огромное количество мануалов по настройке, при том многие из них на русском языке. К несчастью это проблема — некоторые из статей написаны людьми, встречавшимися с nginx только в теории.

Примеры плохих советов:

• Рекомендовалось писать «expires modified 30d;». Автор уверял, что это значит, что ресурс будет перекеширован клиентом, если он изменился или если прошло 30 дней. А это не так работает!
  ... сам виноват, оно так работать не может!

  Да, как-то сглупил
• Рекомендовалось блокировать всех людей/ботов, пришедших с порнушных ресурсов!
  ... в теории то, полезный совет!

  Ага, но вот только при переходе с Yandex Поиска, куча всякого шлака шлётся в заголовках, и слово «sex» там встречается на удивление часто!

В Nginx всё логично и разумно. Однако все советы из статей стоит перепроверять по официальной документации. Да и это не гарантирует 100% работоспособность.

Закручиваем гайки

Думаю многие видели веб сервера, отдающие по ошибке файл с PHP кодом. Хотелось обезопасить себя от таких ошибок конфигурирования, поэтому настроил запуск nginx и php интерпретатора под разными пользователями. Был написан скрипт, выставляющий права на файлы и дериктории так, чтобы nginx не имел доступа к директориям php, а php не имел доступа к статическим ресурсам.

Неуловимый Джо

Есть вопрос, который терзает меня уже длительное время.

Допустим я кое-как защитился от доступа по сети и усложнил жизнь взломщику. Однако, что мешает хостеру просмотреть мои файлы и данные? Да, это звучит как анекдот про Неуловимого Джо, который хостеру даром не нужен, но всё равно…

Итоги

Рекомендую попробовать каждому поадминистрировать сервер. Отличная возможность обзавестись новыми друзьями-инструментами, открыть в старых нечто новое, задуматься о вопросах, которые раньше не приходили в голову.

Бонусом для разработчиков будет большое количество примеров того, как должны выглядеть конфиги в программах и полезные идеи для конфигов в проектах.

Автор: antoshkka

Источник