सत्यं वद धर्मं चर

Борьба с ботами, подбирающими пароль администратора

2013-05-12T11:58:54Z

Как отвадить ботов от сайта

Имеется сервер с большим количеством установленных блогов WordPress. В какой-то момент времени сервер облюбовали боты, нагло подбирающие админские пароли. При этом на блогах зарегистрировано много пользователей, которые тоже периодически ошибаются с паролями и даже упорствуют в своих заблуждениях.

Задача простая: отсечь ботов, при этом по минимуму затронуть пользователей.

Самые очевидные решения: не использовать admin в качестве имени администратора (бот при желании может получить имя/логин автора из постов), использовать плагины типа User Locker (от него у нас временами страдают пользователи) и т.д. В любом случае, защита должна быть эшелонированной — на один единственный способ защиты лучше не полагаться.

От попыток подбора паролей User Locker помогает. Проблема в том, что боты достаточно тупы, чтобы осознать, что зайти у них не получится; как следствие, они продолжаются долбиться в несчастную форму логина, временами сильно нагружая сервер.

Отслеживались боты так: сначала я завёл в nginx новый формат лога:

log_format insight '$remote_addr $server_name [$time_local] "$request" $status $body_bytes_sent $request_time "$http_referer" "$http_user_agent"';

и добавил во все виртуальные хосты такую строчку:

access_log /var/log/nginx/insight.log insight;

Это позволило собрать все логи в одном файле — с одним файлом работать гораздо проще.

Наблюдать попытки логина можно так:

tailf /var/log/nginx/insight.log | grep -F ' /wp-login.php '

на выходе получалось что-то вида

202.151.22.4 sjinks.org.ua [11/May/2013:06:54:10 +0000] "POST /wp-login.php HTTP/1.0" 200 3687 0.714 "sjinks.org.ua/wp-login.php" "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0"
78.168.125.72 sjinks.org.ua [11/May/2013:06:54:23 +0000] "POST /wp-login.php HTTP/1.0" 200 3648 0.314 "sjinks.org.ua/wp-login.php" "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0"
151.232.60.251 sjinks.org.ua [11/May/2013:06:54:46 +0000] "POST /wp-login.php HTTP/1.0" 200 3687 0.561 "sjinks.org.ua/wp-login.php" "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0"
41.105.76.240 sjinks.org.ua [11/May/2013:06:54:51 +0000] "POST /wp-login.php HTTP/1.0" 200 3648 1.101 "sjinks.org.ua/wp-login.php" "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0"
119.93.76.186 sjinks.org.ua [11/May/2013:06:54:57 +0000] "POST /wp-login.php HTTP/1.0" 200 3648 0.575 "sjinks.org.ua/wp-login.php" "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0"

Неуспешная попытка логина — код 200, успешная — код 302.

Характерные особенности:

в поле Referer отсутствует http://;
используется протокол HTTP/1.0;
отсутствует GET /wp-login.php — можно добавить в форму входа своё поле и проверять его наличие при попытке входа; если поле не присутствует, мы имеем дело с ботом

Доходило до того, что боты часами пытались подобрать пароль.

Я решил выделить неудачные попытки входа кодом 403 (Forbidden), а заодно и посмотреть, пытаются ли боты найти phpMyAdmin или что-нибудь еще (404).

Набросал такой вот плагинчик:

Тут, собственно, и началось самое интересное: человек не увидит 403 ошибку (если специально не будет смотреть на заголовки HTTP): человек увидит привычную форму входа и сообщение об ошибке. Боты же сообщения об ошибке обычно не анализируют — у них всё проще: перенаправило на /wp-admin/ — пароль попдобран, оставило там же — подбираем дальше. И вот тут оказалось, что если вернуть ошибку (в данном случае 403 Forbidden), то бот обижается и уходит Если над этим подумать, то всё логично: бот не проверял существование страницы до попытки войти; получив явный код ошибки, бот уходит к другой жертве.

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

PS: в качестве бонуса: если сделать так:

то особо злобных ботов можно отслеживать при помощи CSF + LFD или fail2ban (или аналогичных средств) и блокировать их адреса.

Например, в случае CSF я добавил в /etc/csf/regex.custom.pm такой код:

if (($lgfile eq $config{SYSLOG_LOG}) and ($line =~ /^(\S+|\S+\s+\d+\s+\S+) (\S+ )?wplogin\[\d+\]: (\S+)/)) {
return ("Brute forcing attempt from", $3, "wplogin", "10", "80", "60");
}

Помимо блокировки бота, скрипт, указанный в параметре BLOCK_REPORT csf.conf отсылает логи инцидента «куда надо».

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

Контроль доступа к SSH на основе DNSBL

2013-04-30T08:44:50Z

Пример ограничения доступа с использованием tcpwarppers

С целью безопасности имеет смысл ограничить доступ к SSH (и другим критическим службам) для пользователей, компьютеры которых заражены (или являются членами ботнета).

Есть несколько DNSBL, специализирующихся на таких случаях:

Composite Block List (CBL)
Spamhaus Exploits Block List (XBL); включает в себя данные CBL;
blocklist.de
ZeuS / SpyEye / Palevo Trackers на abuse.ch

Также имеет смысл запретить вход по SSH пользователям из стран, которые не имеют к серверу отношения. На этот случай тоже есть свой DNSBL: countries.nerd.dk

Если sshd собран с поддержкой tcpwrappers, то можно поступить следующим образом (проверено на Debian и Ubuntu).

Для начала установить пакет rblcheck:

sudo apt-get install rblcheck

Затем нужно изменить файлы /etc/hosts.allow и /etc/hosts.deny.

Прежде всего нужно добавить в /etc/hosts.allow свой IP-адрес, чтобы в случае всяких неожиданностей не потерять доступ к серверу. Например, если ваш IP-адрес 1.2.3.4, то нужно добавить такую запись в /etc/hosts.allow:

sshd : 1.2.3.4

И сохранить файл.

Затем добавляем такие записи в /etc/hosts.allow:

sshd : 127.0.0.0/8
sshd : ALL : aclexec /usr/bin/rblcheck -c -q -s xbl.spamhaus.org -s ssh.bl.blocklist.de %a

В примере выше задана проверка IP-адреса клиента по спискам xbl.spamhaus.org и ssh.bl.blocklist.de; дополнительные списки можно добавить через параметр -s

После 127.0.0.0/8 имеет смысл добавить (через пробел) IP-адреса сервера; если на сервер можно зайти из локальной сети (например, 10.0.0.0/8, 192.168.0.0/16), эти адреса тоже нужно добавить в список (эти адрес не являются маршрутизируемыми и запрашивать их на наличие в чёрных списках бессмысленно).

Затем добавляем в /etc/hosts.deny

sshd : ALL

Сохраняем, готово!

Если всё прошло успешно, то в логе сервера вскоре можно будет увидеть записи вида

Apr 29 23:55:47 sjinks sshd[17205]: aclexec returned 1
Apr 29 23:55:47 sjinks sshd[17205]: refused connect from 217.174.249.24 (217.174.249.24)

Опасная уязвимость в WP Super Cache и W3 Total Cache

2013-04-25T00:18:12Z

Выполнение произвольного кода PHP на целевой системе

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

Исследователь ИБ Френк Гусен (Frank Goosen) опубликовал подробности уязвимости в популярных плагинах для кеширования страниц WordPress – WP Super Cache и W3 Total Cache, насчитывающих более 6 млн загрузок. Обнаруженная исследователем уязвимость позволяет злоумышленнику внедрить и выполнить произвольный PHP код на целевой системе с привилегиями Web-сервера.

Уязвимые версии:

WP Super Cache 1.2 и более ранние
W3 Total Cache 0.9.2.8 и более ранние

Для успешной эксплуатации уязвимости на сайте должен присутствовать парсер динамических сниппетов. Злоумышленник может опубликовать комментарий к публикации, содержащий PHP код, который будет преобразован с помощью парсера и выполнен на системе.

Для устранения уязвимости установите последнюю версию плагинов WP Super Cache 1.3.1 или W3 Total Cache 0.9.2.9. В качестве временного решения можно отключить динамические сниппеты.

С подробным описанием уязвимостей можно ознакомиться по адресам:

http://www.securitylab.ru/vulnerability/439817.php
http://www.securitylab.ru/vulnerability/439824.php (злостный копипаст прошлой ссылки; вставленное, очевидно, никто не читает)

Взято отсюда.

От себя добавлю, что также уязвим плагин WP Cache (прообраз WP Super Cache); идея динамических сниппетов, если я не ошибаюсь, заимствована из него.
Я знал об этой особенности плагинов лет, наверное, пять. Просто в голову не приходило, что это уязвимость

Подана заявка на русский StackOverflow

2013-04-15T17:04:37Z

Некоторое время назад на StackExchange была подана заявка на открытие форума StackOverflow на русском языке. Хотя новое сообщество никогда не заменит оригинальный StackOverflow в силу меньшего размера аудитории, но принесет свою пользу: позволит начинающим программистам, которые еще недостаточно хорошо владеют английским языком, приобщиться к культуре большого сайта.

Всем желающим большая просьба поддержать это начинание.

Адрес заявки: http://area51.stackexchange.com/proposals/41168/stack-overflow-in-russian

Как спрятать версию BIND

2013-04-06T19:28:43Z

Делаем BIND менее болтливым

Чтобы узнать версию BIND, достаточно натравить на него такой запрос:

dig -c CH -t TXT version.bind @address

где address — адрес сервера, где живёт BIND.

BIND на такое ответит чем-то вроде

;; QUESTION SECTION:
;version.bind. CH TXT

;; ANSWER SECTION:
version.bind. 0 CH TXT "9.8.1-P1"

;; AUTHORITY SECTION:
version.bind. 0 CH NS version.bind.

Параноики (и dnsstuff) рекомендуют прятать версию BIND, например, таким образом.

Но на самом деле правильно делать так:

options {
version none;
hostname none;
server-id none;
};

Тем не менее, следует помнить, что это security by obscurity, а версию сервера примерно можно определить при помощи fpdns или подобных инструментов.

Memcache, igbinary и сессии в PHP

2013-03-18T15:24:58Z

Хозяйке на заметку: как делать не надо

Ситуация: на сервере стоит PHP с установленными расширениями memcache и igbinary.

В конфигурации задано хранение сессий в memcached, а для сериализации сессий — использование igbinary.

То есть как-то так:

session.save_handler=memcache
session.save_path=tcp://127.0.0.1:11211?persistent=1&weight=1&timeout=1&retry_interval=15
session.serialize_handler=igbinary

В такой конфигурации сессии могут не работать вообще.
Решение простое: убрать session.serialize_handler.

Установка Idera Server Backup Free в Ubuntu

2013-03-10T07:55:35Z

Некоторые подводные камни, замеченные при установке Idera Server Backup Free в Ubuntu

Сегодня обратил внимание, что у R1 Soft (они теперь Idera) появилось бесплатное решение для создания резервных копий — Server Backup Free, представляющий собой несколько урезанный по функциональности клон Server Backup Enterprise (бывший R1 Soft CDP).

При установке Server Backup Free встретилось несколько подводных камней, о которых в официальной документации ничего не сказано. Надеюсь, что данная статья поможет.

Процесс установки выглядит так (предполагается, что команды выполняются от имени суперпользователя):

echo "deb http://repo.r1soft.com/apt stable main" >> /etc/apt/sources.list
wget http://repo.r1soft.com/r1soft.asc
apt-key add r1soft.asc
apt-get update
apt-get install serverbackup-free linux-headers-`uname -r`
serverbackup-setup --get-module
serverbackup-setup --user USERNAME --pass PASSWORD
serverbackup-setup --http-port 8080 --https-port 8443
/etc/init.d/cdp-server restart
/etc/init.d/cdp-agent restart

USERNAME, PASSWORD — это административные логин и пароль для управления сервером CDP.
8080 и 8443 — порты для соединений по протоколам HTTP и HTTPS. В принципе, могут быть любыми. Они сохраняются в файл /usr/sbin/r1soft/conf/web.properties. Теоретически в этом файле можно отключить HTTP (http-enabled=false) или HTTPS (ssl-enabled=false), но я не пробовал.

Вышеприведённые команды выполнялись без ошибок, но сервер (cdp-server) сразу же умирал, причём не выдавая никаких диагностических сообщений. Причина проста: init-скрипт перенаправлял stderr в /dev/null.

Если запускать вручную:

cd /usr/sbin/r1soft/bin/
./cdpserver /usr/sbin/r1soft/conf/server.conf

то можно получить сообщение о несуществующей ошибке вида:

./cdpserver: error while loading shared libraries: libjvm.so: cannot open shared object file: No such file or directory

Несуществующая она потому, что init-скрипт шаманит с переменной среды LD_LIBRARY_PATH, и если эти шаманства не повторить, то получим вышеприведённую ошибку. На самом же деле проблема в другом.

Смотреть надо в логи сервера, а лежат они отнюдь не в /var/log, как было раньше (да, я помню те времена, когда R1 CDP использовал syslog), а в /usr/sbin/r1soft/log. Требуемый файл — server.log.

В моём случае сообщение об ощибке было таким:

2013-03-10 00:03:14,943 INFO - Allowed number of agents: 1
2013-03-10 00:03:14,943 INFO - Trial License - NO
2013-03-10 00:03:14,959 INFO - General Service started
2013-03-10 00:03:14,959 INFO - Disk Safe Service starting
2013-03-10 00:03:14,963 INFO - Starting Disk Safe block store
2013-03-10 00:03:14,963 INFO - Disk Safe block store native heap memory soft limit: 33,554,432 (bytes)
2013-03-10 00:03:14,963 INFO - Disk Safe Page Cache Size: 512 (pages)
2013-03-10 00:03:14,978 INFO - Disk Safe Service started
2013-03-10 00:03:14,978 INFO - Storage Cache Service starting
2013-03-10 00:03:15,044 INFO - Storage Cache Service started
2013-03-10 00:03:15,044 INFO - Tomcat Wrapper starting
2013-03-10 00:03:18,291 ERROR - Error starting up server
com.r1soft.backup.server.exception.StartupException: Could not start web server
at com.r1soft.TomcatWrapper.start(TomcatWrapper.java:279)
at com.r1soft.Main.Rb(Main.java:286)
at com.r1soft.Main.run(Main.java:170)
Caused by: LifecycleException: Protocol handler initialization failed: java.net.BindException: Address already in use <null>:9080
at org.apache.catalina.connector.Connector.initialize(Connector.java:1051)
at com.r1soft.TomcatWrapper$LifecycleEventConnector.initialize(TomcatWrapper.java:97)
at org.apache.catalina.startup.Embedded.start(Embedded.java:830)
at com.r1soft.TomcatWrapper.start(TomcatWrapper.java:274)
... 2 more

Собственно, ошибка вот: java.net.BindException: Address already in use <null>:9080. Ошибка потому, что на порту 9080 вообще никто не сидел. Абсолютно. Аналогично было с портами 9443 и 5443.

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

UPD: а проблема с портами, как оказалось, в том, что Server Backup сам занимает некоторые порты:

tcp 0 0 127.0.0.1:32000 0.0.0.0:* LISTEN 4260/cdpserver
tcp 0 0 127.0.0.1:32000 127.0.0.1:31000 ESTABLISHED 4258/cdpserver
tcp6 0 0 :::9080 :::* LISTEN 4260/cdpserver
tcp6 0 0 127.0.0.1:8063 :::* LISTEN 4260/cdpserver
tcp6 0 0 :::5443 :::* LISTEN 4260/cdpserver
tcp6 0 0 :::9443 :::* LISTEN 4260/cdpserver
tcp6 0 0 127.0.0.1:31000 127.0.0.1:32000 ESTABLISHED 4260/cdpserver

По случайному совпадению, занятыми оказались как раз те порты, которые я пытался указать. Мораль такова: порты 5443, 8063, 9080, 9443, 31000, 32000 лучше не трогать.

И еще: для нормального функционирования сервера у него должен быть доступ к activation.r1soft.com:443 (по другим сведениям — к порту 10443).

Официальные рекомендации 2008 года таковы:

R1Soft Licensing Server: allow TCP established from activation.r1soft.com port 10443 to CDP-Server port range 1024-65535
R1Soft Licensing Server: allow TCP from CDP-Server port range 1024-65535 to activation.r1soft.com port 10443
CDP Server Web Interface: allow TCP from any to CDP-Server port 80
CDP Server Web Interface: allow TCP from any to CDP-Server port 443
CDP Server Web Interface: allow TCP established from CDP-Server port 80 to any port range 1024-65535
CDP Server Web Interface: allow TCP established from CDP-Server port 443 to any port range 1024-65535
CDP Server Service Provider API: allow TCP from any to to CDP-Server port 8084
CDP Server Service Provider API: allow TCP from any to to CDP-Server port 8085
CDP Server Service Provider API: allow TCP established from CDP-Server port 8084 to any port range 1024-65535
CDP Server Service Provider API: allow TCP established from CDP-Server port 8085 to any port range 1024-65535
CDP Server to CDP Agent: allow TCP established from any port 1167 to CDP-Server port range 1024-65535
CDP Server to CDP Agent: allow TCP from CDP-Server port range 1024-65535 to any port 1167

Вместо портов 80 и 443 подставить порты, заданные в рпциях --http-port и --https-port.

Как следует из рекомендаций, порты 1167, 8084 и 8085 не занимать.

Как скрыть рекламу Facebook в ленте новостей

2013-02-28T16:21:18Z

Greasemonkey to the rescue!

Буквально пару дней назад я обнаружил, что Facebook стал показывать неотключаемую рекламу в ленте новостей. Не знаю, почему, но она меня жутко раздражает. Я понимаю, что для Facebook это один из способов заработка, но ничего не могу с собой поделать.

Поэтому ниже приведён скрипт для Greasemonkey, который эту рекламу скрывает.

// ==UserScript==
// @name Facebook Newsfeed Ads Remover
// @author Vladimir Kolesnikov
// @namespace http://blog.sjinks.pro/
// @include http://*.facebook.com/*
// @include https://*.facebook.com/*
// @grant none
// ==/UserScript==

function kill_ads()
{
var x = document.evaluate('//li[.//a[@href="/about/ads"]]', document, null, XPathResult.UNORDERED_NODE_SNAPSHOT_TYPE, null);
for (var i=0; i<x.snapshotLength; ++i) {
var a = x.snapshotItem(i);
a.parentNode.removeChild(a);
}
}

document.addEventListener("DOMNodeInserted", kill_ads, true);

Подобное, вероятно, можно провернуть и с помощью одного из дополнений AdBlock (Element Hide Helper или как там оно называется), но мне было лень его ставить.

Возможная 0-day уязвимость в SSH

2013-02-20T04:09:31Z

Злобный SSHD руткит шагает по планете

Как сообщают различные эксперты по информационной безопасности, наблюдается волна взломов серверов на базе Linux. По предварительным данным, в ходе атаки эксплуатируется уязвимость нулевого дня в одной из служб платформы, предположительно SSH.

Детальное обсуждение здесь: http://www.webhostingtalk.com/showthread.php?t=1235797

Симптомы следующие:

На заражённых системах появляется файл /lib64/libkeyutils.so.1.9 (для 64-битных систем) и /lib/libkeyutils.so.1.9 (для 32-битных систем)
Символическая ссылка /lib64/libkeyutils.so.1 (/lib/libkeyutils.so.1) указывает на новый файл.

Предполагается, что libkeyutils.so.1.9 крадёт пароли, ключи SSH, содержимое /etc/shadow, устанавливает backdoor для возможности доступа к системе злоумышленнику, рассылает спам, а также делает сервер частью ботнета.

Cloudlinux опубликовал две утилиты: для обнаружения присутствия руткита и удаления руткита (последнюю рекомендуется использовать на свой страх и риск).

Для проверкм на руткит:

wget -qq -O - http://www.cloudlinux.com/sshd-hack/check.sh | /bin/bash

Для удаления руткита:

wget -qq -O - http://www.cloudlinux.com/sshd-hack/clean.sh | /bin/bash

По традиции эксперты рекомендуют закрыть доступ к ssh файрволом для всех адресов, кроме своего собственного.

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

Героин или героиня?

2013-02-15T17:29:36Z

Очередной казус от Google Translate

Google Translate в очередной раз порадовал.

Если перевести слово heroine (героиня) с английского на русский, то получится такая картинка.

Действительно, героин, героиня — какая разница?