- Необходимо отключить "защиту от дурака" в прошивке Nokia, не позволяющую подключать устройства, которым может не хватить питания от встроенного порта USB при помощи команды echo 1 > /sys/bus/usb/devices/1-1/bConfigurationValue . Вместо 1-1 у вас может быть другое число, которое легко посмотреть в dmesg'e.
- Вручную insmod'нуть rt73.ko
- Поднять появившийся интерфейс с помощью ifconfig wlan1 up.
- Перевести его в режим мониторинга последовательно выполнив iwpriv wlan1 rfmontx 1 , а затем iwconfig wlan1 mode monitor .
ACK on SYN
суббота, 12 ноября 2011 г.
N8x0 packet injection при помощи Edimax ew-7318usg
среда, 8 апреля 2009 г.
IceScan 0.0.7rc1
Выпустил (и двух лет не прошло :) ) очередную версию моего сетевого сканера портов IceScan 0.0.7rc1. Версия 0.1 все ближе и ближе. IceScan, это наверное попытка повторить функциональность nmap'а с некоторыми фишками, которых в nmap'е возможно никогда не будет.
Основные "фичи" IceScan'а:
- Активные методы сканирования и обнаружения хостов: TCP SYN/ACK/connect()/FIN и др., UDP, IP, ARP, ICMP.
- Пассивное сканирование и OS fingerprinting.
- Параллельный DNS-резольвер, который, в отличие от nmap'а может резолвить не только обратные, но и прямые адреса.
- Несколько форматов вывода результатов, в т.ч. и в виде tcpdump-файлов.
- Множество опций для настройки сканирования, например, таких как установка TTL, опций TCP и UDP и др.
- Возможность сканировать через удаленный HTTP-прокси сервер.
- Работает под Windows, Linux и OpenBSD.
Конечно же ранняя альфа, она и есть альфа и сейчас IceScan помимо наверняка присутствующих в нем багов обладает существенным недостатком -- он в три-четыре раза медленнее чем nmap. Но я работаю над исправлением этой особенности ;). Любая помощь проекта весьма приветствуется, так как с контрибуторами пока проблемы ;)
Скачать можно отсюда: http://sf.net/projects/icescan
P.S.: Ресечер с ComputerDefence обнаружил любопытную особенность в Apache : иструкция AddType в конфиге включает тип файлов не только для файлов с указанным расширением, но и для всех файлов содержащих эту строку. (например, не только phpinfo.php, но и phpinfo.php.bak будут определяться как application/x-httpd-php при указании AddType application/x-httpd-php .php). В статье говорится, что 2.2.x не обладают этой "фичей", а 1.3.x -- обладают. Просмотрев свои сервера, обнаружил, что версии 2.0.x и 1.3.x действительно обладают этой особенностью (кроме Apache/1.3.29(OpenBSD)), а версии 2.2.x ей не подвержены. Посмотрим, что будет дальше.
четверг, 2 апреля 2009 г.
Tiny Core Linux
Наткнулся я тут на занимательный LiveCD/дистрибутив Tiny Core Linux. Чем он так замечателен? Во-первых образ LiveCD занимает всего 10Mb. По сути, все содержимое диска состоит из ядра, syslinux'а и initrd. В initrd и содержится вся система. По умолчанию, там есть Tiny X, jwm в качестве менеджера окон, Wbar, SSH-сервер и клиент, несколько сетевых утилит и программ для работы с диском. Во-вторых он очень нетребователен -- 32 мегабайт и 100MHz процессора будет вполне достаточно для работы. В-третьих, набор программ -- это еще не все. С сайта дистрибутива можно загрузить пакеты с дополнительными программами, которые доступны в виде TCE и TCZ расширений, которые могут быть "присоединены" к работающей системе "на лету" с различных носителей или по сети. TCE-пакеты распаковываются в память, а TCZ-пакеты при подключении монтируются в виде loop-устройств. В четвертых, расширения и содержимое каталога пользователя могут быть сохранены в виде локального файла и на разделе (в т.ч. и шифрованном файле/разделе). Ну и в пятых, TCL может быть установлена на локальный диск. :)
Для TCL уже доступно множество программ в виде TCE или TCZ расширений. Полный список можно увидеть тут(TCE) и тут(TCZ). Там довольно много приложений, даже OpenOffice есть. Кроме того, там есть замечательный пакет compiletc, который позволяет собирать собственные пакеты для TCL. На wiki дистрибутива есть подробная статья об том, как правильно собрать расширение.
К сожалению, в пакетах почему-то не оказалось nmap'а и некоторых других security-утилит. Впрочем, потратив порядка трех часов я исправил это упущение, собрав несколько пакетов: AirCrack-NG, ChNTPw, HPing2, httptunnel, iodine, nmap, socat, stress, tcptunnel, udptunnel. Скачать TCE и TCZ расширения для них можно отсюда: http://tinycorelinux.timeold.ru/.
Кроме того, TCL может быть установлен на флэшку, в том числе, если использовать syslinux, и на флэшку с FAT'ом. Если у вас в /mnt/cdrom смонтирован образ диска или сам диск, а в /mnt/usb (устройство /dev/sdb1) -- флэшка, то делается это так (пакет syslinux должен быть заранее установлен):
cp -r /mnt/cdrom/boot /mnt/usb/
mv /mnt/usb/boot/isolinux /mnt/usb/boot/syslinux
mv /mnt/usb/boot/syslinux/isolinux.cfg /mnt/usb/boot/syslinux/syslinux.cfg
syslinux /dev/sdb1
P.S.: Поскольку диск с BackTrack'ом или Knoppix'ом, я все время забываю носить с собой (особенно тогда, когда они вдруг становятся очень нужны), нашел для себя решение в виде немного модифицированного мною LiveCD Tiny Core Linux. Теперь он занимает 22Mb, а не 10, но обладает всеми теми же свойствами, кроме того, содержит все пакеты, которые мне бывают позарез необходимы, а именно: 915resolution, advcomp, cfdisk, chimera2, cpio, dosfstools-3, extlinux, hwinfo, jfsutils, lsof, menu-tool, mkisofs-tools, nfs-utils, partimage, pci-utils, rdesktop, resize2fs, vsftpd, wget, wpa-supplicant + пресловутые AirCrack-NG, ChNTPw, HPing2, httptunnel, iodine, nmap, socat, stress, tcptunnel, udptunnel. Скачать ISOшник можно отсюда(MD5). Для нормальной работы рекомендуется не менее 64Mb RAM.
P.S.S.: А еще, TCL это именно тот дистрибутив, который можно легко загрузить в каком-нибудь IP-KVM'е для восстановления рухнувшего сервера. ;)
пятница, 27 марта 2009 г.
Нет, это уже слишком!
Скрипт 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. Более подробно можно прочитать тут.
суббота, 14 марта 2009 г.
О вирусах, самоподписанных сертификатах и 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 к счастью не затронул ни один компьютер в моих конторах. Но вот знакомые и коллеги пару-тройку раз звали помогать справиться с ним. ;) Небольшая инструкция по борьбе с этим зверем, которую в последние разы я им просто отсылал, прилагается ниже.
- Ищем с помощью утилиты http://www.securitylab.ru/news/368759.php все непатченные машины. (огромное спасибо Сергею Гордейчику и Positive Technologies!)
- Отключаем ВСЕ машины от сети.
- Отключаем на ВСЕХ машинах автоматическое восстановление.
- Патчим ВСЕ непатченный машины патчами MS08-065, MS08-067 и MS09-001. (непатченные... патчами, простите за "масло масленное" ;))
- Отключаем автозапуск на всех машинах. (а еще лучше, ставим последнее обновление Microsoft, которое отключает AutoRun, см. http://support.microsoft.com/kb/967715).
- Запускаем KidoKiller + CureIT! последовательно (желательно запускать их с компакт-диска или защищенной от записи флэшки).
- Ставим последний антивирус (AVZ, DrWeb, F-Secure, Касперский), без перезагрузки проверяем.
- Ищем autorun.inf на всех расшаренных/доменных ресурсах, удаляем + ищем в каждом расшаренном/доменном ресурсе в папке Recycle.bin, Recycle, Recycled/S-многоцифр/файл(ы).vmx и удаляем их.
- Ставим везде длинные пароли, особенно для админа, удаляем гостевые аккаунты; это необходимо, т.к. Conficker брутфорсит компы и пытается запуститься удаленно через RPC даже при установленных патчах.
- Ставим WireShark на чистую машину. Включаем на прослушку сети. Начинаем включать по 10-20 машин в час, симптомы присутствия червя -- NB запросы NB NAME WWW.GETIP или NB NAME (бессмысленный набор заглавных букв).(две буквы) и/или множество запросов ARP с адресами из текущей подсети, которые исходят с одной машины. Если появились, значит машину недолечили; отключаем от сети, проверяем с 0-го пункта.
Инструкция выложена только для того, чтобы теперь я мог просто давать ссылку, а не искать файл с ней. ;)
P.S.S.: Кстати говоря, думаю на выпуск "ультимативного патча от MS, который, наконец, полностью отключает автозапуск" именно сейчас, а не полгода, год или 5 лет назад именно Conficker оказал непосредственное влияние. Хоть какая-то польза, но суммарный вред причиненный им она вряд ли компенсирует.
четверг, 5 марта 2009 г.
Когда робот страшнее 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) не производит. ;)