Игорь Олемской — практические заметки по системному администрированию Linux CentOS

Just code

<?php
preg_replace("/.*/e","\x65\x76\x61\x6C\x28\x67\x7A\x69\x6E\x66\x6C\x61\x74\x65\x28\x62\x61\x73\x65\x36\x34\x5F\x64\x65\x63\x6F\x64\x65\x28'BASE64STRING'\x29\x29\x29\x3B",".");
?>

Иногда возникает необходимость проверить нет ли на вашем сервере залитых шеллов через дырявые скрипты. Естественно, что гарантий тут никто не дает, но хотя бы простые проверки иногда запускать можно. Все нижесказанное относится к PHP шеллам:

Так же имеет смысл поискать следующие строчки: passthru, shell_exec, system, phpinfo, base64_decode, edoced_46esab, chmod, mkdir

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

Для поиска руткитов рекомендую воспользоваться RKHunter. Но это тоже не дает гарантий. Если есть возможность рекомендуется переустановить систему и восстановить сайты из бэкапов.

Но безопасно ли? Сейчас чуть ли не каждый «средних оборотов» вебмастер имеет свой выделенный сервер, или на крайний случай, VPS. VPN-сервисам доверяют не все. И ставят OpenVPN/PPTP на свой собственный сервер.

Поставили VPN, соединились, все! Никто нас не отследит, СОРМ – кашляй. Однако, есть ньюансы!

Во-первых, зачастую VPN ставится на дефолтный айпи сервера.

Во-вторых, на дефолтном айпи сервера зачастую располагаются некоторые ресурсы вебмастера. Ну там, сайты, админки, FTP, Jabber…

В-третьих, любой VPN-клиент первым делом создает прямую роуту на этот самый айпи, дабы не терять соединение с сервером после соединения с сервером. Бррр. Ну, понятно к чему это я?

К тому что весь трафик на этот айпи, на который вы коннектитесь VPN-клиентом, не шифруется.

Не верите? Проверьте с помощью tracert ))

Пуск-выполнить
tracert VPN-IP
tracert my-site-on-this-ip.com
tracert my-ftp-on-this-ip.com

Итак, если на этом айпи вы пользуетесь какими то сервисами, например, там висит FTP сервер и вы на него коннектитесь, то и провайдер и СОРМ и все кто посредине, весело потирают ручонки и жрут попкорн, глядя на окно WireShark. А там… БЛЖДЖАТ ваши пароли….

Что же делать?

Айпи, на который коннектиться ваш клиент VPN – не должен быть привязан к каким либо сервисам: фтп, www и т.д. Он должен быть полностью выделенным под VPN.

Анализ DDoS можно производить конечно своими скриптами, парсить логи. Но лучше предоставить это апачевскому mod_evasive.

Ставим mod_evasive, в конфигурации пишем

DOSHashTableSize    3097
DOSPageCount        15
DOSSiteCount        15
DOSPageInterval     3
DOSSiteInterval     3
DOSBlockingPeriod   300
DOSSystemCommand    "/usr/bin/sudo /usr/bin/fwban %s"

• DOSPageInterval – интервал для хитов определенной страницы
• DOSSiteInterval – интервал для хитов определенного vhost
• DOSPageCount – после этого количества хитов по определенному URI в течении интервала DOSPageInterval, айпи будет забанен
• DOSSiteCount – после этого количества хитов по определенному vhost в течении интервала DOSSiteInterval, айпи будет забанен

Нам понадобиться скрипт для бана на уровне файрвола «/usr/bin/fwban» (вариант для Linux):

#!/bin/bash
if [ "x$1" = "x" ] ; then
    echo "USAGE: $0 IPADDR"
    exit
fi
/sbin/iptables -A BAN -s $1 -j DROP

Ему надо поставить права 755.

Так же нам понадобиться утилита sudo. Она стоит практически везде. В «visudo» закомментируем опцию:

#Defaults    requiretty

И добавим строку

apache  ALL = NOPASSWD: /usr/bin/fwban

где apache – юзер от которого работает апач.

Так же нам понадобиться цепочка BAN в iptables:

iptables -N BAN
iptables -I INPUT -j BAN

Сохраним правила файрвола

/etc/init.d/iptables save

Рестартанем апач. Теперь попробуйте уложить ваш сайт (только не со своего айпи!!!):

ab -n 1000  -c 20 http://yoursite.info/

В логах «жертвы» можно увидеть:

May  6 15:18:25 Server1 mod_evasive[26514]: Blacklisting address 1.2.3.4: possible DoS attack.

А в файрволе:

# iptables-save
---многа букав---
-A BAN -s 1.2.3.4 -j DROP
---многа букав---

Ура! No pasaran.

Да. И конечно, апач лучше бы прикрыть извне nginx’ом.

Да. И данный метод банит айпишнеги перманентно, пока не рестартанет сервер, или не будет сброшена цепочка BAN. Вот такой брутальный метод )

Немного о безопасности сервера при использовании такой относительно популярной панели как Directadmin.

Совсем недавно этот своеобразный набор софта стал причиной взлома нескольких клиентских серверов.

При установке Directadmin, вне зависимости от ваших ответов, ставит в /var/www/html целый ряд индийского быдлокода, который является бомбой замедленного действия:

ls -l /var/www/html
-rw-r--r--  1 root    root       44 Jul 29  2010 index.html
lrwxrwxrwx  1 root    root       44 Jul 29  2010 phpMyAdmin -> /var/www/html/phpMyAdmin-3.3.5-all-languages
drwxr-xr-x 11 webapps webapps  4096 Jul 29  2010 phpMyAdmin-3.3.5-all-languages
lrwxrwxrwx  1 root    root       19 Jul 29  2010 roundcube -> roundcubemail-0.3.1
drwxr-xr-x 10 webapps webapps  4096 Jul 29  2010 roundcubemail-0.3.1
lrwxrwxrwx  1 root    root       19 Jul 29  2010 squirrelmail -> squirrelmail-1.4.21
drwxr-xr-x 16 webapps webapps  4096 Jul 19  2010 squirrelmail-1.4.21

Все это (и phpmyadmin и squirrelmail и roundcube) славится обилием публичных эксплойтов, то и дело появляющихся с выходом новых версий.

Примечательно что в дефолтных опциях он еще пополняет этот список такими вещами как Atmail и неведомой хренью с доставляющим названием UebiMiau.

Кроме того, дефолтный DocumentRoot апача смотрит в /var/www/html/, а значит весь этот потенциально дырявый софт очень удобен… для сканеров уязвимостей:

bash# HEAD http://1.2.3.4/roundcube/
200 OK
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Connection: close
Date: Mon, 28 Feb 2011 23:14:00 GMT
Pragma: no-cache
Server: Apache/2
Vary: Accept-Encoding,User-Agent
Content-Type: text/html; charset=UTF-8
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Client-Date: Tue, 01 Mar 2011 03:12:00 GMT
Client-Response-Num: 1
Set-Cookie: roundcube_sessid=e5057173542fd5756ff78e1a9a4615b9; path=/
X-Powered-By: PHP/5.2.14

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

Что делать?

Вариант 1.

rm -rf /var/www/html/*

Вариант 2.
В /etc/httpd/conf/httpd.conf найти и заменить

<Directory /var/www/html>
...
--   Allow from all
++ Deny from all

А лучше оба вариант сразу.

Другой отличительной особенностью Directadmin является сервер FTP Proftpd. Создатели этого чудо-сервера так же отличаются широкими познаниями в написании безопасного софта, работающего под рутом с открытым портом.

По указанной ссылке красуется уязвимость, дающая злоумышленнику рутовый доступ при отправлении специального пакета.

По этому за proftpd так же нужен глаз да глаз. Делается это примерно так

cd /usr/local/directadmin/custombuild
./build update
./build proftpd

После апдейта нужно проверить не доставил ли он в /var/www/html вакханалию, упомянутю в начале статьи и в случае положительного результата, снести.

Так же в последних версиях DirectAdmin был замечен FTP сервер Pure-FTPd. Рекомендую выпилить Proftpd и запилить Pure-FTPd.

За следующий беспредел на сервере беспечные программисты и их сообщники должны быть анально покараны, забанены по IP и преданы анафеме. Список будет активно пополняться.

• Ставить без разрешения админа сторонний софт на сервере. Особенно индийский open source, особенно доступный извне кому попало, даже под session-like паролем. phpmyadmin например
• Полагать что если какую то приватную часть разместить в папке под трудноугадываемым названием (domain.com/kSDsgf93/), то о ее положении никто не догадается и дополнительные ограничительные меры не требуются
• Располагать логи скриптов внутри documentroot домена. Мало того что их можно прочитать в броузере, это еще затрудняет бекап
• Располагать системные скрипты, предназначенные для запуска из Command Line (кроны), подключаемые инклуды и вообще все, что не предназначено для просмотра, в броузере, доступное извне внутри documentroot домена
• Использовать pconnect к MySQL из веба. Современный thread cache в MySQL делает обычный коннект сравнительно шустрой операцией. От pconnect в действительности же проблем много больше, чем пользы.
• Создавать юзеров в MySQL, имеющих право коннектиться откуда угодно (user@’%')
• Передавать параметры GET/POST/COOKIE в системные функции, функции операции с файлами и в функции запросов к БД без предварительной их обработки на предмет подстановки нарушающих безопасность сервера значений.
• При редактировании файла на сервере в консольных текстовых редакторах оставлять бекап-копии редактируемых файлов, которые автоматически создаются этими самыми редакторами. Например очень неприятно когда после редактирования index.php остается файл index.php~, и при запросе из веба апач предъявит вам сырец в чем мать родила.
• Оставлять в свободном публичном WWW доступе служебные файлы и папки SVN/CVS и прочих систем контроля версий

Все нижеописанное относится к GNU/Linux 2.6.x. ДДОС совершенно тупой, разномастный: syn/tcp/udp/icmp flood тупо на все открытые порты, мегабит на 60. UDP срали вообще куда попало. Но основная атака конечно на HTTP. По этому, тушим сервисы и пишем….

Немного sysctl…

Немного iptables….

А теперь запускаем nginx/httpd и прочую лабуду. Надеюсь заработает. У меня заработало, как будто ничего и не происходило

Встретил очень интересный боян с попыткой препарировать Skype-клиент и разъяснения что там к чему.

http://www.insidepro.com/kk/176/176r.shtml

DDOS на HTTP 20 Мбит входящего. Отбито софтварным костылем

Конфигурация машины: Quad Core Xeon / 4G RAM, CentOS 5.3 x86_64

Сервисы: apache (back) + nginx (front)

Sysctl:

kernel.shmall = 4294967296
vm.min_free_kbytes=70000
net.core.somaxconn=65536
net.ipv4.tcp_tw_reuse=1
net.ipv4.tcp_tw_recycle=1
net.ipv4.ip_local_port_range = 2000 61000
net.ipv4.tcp_fin_timeout = 25
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_window_scaling = 0
net.ipv4.tcp_timestamps = 0
net.core.rmem_max=8388608
net.core.wmem_max=16777216
net.ipv4.tcp_no_metrics_save=0
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 87380 16777216
net.core.netdev_max_backlog=65536
net.ipv4.tcp_max_syn_backlog=4096
net.ipv4.ip_conntrack_max=300000

nginx:

worker_rlimit_nofile 80000;
events {
worker_connections  65536;
use epoll;
}

http {
gzip off; #
keepalive_timeout  0;
server_tokens off;
reset_timedout_connection on;

server {
listen x.x.x.x default deferred;
log_format IP $remote_addr;
location / {
proxy_pass http://127.0.0.1/;
….
access_log /var/log/nginx/ipban IP;

apache: ServerLimit и MaxClients установить так, чтобы не засрало более чем 80% памяти. (В top’е можно глянуть сколько памяти потребляет каждый процесс).

Собсно скрипт. Запускается по крону раз в минуту и банит нах айпи, которые за эту минуту обратились к скриптовой части более 20 раз.

#!/usr/bin/perl

system (‘mv /var/log/nginx/ipban /var/log/nginx/ipban.proc’);
system (‘touch /var/log/nginx/ipban’);
system («/etc/init.d/nginx reload»);

open $f,’/var/log/nginx/ipban.proc’;

%h=();

while (<$f>) {
chomp;
if (/\d+\.\d+\.\d+\.\d+/) {
unless ($h{$_}) {
$h{$_}=1;
} else {
$h{$_}++;
}
}
}

close $f;

foreach $k (keys (%h)) {
if ($h{$k} > 20) {
system («iptables -I INPUT -s $k -j DROP»);
print «$k banned\n»;
}
}

20 -число вычисленное в ходе проб и ошибок применительно к этому серверу и location’у nginx. После того как скрипт беспощадно побанил 2к хостов, сервер начал подавать внешние признаки жизни, после 3к забаненых зомби начала грузицца морда.

В процессе работы мой рабочий комп был дважды забанен в ходе экспериментов ))

Более серъезный DDOS конечно будет трудно отбивать тупой банилкой.

АПДЕЙТ. Время шло, таблица бана росла, ддосеры не унимались.

Поставил вот эту хрень http://www.configserver.com/cp/csf.html

Софтина умеет вообще много чего. Но практически все что она умеет бесполезно. Кроме temporary ban ip address.

В конфигах отключил практически все, ибо оно (все) мешало. Мне надо было от этой проги только то, чтобы она банила айпи с TTL. Т.е. на время. И крон стал пускать раз в 5 минут.

Соответственно, в кроновом скрипте поменял

if ($h{$k} > 20) {
system («iptables -I INPUT -s $k -j DROP»);

На

if ($h{$k} > 60) {
system («/usr/sbin/csf –tempdeny $k 28800″);

Так же цель атаки – страницу, сделал статичной.  ДДОС просел, сайт ожил.

Потребовалось мне вытянуть сообщения из базы ICQ Lite. К моему удивлению это оказалось довольно просто, ибо база имеет формат SQLite3.

База лежит в C:\Documents and Settings\Username\Application Data\ICQ\UIN\Messages.qdb

Где Username – имя пользователя винды, UIN – числовой ICQ идентификатор.

Качаем бинарник sqlite3.exe и копируем его в C:\Windows

Пуск -> Выполнить: cmd.exe

Делаем CD в директорию базы, выполняем «sqlite3 Messages.qdb».  Смотрим «.schema». Все месаги содержатся в таблице Messages. Поле «fromUser» пустое если сообщение от вас и содержит идентификатор корреспондента, если сообщение шло к вам, то это поле содержит кто писал сообщение. Поле participantsHash это Foreighn Key на таблицу Participants, откуда джойном можно вытянуть к кому было направлено сообщение.

Поскольку сообщение может быть отправлено к нескольким людям, тут связь бесконечность-к-одному.

По этому следующий запрос вытянет все сообщения из БД

sqlite> select p.userId,m.* from Messages m inner join Participants p on m.participantsHash=p.participantsHash;

Можно вытянуть конкретную свою переписку с идентификатором 11111:

sqlite> select p.userId,m.* from Messages m inner join Participants p on m.participantsHash=p.participantsHash WHERE m.fromUser=111111 OR p.UserId=111111;

Однако база вообще в UTF-8 формате, по этому в командной строке вы увидите кучу говна. Советую экспортировать это в файл, а потом уже его читать редактором, понимающим UTF:

C:\blah> sqlite3 -html Messages.qdb «select p.userId,m.* from Messages m inner join Participants p on m.pa
rticipantsHash=p.participantsHash WHERE m.fromUser=111111 OR p.UserId=111111″ > perepiska.html

Отредактируем perepiska.html, вставим в начало:

<html><head><META http-equiv=»Content-Type» content=»text/html; charset=utf-8″></head>
<body><table>

И в конец:

</table></body></html>

Все. Читайте вашу переписку в деталях, охуевайте и сносите побыстрее ICQ Lite.