Разгружаем и защищаем север nginx с помощью fail2ban

Разгружаем и защищаем север nginx с помощью fail2ban

Задача: простыми для самоучки средствами максимально разгрузить сервер и/или ВДС-ВПС от множества дурных запросов.

Два вида паразитных запросов:

• роботы как роботы
• роботы как люди

Вводная: роботы как люди хитрят и меняют:

• юзерагент через 5-100 запросов, но ИП меняют редко;
• ИП через 5-100 запросов, но юзерагент меняют редко;
• лимитировать по числу коннектов и/или их скорости/частоте не хочется, потому что в век скоростного интернета и 128 поточных браузеров потеряем много юзеров и гуглоботов.

Идея:

• роботам как роботам сразу отдаём ошибку 444 по юзерагенту;
• роботам как людям сразу отдаём ошибку 444 по специфичным подстрокам в URI запроса;
• баним найденные ИП на часок, чтобы робот отдохнул и выкинул наш сервер из своей базы данных.

Реализация:

Прочитать полностью...

Test VDS-VPS vs Dedicated Server by HDD

Чем отличается VDS-VPS (XEN 3.1GHz, ОЗУ 256MB, диск 15Gb, Канада) за 10 баксов от Dedicated Server за 10 баксов (Atom N2800 1,86 GHz, ОЗУ 2Gb, диск 500Gb, Франция)?

Методика тестирования:

идем в темп:

cd /tmp

создаем файлик из 16384 кусочков по 65536 байтиков, примерно будет 1 гигабайт:

dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync

на сервере за 10 баксов получим (не останавливая nginx и имея 100 PHP вызовов в секунду):

16384+0 records in
16384+0 records out
1073741824 bytes (1.1 GB) copied, 10.1663 s, 106 MB/s

уберем мусор за собой:

rm -f test

на VDS-VPS за 10 баксов получим:

1073741824 bytes (1.1 GB) copied, 270.881 seconds, 4.0 MB/s

при остановленном nginx (соответсвенно PHP-FPM тоже ничего не делает):

1073741824 bytes (1.1 GB) copied, 127.868 seconds, 8.4 MB/s

Вывод: нунах эти ВДС. К тому же на VDS-VPS за постоянную большую нагрузку на процессор/диск/сеть вас погонят и на XENe тоже, хотя и не так быстро как на OpenVZ.



И да, Ceterum censeo Moskva esse delendam! Прочитать полностью...

Защита nginx на сервере

Защита nginx на сервере многогранна.

Одна из граней, пока у нас не увели рута или юзера с правами рута, то логи nginx нужно обогатить:

if ($request_method ~ "^POST$") {
    access_log /var/log/nginx/access-POST-$server_name.log main_post;
}
if ($request_method ~ "^(PUT|OPTIONS|HEAD|PATCH|DELETE|TRACE|CONNECT)$") {
    access_log /var/log/nginx/access-PUT-$server_name.log main_post;
}

ну и:

log_format main_post '$remote_addr [$time_local] $host "$request" '
    '$status $body_bytes_sent [$request_body] "$http_referer" '
    '"$http_user_agent"';

ну и client_body_buffer_size в /etc/nginx/nginx.conf установить как вам нужно, чтобы ваши запросы помещались, а хакерские нет :)
или наоборот, ставьте побольше, чтобы любой хакерский запрос поймать.

и защитить:

chown nginx:nginx /var/log/nginx
chmod 200 /var/log/nginx

последнее особенно удивительно для меня, самоучки, но логи пишутся, а больше убирать там нечего :)

UPDATE уже ночью
логи то пишутся, но после рестарта nginx хочет прочитать старое, чтобы добавить новое и не может.
поэтому

chmod 600 /var/log/nginx

и наблюдаем дальше...

И да, Ceterum censeo Lugansk esse delendam! Прочитать полностью...

Защита PHP на сервере

По следам наших выступлений раз, два.

Я считаю обязательным  в файле /etc/php.ini установить disable_functions = длинный список функций под катом


Прочитать полностью...

Второй хакер на новом сервере results@hackermail.com

Второй хакер на новом сервере results@hackermail.com
Аваст называет его PHP:BackDoor-DJ [Trj]
Смог только залить псевдогифку в /tmp/ но уже не gzip, а просто PHP в виде гифки.
первый заливал сжатый PHP:Shell-HP [Trj]
И да, Ceterum censeo Lugansk esse delendam! Прочитать полностью...

Если fail2ban в письме пишет "missing whois program"

Если fail2ban в письме пишет "missing whois program"

Проверяем из консоли

# whois 11.22.33.44
-bash: whois: command not found

Это значит, что нужно поставить jwhois. Для CentOS это

# yum install jwhois
 
    Installed: jwhois.x86_64 0:4.0-19.el6




И да, Ceterum censeo Lugansk esse delendam! Прочитать полностью...

Первые хакеры на новом сервере

Поздравь хакера с Новым 2015 годом по одному из адресов:

citiexplosion2013@gmail.com
sarna_p@yahoo.com
bebeshark@live.com

На новом сервере, я ещё не успел им похвастаться, залили псевдогифку в /tmp/

Вот под катом её PHP текст уже после расшифровки, текстовки на индонезийском языке

Апдейт 05/01/2014

Аваст спустя 10 дней от начала этого безобразия обновился :) и стал называть это "PHP:Shell-HP [Trj]" и блокировать, поэтому текст я убрал. Если кому-то нужно - вставлю картинкой.

Прочитать полностью...

Как чинить проблемы SSHD в Centos 6

Как чинить проблемы SSHD

Если ваша Путти внезапнно вместо логина на сервер по паре ключей пишет в консоли:

Using username "root".
Server refused our key
root@8.8.8.8's password:

А в логе путти вы видите:
2014-12-10 12:17:15 Offered public key
2014-12-10 12:17:15 Server refused our key
2014-12-10 12:17:15 Using SSPI from SECUR32.DLL
2014-12-10 12:17:15 Attempting GSSAPI authentication
2014-12-10 12:17:16 GSSAPI authentication request refused

Это значит, что: караул, меня взломали, я разорен или что настала пора что-то полечить.

1. если вы раньше отключали ведение логов для экономии ресурсов, то нужно убедиться в том, что сейчас работает демон rsyslogd, без него не пишется /var/log/secure и следовательно не работает fail2ban между прочим
# ps axfu
где-то есть такое /sbin/rsyslogd -i /var/run/syslogd.pid -c 5
service rsyslog start
chkconfig rsyslog on
2. включить дебаг лога SSHD
\etc\ssh\sshd_config
разремить или добавить
LogLevel DEBUG3
в районе
#LogLevel INFO
3. За одно проверить
#AuthorizedKeysFile .ssh/authorized_keys
обратите внимание, что путь будет строиться от домашнего каталога юзера! Вам тут исправлять вот так
AuthorizedKeysFile /root/.ssh_t/authorized_keys
не нужно!
4. читать логи, если там есть
key_type_from_name: unknown key type 'ssh-dsa'
key_read: missing keytype
то внимательно проверить файл с публичным ключем, в моем случае было ssh-dsa.... вместо ssh-dss....
а если бы я выбрал ключик попроще RSA, то такой проблемы не было бы :)
желательно в конце ключа через пробел после == дописать что-то типа john@example.net
5. Вывод - выбирайте тип RSA и генерируйте ключи на сервере, потому что при переносе ключа из Putty в \root\.ssh\authorized_keys больше шансов ошибиться, чем при скачивании приватного ключа с сервера на локальный комп.
5. Инструкция
Создаем папку
$ mkdir ~/.ssh
$ chmod 700 ~/.ssh
Генерируем ключи
$ ssh-keygen -t rsa
и три раза Энтер
Создаст
~/.ssh/id_rsa приватный ключ
~/.ssh/id_rsa.pub публичный ключ
$ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
$ chmod 600 ~/.ssh/authorized_keys
Теперь нужно стащить ~/.ssh/id_rsa (приватный ключ) в программу puttygen.exe и сохранить в формате Путти. Потом подключить к Путти...
Проверим права и владельцев по всему пути
namei -om /root/.ssh
SSHD строго следит за минимально необходимыми правами. Ставить везде 777 и 666 нельзя.
Если это ВДС под OpenVZ, то потребуется восстановить владельца:
restorecon -Rv /root/.ssh
Припрячем ключ на будущее
$ chmod 600 ~/.ssh/id_rsa
Или уберем за собой, смотря кому как нужно
rm ~/.ssh/id_rsa
rm ~/.ssh/id_rsa.pub


Полезное чтиво http://wiki.centos.org/HowTos/Network/SecuringSSH Прочитать полностью...

mc Крякозаблы вместо псевдографики

Для борьбы с крякозаблами вместо псевдографики в mc обычно делают так
/etc/sysconfig/i18n
LANG="en_US.UTF-8" --> LANG="ru_RU.koi8r"
ИЛИ
LANG="en_US.UTF-8" --> LANG="ru_RU.UTF-8"

но тогда гадостным обазом половина сообщений операционной системы Centos становятся на русском языке, что сильно затрудняет обращение в нерусский саппорт :)

Оказалось, что эту псевдографику в mc можно победить одной командой:

unicode_start

И никакого русского языка :)

Это ещё не всё... Прочитать полностью...

mc Cannot open master side of pty: No space left on device (28)

Арендовал я месяц назад выделенный сервер потому что ВДС мне уже не хватает по производительности. Вроде всё так же, но какие-то гадости вылазят. Напишу их тут, чтобы потом легче искать было.

Гадость 1.

Midnight Commander, он же mc, после запуска и закрытия оставляет сообщение

Cannot open master side of pty: ▒▒ ▒▒▒▒▒▒▒▒▒▒ ▒▒▒▒▒▒▒▒▒ ▒▒▒▒▒ (28)

Решетки это из-за сломавшегося \etc\sysconfig\i18n - это ещё одна гадость от mc
Под решетками имеется в виду так:

Cannot open master side of pty: No space left on device (28)

Решение простое:
#mkdir /dev/pts
#mount /dev/pts

ну и дописать в автозагрузку в /etc/rc.d/rc в самое начало или в /etc/rc.d/rc.local куда угодно
mkdir /dev/pts
mount /dev/pts

----------------------------
другие рецепты не помогали:
«Cannot open master side of pty: No such file or directory (2)
Прежде всего убедитесь, что в /etc/fstab присутствует запись вида:
none /dev/pts devpts mode=0620 0 0
Если нет - добавляем и выполняем под пользователем root:
#mount -a
Если нет идем дальше: Можно запустить strace и посмотреть, что идет не так. Но вероятнее всего ошибка возникает при обращении к /dev/urandom и/или /dev/ptmx.
бла бла бла про OpenVZ.

И это не помогло
Если devpts все же примонтирована, а ошибка сохраняется, возможно отсутствует файл /dev/ptmx
создадим его:
mknod /dev/ptmx c 5 2
chmod 0666 /dev/ptmx
chown root.tty /dev/ptmx


Это ещё не всё... Прочитать полностью...

"На локальном компьютере все работает нормально, а на сервере не работает"

"На локальном компьютере все работает нормально, а на сервере не работает."

Пост лютой ненависти сука к Микрософт Виндовсу.

Сделал сайт, протестировал на локальном компьютере - всё работает, залил на сервер - не работает кусок яваскриптов. Ну там сепермегакруто и красиво на JQuery.ajax и все дела, кроссбраузерность, адаптивный дизвйн, красота охуительная и для людей и для роботов. Такое дело даже дором не удобно называть, хотя это дор :)

Так вот, на сервере не работает. А я в этих ваших яваскриптах и аяксах джейКваери (так это по-русски читается?) разбираюсь чуть лучше чем нихуя никак. В общем половину дня потратил, инет начал читать, пока не нашел пост такого же оболдуя как и я.

Итого.

Для винды jquery.prettyPhoto.js и jquery.prettyphoto.js одно и то же, а вот для никсов - нихуя. Блядь, я же знал, я помнил, я всегда именовал всё сам нормально, но тут пизженый код и не взлетело - вот и наказание, карма блеать.

Удалить из ридера
никого, а вот добавить свежего надо http://lime.black/ - читайте пока он пишет и не упекли его в пироженницу :) Прочитать полностью...

Unix nginx open() failed (13 permission denied)

Если вдруг на вашем любимом сервере NGINX + PHP-FPM после безобидных на первый взгляд действий перестали открываться все сайты с ошибкой 403 "HTTP/1.1 403 Forbidden", а в логе nginx пишет примерно такое даже при обращении к серверу по IP:

2014/11/15 13:46:58 [error] 25908#0: *27341 open() "/home/pupkin/www/5.6.7.8/index.html" failed (13: Permission denied), client: 1.1.1.1, server: 5.6.7.8, request: "GET /index.html HTTP/1.0", host: "5.6.7.8"

И вы уже проверили владельца папки и права доступа ко всему, что только можно, то пришло время проверить прова на переход по папкам сверху вниз командой namei -om ( owner + mode ), примерно так:

namei -om /home/pupkin/www/5.6.7.8/index.html

получите:

f: /home/pupkin/www/5.6.7.8/index.html
drw-r--r-- root root /
drwxr-xr-x root root home
drwx-----x pupkin users pupkin
drwxr-xr-x pupkin users www
drwxr-xr-x pupkin pupkin 5.6.7.8
-rw-rw-r-- pupkin pupkin index.html

Обратите внимание на первую строку. Если в процессе ваших настроек вы случайно дали команду

chmod 644 /

т.е. хотели какому-то файлу поставить права 644, но путь к файлу куда-то пропал и остался только путь к корню.

Лечится очевидно:

chmod 755 /

или более умно, мне помогло так.

Удалить из ридера
http://dmxo.blogspot.com/ - был блог и пропал автор навсега в 2012 году Прочитать полностью...