Нет, это уже слишком!

Скрипт firewall'а на почтовом сервере/по совместительству интернет-шлюзе:

for p in 22 3306 3389 4444 8080 9000
do
$IPTABLES -A INPUT -i $EXT -p tcp -m tcp -s $IPMONITORSERVER1 --dport $p -j ACCEPT
$IPTABLES -A INPUT -i $EXT -p tcp -m tcp -s $IPMONITORSERVER2 --dport $p -j ACCEPT
$IPTABLES -A INPUT -i $EXT -p tcp -m tcp -s $IPADMIN1 --dport $p -j ACCEPT
done

В самом верху файла написано:

IPADMIN1="0.0.0.0/0"

Я понимаю конечно, что статический IP это дорого и неудобно, но иногда надо хоть за что-то платить. ;)

P.S.: Вчера разговаривал с коллегой, чей сервер подвергался постоянному Web-DDoS'у какого-то ботнета -- постоянно посылались запросы на загрузку страницы '/' сайта. Решение коллега нашел простое -- положил index.html в котором средствами javaScript'а производился переход на index.php. На удивление нагрузка на сервер здорово упала. :)

История с продолжением

Что-то март получился очень насыщенным на события в IT-Security. Не успели бравые парни из Adobe зафиксить уязвимость в JBIG(всего-то три недели исправляли), как тут же подоспела новая узявимость. Правда, на сей раз в JavaScript. Но результат все тот же -- исправления нет, уязвимость позволяет выполнить произвольный код. Мне даже страшно подумать, сколько времени займет исправление на этот раз. 

В предыдущем посте говоря о психологии, я писал про Conficker. Механизм работы psyb0t'а (подробнее см. http://www.dronebl.org/blog/8 ), червя атакующего linux-роутеры на платформе mipsel, также основан на психологии. Этот червь, способный объединять зараженные устройства в ботнет, извлекать данные пользователя (пароли etc.) из проходящего трафика, распространяется в основном посредством подбора паролей к управляющим консолям маршрутизаторов. Ведь зачем на купленной дешевой мыльнице-роутере, модеме или точке доступа менять пароли? Ну а если уж менять, то можно поставить qwerty и 123. Судя по приблизительному количеству взломанных устройств (~100k),  людей, которые думают именно так, довольно много. И это очень беспокоит, так как подобные устройства очень слабо защищены. Многие пользователи, даже если они установили антивирус на свой компьютер, очень аккуратны с запуском незнакомых программ и пр. никогда не задумаются, что маршрутизатор может быть точно также заражен вирусом, как и их настольный компьютер. Опрос моих знакомых из контакт-листа jabber/icq показал -- >90% опрошенных (которые не были связанны с информационной безопасностью) имеющих дома подобные устройства даже не думали что в них есть функция изменения пароля. Вот так. Впрочем, если вы думаете что дело только в домашних пользователях, то вы ошибаетесь. Мне сразу вспоминается одна контора, которая попросила проверить безопасность их сети. Аккаунт cisco/cisco на одном из их маршрутизаторов периметра и открытый порт telnet говорил о многом. Интересно, есть ли какие-то способы защиты от наивных пользователей? 

О хорошем. psyb0t атакует только маршрутизаторы на платформе mipsel, используя для проникновения дефолтовые/слабые пароли и/или уязвимости в firmware. Обновления до последней версии firmware и смена паролей на устойчивые обезопасит ваш маршрутизатор на 99%. Если же вы подозреваете, что ваш рутер/модем/тд заражены (явным признаком этого является блокировка трафика по порту 80 и/или невозможность подсоединения к web-, ssh-, telnet- консоли управления и/или просто резкое снижение пропускной способности устройства), то вас спасет hard reset (обнуление настроек) с последующей перепрошивкой до последней версии вашего firmware. И кроме того, хорошо бы ограничить доступ к портам консоли управления  -- хотя бы по IP и только с интерфейсов локальной сети (а не WAN и DMZ ;) ).

P.S.: Обнаружил замечательную утиллиту извлечения данных из трафика -- Xplico. Как-то раньше я для таких целей в основном использовал pure wireshark/tcpdump, dsniff или самопальные приложения. У Xplico же довольно удобный интерфейс и самое главное -- на удивление высокая скорость работы. А набор поддерживаемых протоколов просто впечатляет.

P.S.S: И еще: появилась третья модификация Conficker'а (C). Эта версия не имеет механизмов распространения через сеть, зато имеет дополнительные механизмы защиты от антивирусов и LIDS. Более подробно можно прочитать тут.

О вирусах, самоподписанных сертификатах и pdf...

В умной книжке Норкатта (Защита сетевого периметра) говорилось приблизительно так: "50% проблем с безопасностью лежат в области человеческой психологии". Иногда мне кажется, что все 99%.

Вот например пресловутый Win32.Kido.* aka Conficker. Ведь потрясающий вирус! IT-безопасностью я занимаюсь уже года четыре, а программированием уже более 11 лет, но не помню современных вирусов с такими же свойствами. (меня поправить! ;)) Вдумайтесь, один вирус использует такие косяки, как:

• слабые пароли пользовательских учетных записей;
• непатченность систем;
• autorun, который Microsoft закрыла лишь совсем недавно.

Все эти три проблемы лежат скорее в области психологии, чем технологии.  У Conficker'а много "замечательных" свойств, которые здорово усложныют борьбу с ним, и я уверен что автор вируса -- очень хороший программист. И я также уверен, что он неплохо знает психологию :).

Или другой пример -- о самоподписанных SSL-сертификатах. Недавно в одном блоге увидел заметку, в которой утверждалось, что ненадежность самоподписанных сертификатов -- всего лишь "предрассудок", и 

 зачем вообще нужен сертификат SSL? Для того, чтобы зашифровать HTTP-соединение между браузером и сайтом, по которому будет передаваться пароль и какие-то другие конфиденциальные данные. Что изменится, если сертификат не подписан доверенным центром сертификации? Ничего! Соединение все равно будет зашифрованно точно также

Интересное мнение, не так ли? И не лишенное определенной логики. Но вот я например, если условный сайт веб-денег mylmoney.com выдаст мне MylMoney.com run as (unknown), Verified by MylMoney.com, не стану хранить на нем деньги. Потому что однажды, я могу по-привычке кликнуть на "принять запрос сайта my1money.com, который подписан My1Money.com". Куда потом уйдут мои деньги -- одним гремлинам известно. Человек -- не точная машина, и мы можем в спешке, в суете, из-за усталости, да и просто по невнимательности щелкнуть по надоедливому окошку "принять сертификат". Ведь на первый взгляд mylmoney.com == my1money.com, не так ли? Единственное место, где, ИМХО, стоит применять самоподписанные сертификаты -- это тестовый стенд. Впрочем, я могу и ошибаться. Желающие подискутировать -- прошу в комменты.

Ну и последнее. На этой неделе Adobe наконец выпустил заплатку закрывающую уязвимость в JBIGPicture. На мой взгляд, появление публичной инфы об уязвимости на блоге VRT  сразу после обнаружения не сильно ускорило процесс написания заплаток, а только создало больше проблем сисадминам и инженерам по безопасности. Все-таки наверное политика Full-Disclosure не всегда себя оправдывает. Хотя кто знает, сколько бы прошло времени, пока Adobe пофиксила бы уязвимость, если бы не появились эксплоиты in-the-wild. Правда я сомневаюсь, что больше месяца. Выиграло ли сообщество от того, что патч появился на неделю раньше, а эксплоиты -- на три недели? Думаю, что нет. 

P.S.: Пресловутый Conficker к счастью не затронул ни один компьютер в моих конторах. Но вот знакомые и коллеги пару-тройку раз звали помогать справиться с ним. ;) Небольшая инструкция по борьбе с этим зверем, которую в последние разы я им просто отсылал, прилагается ниже. 

1. Ищем с помощью утилиты http://www.securitylab.ru/news/368759.php все непатченные машины. (огромное спасибо Сергею Гордейчику и Positive Technologies!)
2. Отключаем ВСЕ машины от сети.
3. Отключаем на ВСЕХ машинах автоматическое восстановление.
4. Патчим ВСЕ непатченный машины патчами MS08-065, MS08-067 и MS09-001. (непатченные... патчами, простите за "масло масленное" ;))
5. Отключаем автозапуск на всех машинах. (а еще лучше, ставим последнее обновление Microsoft, которое отключает AutoRun, см. http://support.microsoft.com/kb/967715).
6. Запускаем KidoKiller + CureIT! последовательно (желательно запускать их с компакт-диска или защищенной от записи флэшки).
7. Ставим последний антивирус (AVZ, DrWeb, F-Secure, Касперский), без перезагрузки проверяем.
8. Ищем autorun.inf на всех расшаренных/доменных ресурсах, удаляем + ищем в каждом расшаренном/доменном ресурсе в папке Recycle.bin, Recycle, Recycled/S-многоцифр/файл(ы).vmx и удаляем их.
9. Ставим везде длинные пароли, особенно для админа, удаляем гостевые аккаунты; это необходимо, т.к. Conficker брутфорсит компы и пытается запуститься удаленно через RPC даже при установленных патчах.
10. Ставим WireShark на чистую машину. Включаем на прослушку сети. Начинаем включать по 10-20 машин в час, симптомы присутствия червя -- NB запросы NB NAME WWW.GETIP или NB NAME (бессмысленный набор заглавных букв).(две буквы) и/или множество запросов ARP с адресами из текущей подсети, которые исходят с одной машины. Если появились, значит машину недолечили; отключаем от сети, проверяем с 0-го пункта.

Инструкция выложена только для того, чтобы теперь я мог просто давать ссылку, а не искать файл с ней. ;)

P.S.S.: Кстати говоря, думаю на выпуск "ультимативного патча от MS,  который, наконец, полностью отключает автозапуск" именно сейчас, а не полгода, год или 5 лет назад именно Conficker оказал непосредственное влияние. Хоть какая-то польза, но суммарный вред причиненный им она вряд ли компенсирует. 

Когда робот страшнее DDoSа

Совмещение косяков различного софта иногда дает потрясающие эффекты.  Буквально пару дней назад, один из сайтов, находящихся в моем ведении стал вести себя очень подозрительно. С внешней стороны создавалось впечатление, что сайт находится под постоянной DDoS-атакой или на сервере что-то медленно умирает. Остановка сервера, перезагрузка, проверка памяти/диска и повторный запуск не помогли -- сразу после поднятия Apache эффект возобновился. Но судя по netstat'у все признаки DDoS-атаки отсутствовали. Более того, график mrtg не показывал увеличения входящих соединений, а даже их некоторое снижение.

Лишь подключение к серверу БД и show full processlist дало частичный ответ почему сайт так странно себя ведет. На нашем сайте (это онлайн игра) есть несколько страниц, связанных с отображением данных из довольно объемной таблицы. Скрипт, отвечающий за эту страницу был написал кривовато, что вызывало при обращении к этой странице небольшие lock'и у остальных запросов. Данные из таблицы отображались в количестве 100 строк на страницу; внизу страницы присутствовал индекс для перехода к остальным данным (всего там было ~10000 страниц по 100 записей на каждой). Время выполнение скрипта в обычном режиме -- около 4-х секунд на страницу, при этом многие важные таблицы lockались на 200-300мсек. Скрипт сильно устарел, таблица была с кривыми индексами и все это явно нуждалось в переделке, но возникал справедливый вопрос -- почему начало тормозить лишь позавчера, а не неделю, месяц или год назад? Страничка с этим скриптом была редкопосещаемой и до текущего момента не влияла на производительность сайта.

Быстрый взгляд в логи апача дал ответ практически сразу же: некий узел производил каждую секунду запрос именно к этой странице. Причем, судя по логам, если этот узел не успевал в течении 1 секунды скачать страницу (а он, конечно же, не успевал), то попытки не прекращались, а инициировался еще один запрос к этой странице, даже не разрывая предыдущий. На момент обнаружения, узел уже дошел до страницы с индексом 60 (из ~10000). И это за более чем двое суток!  На загрузку некоторых страниц он тратил несколько часов и порядка 8000 запросов! Более того, судя по всему загрузка проводилась в несколько потоков, т.к. одновременно шли попытки загрузить script.php?page=60, ..., script.php?page=67. nslookup ip-адреса выдавал обратную зону, принадлежащую одному не очень популярному российскому поисковику. Не умаляя моего косяка, заключащегося в том, что не сразу распознал в чем проблема, и косяков наших php/sql-программистов которые пишут кривые скрипты, мне все-таки очень хочется знать, какой квалификацией обладали люди, разрабатывавшие этот поисковый робот и о чем они думали в процессе его написания. Согласитесь, все-таки 8000 повторных попыток загрузки одной и той же страницы даже nmap в режиме -T5(insane) не производит. ;)