Аудит безопасности

5 Августа 2016 23 мин

Статья давно не обновлялась, поэтому информация могла устареть.

Содержание

1 Общая информация
2 Сервер взломан
- 2.1 Взломали сайт
- 2.2 Взломали сервер (захватили права пользователя или root)
3 Сервер не взломан. Аудит безопасности
- 3.1 Проверка сервера:
- 3.2 Проблемы безопасности сервера:
4 Общие рекомендации
5 Cheat-Sheet

Общая информация

Данная статья делится на 3 части:

- В первой рассматривается порядок действий в ситуации, когда взломан сервер.

- Во второй рассматривается порядок действий, которые нужно предпринять, чтобы обезопасить сервер от взлома (аудит сервера).

- В главе 3 “Общие рекомендации” вынесены пункты, общие для двух первых глав.

- В конце статьи представлен cheat-sheet, содержащий краткий перечень необходимых команд.

Перед проведением аудита/очистки необходимо убедится в отсутствие нестандартных настроек сервисов, сделанных в обход панели.

Если какие-то файлы необходимо удалить в ходе проверки, необходимо делать резервные копии файлов.

Работы, проводимые нами на сервере, соответствуют “Guide to the Secure Configuration of Red Hat Enterprise Linux 6″ (“Руководство по конфигурации безопасности Red Hat Enterprise Linux 6), опубликованного Национальным Агенством Безопасности США.

NSA Security Configuration Guides

Red Hat Enterprise Linux 6 Security Guide

Securing Debian Manual

Сервер взломан

Взломали сайт

Признаки:

- Спам-активность с сервера;

- Дефейс;

- Редиректы с сайта;

- Увеличенный поток трафика;

Нередко признаком взлома является 200 код на нерабочих (не отдающих контент) скриптах.

Действия в данной ситуации можно разделить на 3 шага:

- Выясняем последствия и “глубину” взлома;

- Выясняем причины взлома;

- Проводим очистку.

Шаг 1. Выясняем последствия и “глубину” взлома

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

http://antivirus-alarm.ru/

http://online.drweb.com/?url=1

- ищем файлы за последние 10 дней (либо корректируем время, если оно нам известно):

# find /home/user/data/www/site.ru/ -type f -mtime -10

- проверяем почтовую очередь на наличие спама

- проверка сайта скриптом ai-bolit.

Достаточно интересный и мощный скрипт. Качаем отсюда:

http://www.revisium.com/ai/

Разархивируем, меняем пароль в строке define('PASS', 'put_any_strong_password_here'),

запускаем скрипт. Внимательно изучаем вывод скрипта, делаем резервные копии файлов, приступаем к очистке.

- проверка файлов во временных директориях и директориях загрузки:

# find /home/user/data/www/site.ru/ -type d \( -iname '*upload*' -o -iname '*tmp*' \) - ищем временные директории

# file /home/user/data/www/site.ru/uploads/* | grep -i php - ищем php-файлы в этих директориях

Цель проверки - найти php скрипты во временных и общих директориях.

Если скрипты найдены, вероятнее всего, это вредоносы. Во временных и общих директориях их быть не должно.

- ищем .htaccess и проверяем на наличие редиректов

# find /home/user/data/www/site.ru/ -type f -iname '*htaccess' -exec grep -i rewrite {} \;

- ищем шеллы и вирусы вручную:

# egrep -ril “base64_decode|auth_pass|shell_exec” /home/user/site.ru

Паттерны для поиска, чаще всего, следующие:

FilesMan, try{document.body, String["fromCharCode"], auth_pass, fromCharCode,
shell_exec, passthru, system, base64_decode, chmod, passwd, mkdir,
eval(str_replace, eval(gzinflate, ="";function, "ev"+"al",md5=,ss+st.fromCharCode, e2aa4e

Шаг 2. Выясняем причины взлома

Причины взлома сайта, чаще всего, следующие:

- Устаревшие CMS/Модули CMS;

- Неправильные настройки прав;

- Утерянные аккаунты ftp/ssh;

- Уязвимые скрипты сайта.

- проверяем актуальность CMS и проверяем соседние сайты того же пользователя или с теми же CMS

- проверяем права на директории сайта

- смотрим, когда были залиты шеллы:

# stat shell.php

- ищем в access-логах сайта обращения к скриптам шелла. При найденных строках, ищем в логах обращения к сайту по IP, с которого обращались к скрипту. Таким образом можно обнаружить уязвимости в скриптах или модулях CMS/Сайта.

# grep shell.php /var/www/httpd-logs/site.ru.access.log

- проверяем наличие крон-заданий для пользователя и root:

# egrep -ri ‘wget|sh|fetch|curl’ /var/spool/cron

- проверяем логи ftp и ssh

Находим конфигурационный файл syslog.conf/rsyslog.conf и смотрим куда записываются события auth, authpriv.

Эти логи необходимо проверить на наличие успешных попыток ввода.

# grep -i accept /var/log/secure

Также необходимо проверить логи ftp - xferlog:

# awk ‘($12~/i/){print}’ /var/log/xferlog - покажет все файлы, которые были залиты по ftp.

Если нам известно время и имя скрипта, искать стоит по этим параметрам.

Шаг 3. Проводим очистку

- если в ходе проверки обнаружены устаревшие CMS, необходимо обновить CMS;

- количество необходимых модулей должно быть сведено к минимуму;

- проверяем наличие безопасных настроек php в php.ini

- файлы, что были найдены на шаге 1 необходимо проверить вручную. Для этого открываем url в браузере и убеждаемся, что это шелл;

- анализируем найденные скрипты. Делаем резервные копии. Если в скриптах, что мы нашли на шаге 1 всего лишь вставки, пробуем очистить их вручную, например так:

@preg_replace («\x40\50\x2e\53\x29\100\x69\145»,"\x65\166\x61\154\x28\142\x61\163\x65\66\x34

удалится с помощью команды

# sed -i 's/@preg.*34//g' infected.js

- проверяем результат очистки скрипта. Если скрипт не работает, разворачиваем резервную копию;

- если скрипт, что мы нашли на шаге 1 целиком является шеллом, делаем резервную копию файла и удаляем скрипт.

Взломали сервер (захватили права пользователя или root)

Признаки:

- Спам-активность с сервера;

- Сетевая активность/Блокировка VDS;

- Проблемы в работе VDS.

Действия в данной ситуации можно разделить на 3 шага:

- Выяснить последствия и “глубину” взлома;

- Выяснить причину взлома;

- Проводим очистку;

Шаг 1. Выяснить последствия и “глубину” взлома

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

Необходимо вручную просмотреть вывод ps и top. Если обнаружены неизвестные процессы, необходимо определить, откуда они были запущены. Для этого поможет команда:

# ls /proc/PID/cwd - для процесса с pid’ом PID покажет окружение директории, из которой был запущен файл.

Также можно воспользоваться утилитой find, чтобы найти исполняемый файл.

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

# stat shell

Выяснить, что это за файл поможет утилита strings.

# strings shell - покажет строки, которые содержит бинарный файл.

Дальнейший анализ требует глубоких познаний реверс-инженеринга и в данной статье не рассматривается.

- проводим анализ сервера на наличие бэкдоров и руткитов с помощью rkhunter

- проверяем почтовую очередь и причины ее возникновения

- проверяем сервер на наличие неизвестных сетевых соединений и портов;

# netstat -tuplnw | awk '{print $4,$NF}' | sort | uniq

- необходимо проанализировать все крон-задания для root и других пользователей:

# egrep -ri ‘wget|sh|fetch|curl’ /var/spool/cron

Шаг 2. Выяснить причину взлома

Причины взлома сервера, чаще всего, следующие:

- Устаревшее (уязвимое) ПО на сервере;

- Утерянные или слабые пароли;

- Неправильная конфигурация ПО;

Основную информацию стоит искать в системных логах сервера. В случае, если логи были удалены или стерты, необходимо искать причины по косвенным признакам.

- ищем успешные попытки авторизации по ssh:

# egrep -i "accept|success" /var/log/secure

# grep -i accept /var/log/auth.log

- проверяем сервер на наличие устаревшего/уязвимого ПО

- проверяем history-файл пользователя на наличие подозрительных действий.

- ищем попытки выполнения в панели административных функций. Для этого смотрим в лог панели и ищем следующие функции:

файл /usr/local/mgr5/var/ispmgr.journal

root admin.edit - изменение параметров учетной записи администратора

файл /usr/local/mgr5/var/ispmgr.log

[IP][root] ‘’ - успешная авторизация пользователя root

‘auth’ Object: ‘badpassword’ Value: ‘’ - безуспешная авторизация пользователя root

# grep "admin.edit" /usr/local/mgr5/var/ispmgr.journal && \

egrep “\[root\] ‘’|badpassword” /usr/local/mgr5/var/ispmgr.log

если есть логи, которые поротейтились (/usr/local/mgr5/var/logs/*), выясняем, удовлетворяют ли они временным критериям и грепаем по ним:

# zgrep -Ei "admin.edit" /usr/local/mgr5/var/logs/ispmgr.journal.0.gz && \

zgrep -Ei “\[root\] ‘’|badpassword” /usr/local/mgr5/var/logs/ispmgr.log.0.gz

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

# stat file.c

# stat -x file.c

Шаг 3. Проводим очистку

- очищаем сервер от найденных шеллов и бэкдоров;

- обновляем устаревшее/уязвимое ПО;

- используем стойкие пароли. Описано здесь:

Безопасность_начинается_с_пароля

- открываем в файерволе только необходимые порты. Остальное закрываем;

- ограничиваем доступ в панель с определенных ip;

Сервер не взломан. Аудит безопасности

Проверка сервера:

Уровни обеспечения безопасности:

- Уровень приложений.

- Уровень ОС.

- Сетевой уровень.

Проблемы безопасности сервера:

1. Уровень приложений:

- проверка сайтов;

- некорректные файлы конфигураций;

- настройки панели;

- неиспользуемые сервисы;

- устаревшее ПО.

2. Уровень ОС:

- руткиты и проблемы конфигурации;

- настройки sysctl;

- настройка системы логирования;

- настройка монтирования.

3. Сетевой уровень:

- сетевые службы;

- firewall;

- ограничение доступа по ssh/ftp (restricted root).

Уровень приложений

Проверяем сайты

-проверяем актуальность установленных CMS

-проверка настроек php.ini

-проверка прав на директории сайта

Apache

- Проверяем наличие директив в конфигурационном файле apache:

 ServerTokens Prod

 ServerSignature Off

Если их нет, добавляем. Они позволяют отключить вывод информации о версии Apache.

- Проверяем наличие и содержимое файла secure.conf. Выглядеть он должен примерно так:

<Directory /home/*>

  Options +Includes -FollowSymLinks +SymLinksIfOwnerMatch

  AllowOverride FileInfo AuthConfig Limit Indexes Options

  Order allow,deny

  Allow from all

</Directory>

<IfModule php5_module>

  php_admin_value open_basedir "."

</IfModule>

<Directory /home/*/data/www/*/cgi-bin>

  Options -Indexes

</Directory>

Action php-cgi /php-bin/php

- Проверяем установленный MPM для apache:

mpm_itk выполняет скрипты от имени владельца сайта. Mpm_prefork в режиме “php как модуль apache” выполняет скрипты от пользователя apache (www, www-data) и от имени владельца сайта в режиме “php как cgi”. С точки зрения безопасности предпочтительно использовать mpm_itk.

Проверить, какой MPM установлен можно командой

# apachectl -V

Можно переустановить MPM для apache, предварительно сделав резервные копии конфигурационных файлов.

После переустановки необходимо проверить права на директории сайтов. Владельцем и группой-владельцем директорий должен быть пользователь.

NTP

- Запрещаем рекурсивные запросы (Защита от ntp-amplification)

restrict default kod limited nomodify notrap nopeer noquery
restrict -6 default kod limited nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict -6 ::1

Bind

В named.conf добавляем:

- Запрещаем рекурсивные запросы (Защита от dns-amplification)

allow-recursion {

    127.0.0.1;
    82.146.32.0/19;
    78.24.216.0/21;
    92.63.96.0/20;
    62.109.0.0/19;
    188.120.224.0/19;
    149.154.64.0/21;
    37.230.112.0/21;
    94.250.248.0/21;
 
};

Nginx

- Ограничиваем количество подключений с одного адреса

limit_zone slimits $binary_remote_addr 5m;

limit_conn slimits 10;

Для новых версий:

limit_conn_zone $binary_remote_addr zone=addr:10m;

limit_conn addr 10;

- Блокируем некоторые user-agent:

if ($http_user_agent ~* LWP::Simple|BBBike|wget|msnbot) {

              return 403;

          }

- Блокируем referal-spam:

    if ( $http_referer ~* (babes|forsale|girl|jewelry|love|nudit|organic|poker|porn|sex|teen) )

      {

            return 403;

      }

ISPmanager

- Ограничен ли доступ в панель по IP.

Ограничиваем доступ в панель по IP адресам. Делается это на вкладке “Настройка” панели ISPmanager.

- Настроено ли резервное копирование.

Рекомендуется настроить резервное копирование важных данных. Не рекомендуется хранить данные на локальном сервере. Для хранения данных предпочтительно использовать удаленный ftp или заблаговременно скачивать их с помощью панели.

- Все неиспользуемые сервисы рекомендуется отключить.

- Необходимо проверить установленное ПО на наличие известных уязвимостей или несоответствий

- Проверяем почтовую очередь и причины ее возникновения

Уровень операционной системы.

- Проверяем систему с помощью rkhunter

- Проверяем настройки sysctl (/etc/sysctl.conf):

Linux

net.ipv4.conf.all.accept_source_route = 0

Не принимать исходящие маршрутизированные пакеты.

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

имеющего адрес внутренней сети, но на самом деле возвращаемого назад злоумышленнику,

что позволит ему компрометировать сеть.

net.ipv4.icmp_echo_ignore_broadcasts = 1

Эта опция отключает ответ на широковещательные ICMP-запросы, предотвращая реализацию Smurf-атаки.

Smurf-атака основана на отправке ICMP-пакета типа 0 (ping) по широковещательному адресу сети.

Обычно для этого злоумышленник использует поддельный адрес. Все компьютеры сети ответят на сообщение ping,

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

net.ipv4.icmp_ignore_bogus_error_responses = 1

Включить защиту против приходящих неправильных сообщений об ошибках.

kernel.exec-shield = 1 (CentOS)

Включает защиту от переполнения стэка, буфферов и указателей.

kernel.randomize_va_space = 2

Включает ASLR. Включено по умолчанию.

net.ipv4.conf.all.accept_redirects = 0

net.ipv4.conf.default.accept_redirects = 0

Запрещаем icmp редиректы.

net.ipv4.conf.all.forwarding = 0

Запрещаем форвардинг. Имеет смысл, если на сервере не настроен VPN или другое специфическое ПО, требующее форвардинг.

net.ipv4.tcp_syncookies = 1

Включение механизма SYN cookies является очень простым способом борьбы

против атаки SYN флудом. При этом немного больше загружается процессор

из-за необходимости создавать и сверять cookie.

net.ipv4.tcp_synack_retries = 3

Определяет число попыток повтора передачи пакетов SYNACK для пассивных соединений TCP

net.ipv4.tcp_keepalive_time=1800

Уменьшим время которое используется для сообщений о поддержке keep alive соединений.

net.ipv4.tcp_keepalive_probes=3

Количество проверок перед закрытием соединения.

net.ipv4.tcp_fin_timeout=30

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

Проверка fstab

- Некорневые разделы должны содержать опцию nodev.

- Если /tmp примонтирована отдельным разделом, желательно добавить nodev, noexec, nosuid для этого раздела.

Проверка логов

- Проверяем конфигурационные файлы syslog

/etc/rsyslog.conf

Важные строки

*.info;mail.none;authpriv.none;cron.none                -/var/log/messages

authpriv.*                                              -/var/log/secure

Для Debian и CentOS название лог-файлов могут отличаться.

- Проверяем, что логи не пустые и данные записываются

Настройка sudo/su

Правим файл /etc/sudoers или /usr/local/etc/sudoers:

Для того, чтобы разрешить всем пользователям использовать sudo su, добавляем строку:

ALL    ALL=/bin/su

ALL    ALL=/usr/bin/su

Если хотим разрешить использовать определенную команду определенному пользователю или группе, используем:

%users    ALL=/sbin/mount - разрешит использовать sudo mount группе users

user    ALL=/sbin/mount - разрешит использовать sudo mount пользователю user

Сетевой уровень

- Проверяем, какие службы слушают порты

# netstat -tuplnw | awk '{print $4,$NF}' | sort | uniq

К этому моменту должны остаться только нужные сервисы. Запоминаем, какие порты слушаются.

- Устанавливаем range port для ftp-сервиса. Это порты, которые будут использоваться для подключения в режиме passive

vsftpd:

pasv_min_port=1028

pasv_max_port=1048

ProFTPD:

PassivePorts 1028 1048

- Проверяем настройки файервола

# iptables -nL

- Закрываем все порты, кроме активных сервисов. Для этого изменяем настройки политики файервола.

ВНИМАНИЕ! Работа с файерволом требует аккуратности. Прежде, чем добавлять значения в файл, попробуйте внести их вручную и посмотреть, все ли сервисы работают. Если наблюдаются проблемы с доступом, перезагрузка сбросит правила. Также в крон можно добавить:

*/10 * * * * iptables -F

Такая настройка будет сбрасывать правила файервола каждые 10 минут.

IPTABLES

- Для CentOS нужно править файл /etc/sysconfig/iptables, для Debian ищем файл в /etc/network/if-up.d/, например /etc/network/if-up.d/ispmgrfw и смотрим его. Файл может выглядеть так:

*filter

:INPUT ACCEPT [0:0]

:FORWARD ACCEPT [0:0]

:OUTPUT ACCEPT [0:0]

COMMIT

Меняем ACCEPT для политик на DROP:

*filter

:INPUT DROP [0:0]

:FORWARD DROP [0:0]

:OUTPUT DROP [0:0]

COMMIT

Политики можно поменять из консоли так

# iptables -P FORWARD DROP

# iptables -P INPUT DROP

# iptables -P OUTPUT DROP

Для iptables порты можно изящно прописать с помощью модуля multiport:

-A INPUT -p tcp -m tcp -m multiport  --dports 21,22 -m connlimit --connlimit-above 4 --connlimit-mask 32 -j DROP

- ограничение до 4х соединений с одного ip на 21,22 порт

-A INPUT -p tcp -m tcp -m multiport --dports 80,443,1500,81 -m connlimit --connlimit-above 32 --connlimit-mask 32 -j DROP

- на порты 80,443,1500,81 разрешаем 32 соединения с одного ip.

правила могут выглядеть так:

-A INPUT -p udp -m udp --sport 53 -j ACCEPT

-A INPUT -p icmp --icmp-type 8 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

-A INPUT -p tcp -m multiport --dports 20,21,22,25,80,110,443,953,1500,1028:1048 -j ACCEPT

-A INPUT -p udp -m udp --dport 53 -j ACCEPT

-A INPUT -p tcp -m multiport --sports 53,80,25,443,953 -j ACCEPT

-A OUTPUT -p udp -m udp --dport 53 -j ACCEPT

-A OUTPUT -p udp -m udp --sport 53 -j ACCEPT

-A OUTPUT -p icmp --icmp-type 0 -m state --state ESTABLISHED,RELATED -j ACCEPT

-A OUTPUT -p tcp -m multiport --dports 25,53,80,110,953,443 -j ACCEPT

-A OUTPUT -p tcp -m multiport --sports 20,21,22,25,80,110,443,953,1500,1028:1048 -j ACCEPT

Файервол также можно настроить с помощью панели ISPmanager.

Можно также использовать динамические правила (отслеживание состояний/keep-state).

Защищаем SSH

- В конфигурационном файле должны быть раскомментированы следующие строчки:

Protocol 2 - использовать вторую версию протокола. В первой присутствуют уязвимости

IgnoreRhosts yes - отключаем использование .rhost файла

HostbasedAuthentication no - отключаем аутентификацию по хосту

PermitRootLogin no - запрещаем доступ рута

PermitEmptyPasswords no - запрещаем пустые пароли

PermitUserEnvironment no - запрещаем пользователю устанавливать переменные окружения

PasswordAuthentication yes - аутентификация по паролю разрешена (можно отключить и предоставить возможность аутентификации по ключам)

Настраиваем SFTP

SFTP включается строчкой в конфигурационном файле ssh.

Subsystem sftp /usr/lib/openssh/sftp-server

Защищаем FTP

Можно отключить ftp сервис и пользоваться sftp или scp/ssh. SFTP настраивается путем конфигурации ssh. Если использование ftp необходимо, проверяем следующие параметры:

VSFTPD

xferlog_enable=YES  - логирование запросов в ftp

anonymous_enable=NO - отключаем доступы анонимным пользователям

anon_upload_enable=NO

anon_mkdir_write_enable=NO

PROFTPD

В файле конфигурации ищем секцию

<Anonymous ~username>

...

</Anonymous>

Удаляем в ней все секции Limit и прописываем:

<Limit LOGIN>

DenyAll

</Limit>

<Limit ALL>

DenyAll

</Limit>

Либо комментируем секцию Anonymous.

Общие рекомендации

Проверка почтовой очереди

Почтовая очередь проверяется командой mailq. Для разных MTA вывод может отличаться. Если сообщений слишком много, нам нужно определить не спам ли это. Для этого нужно найти идентификатор сообщения и посмотреть по логам, откуда оно было отправлено. Идентификатор может выглядеть так:

BD65F10DEE4

1W7GNi-0000OM-OE

С помощью exim можно посмотреть заголовки письма

# exim -Mvh идентификатор_сообщения

или его тело

# exim -Mvb идентификатор_сообщения

Ищем строку X-PHP-Script. Эта строка покажет, какой скрипт отсылает сообщения. Ищем скрипт и проверяем.

Для других МТА нужно искать информацию в логах

Проверяем актуальность установленных CMS

Для основных CMS очень удобно использовать CMSmap

Joomla

Смотрим файл changelog.txt в корне сайта.

Там должна быть информация о версии.

Wordpress

Информация о версии должна быть здесь

wp-includes/version.php

DLE

Можно посмотреть здесь:

engine/data/config.php - строчка version_id.

engine/ajax/updates.php

upgrade/index.php - $dle_version

1C-Битрикс

Информацию о версии смотрим здесь:

/bitrix/modules/main/classes/general/version.php

/bitrix/admin/update_system.php

Drupal

Смотрим файл changelog.txt в корне сайта.

/modules/system/system.info - здесь также стоит посмотреть версию движка

Если версию не удалось определить по файлам движка, смотрим версию в админ-панели CMS

Проверка прав на директории сайта

Директория должна принадлежать пользователю и группе владельца сайта. Если используется mpm_prefork, владельцем может быть пользователь apache (www, www-data). Такая ситуация ослабляет безопасность веб-приложений.

Права 777 возможны только в случае крайней необходимости на директории общего пользования (upload, tmp).

# find ./ -perm 0777 - найдет все файлы/директории с правами 777

Использование rkhunter

# rkhunter --update

# rkhunter --propupd

# rkhunter -c --cs2

Суммарная информация о проверке выглядит так:

System checks summary

===========

File properties checks...

    Files checked: 137

    Suspect files: 0

Rootkit checks...

    Rootkits checked : 306

    Possible rootkits: 0

Applications checks...

All checks skipped

The system checks took: 1 minute and 22 seconds

All results have been written to the log file (/var/log/rkhunter/rkhunter.log)

One or more warnings have been found while checking the system.

Please check the log file (/var/log/rkhunter/rkhunter.log)

Ищем предупреждения, которые заинтересовали rkhunter.

grep -2i warn /var/log/rkhunter/rkhunter.log

С помощью rkhunter можно найти руткиты, проблемы конфигурации, привелегированных пользователей и др. Например, вывод:

[06:36:34] Warning: Account 'move' is root equivalent (UID = 0)

означает, что пользователь move имеет UID=0, что дает ему права root.

Все ошибки и предупреждение необходимо тщательно проанализировать

Проверка ПО на уязвимости

CentOS:

- С помощью RPM определяем, какие файлы установленного ПО были изменены:

# rpm -qVa

# rpm -qVa | awk '$2!="c" {print $0}' - исключит из вывода конфигурационные файлы, которые могут быть изменены.

В первой таблице:

S - отличается размер файла

M - отличаются права по умолчанию

5 - отличается MD5

D - major/minor номера для устройства отличаются

L - отличается путь до симлинки

U - владелец отличается

G - группа отличается

T - значение mtime отличается

Во второй таблице:

c %config конфигурационный файл

d %doc файл документации

g %ghost файл, который не включен в пакет

l %license файл лицензии

r %readme README файл

В данном выводе нас интересуют файлы, у которых отличается MD5.

Эти пакеты могут быть изменены. Нужно проверить бинарники пакетов по времени (stat) и типу (file).

# stat /usr/sbin/sshd && file /usr/sbin/sshd

- Проверяем наличие security-update.

# yum install yum-security

# yum list-security

# yum --security update - установить security-update

Debian:

- С помощью debsums проверяем MD5 суммы установленных пакетов.

# apt-get install debsums

# debsums -c

- С помощью apt проверяем наличие security-update. Необходимо убедиться, что в sources.list присутствует репозиторий с обновлениями безопасности или добавить его туда:

# echo ‘deb http://security.debian.org wheezy/updates main contrib non-free’ >> /etc/apt/sources.list

# grep security /etc/apt/sources.list > /etc/apt/secsrc.list

# apt-get -s -o Dir::Etc::sourcelist="secsrc.list" -o Dir::Etc::sourceparts="-" upgrade

# apt-get -o Dir::Etc::sourcelist="secsrc.list" -o Dir::Etc::sourceparts="-" upgrade - установить security-update

- Проверяем наличие во всех репозиториях сверку gpg:

# grep -ri gpgcheck /etc/yum.conf

# grep -ri gpgcheck /etc/yum.repos.d/

Строка дожна выглядеть так

gpgcheck=1

# grep -ri AllowUnauthenticated /etc/apt/

Строки, вроде:

APT::Get::AllowUnauthenticated "true";

быть не должно

Поиск неиспользуемых сервисов

Список сервисов, настроеных на автозапуск можно получить так:

Debian

# sysv-rc-conf

# sysv-rc-conf off service_name - отключит сервис

Centos

# chkconfig --list

# chkconfig --del service_name - удалит сервис со всех runlevel.

Cheat-Sheet

Устранение последствий взлома сайта

- Проверка на

http://online.drweb.com/?url=1

# find /home/user/data/www/site.ru/ -type f -mtime -10 - ищем файлы, которые изменяли меньше, чем 10 дней назад

# mailq | wc -l - количество писем в очереди

- проверяем http://www.revisium.com/ai/

# find /home/user/data/www/site.ru/ -type d \( -iname '*upload*' -o -iname '*tmp*' \)

# file /home/user/data/www/site.ru/uploads/* | grep -i php

поиск общих директорий и поиск в них php-скриптов

# find ./ -perm 0777 - поиск всех файлов/папок с 777 правами

# find /home/user/data/www/site.ru/ -type f -iname '*htaccess' -exec grep -i rewrite {} \; - поиск редиректов в htaccess

# egrep -ril “base64_decode|auth_pass|shell_exec” /home/user/site.ru - поиск паттернов в файлах сайта

# cat changelog.txt

(wp-includes/version.php,engine/data/config.php,/bitrix/modules/main/classes/general/version.php)

проверка версии CMS

# grep shell.php /home/httpd-logs/site.ru.access.log - доступ к shell-скрипту на сайте

# stat shell.php - атрибуты (время) файла

# grep -i accept /var/log/secure - удачные попытки залогиниться по ssh

# awk ‘($12~/i/){print}’ /var/log/xferlog - файлы, которые залили по ftp

# egrep -i “expose_php|sql.safe_mod|post_max_size|disable_funct” /etc/php.ini - проверка настроек php.ini

# sed -i 's/@preg.*34//g' infected.js - чистим файлы, предварительно сделав копию

Устранение последствий взлома сервера

# ps auxw

# top

проверяем запущенные процессы

# ls /proc/PID/cwd - смотрим директорию файла

# stat shell - смотрим атрибуты (время бинарного файла)

# strings shell - анализируем файл

# rkhunter --update

# rkhunter --propupd

# rkhunter -c --cs2

проверяем сервер rkhunter

# mailq | wc -l -проверяем почтовую очередь

# netstat -tuplnw | awk '{print $4,$7}' | sort | uniq

проверяем сетевые соединения

# groups - покажет группы пользователя

# find / -type f -group user - найдет все файлы с группой user

# egrep -ri ‘wget|sh|fetch|curl’ /var/spool/cron

проверяем crontabs

# egrep -i "success|accept" /var/log/secure

# egrep -i accept /var/log/auth.log

проверяем, кто заходил по ssh.

- проверяем сервер на наличие устаревшего/уязвимого ПО

# tail -30 /root/.bash_history - проверяем history

# egrep -i “auth|mgradmin.edit” /usr/local/ispmgr/var/ispmgr.journal

# grep ‘admin.edit /usr/local/mgr5/var/ispmgr.journal && egrep “\[root\] ‘’|badpassword” /usr/local/mgr5/var/ispmgr.log

проверка логов панели

# stat file.c - изучение файла