В пакетном фильтре ipfw, входящем в состав FreeBSD 6.0, обнаружена неприятная уязвимость (ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA...). Удаленный злоумышленник может вызвать отказ в обслуживании отправив специально сформированный пакет, подпадающий под "reset", "reject" или "unreach" правило фаервола.
Проблем можно избежать заменив все "reset", "reject" и "unreach" действия на "deny".
Также опубликованы еще три сообщения о незначительных проблемах безопасности во входящих в базовую поставку FreeBSD 6.0 приложений:- Multiple vulnerabilities cpio (ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA...);
- ee temporary file privilege escalation (ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA...);- Texindex temporary file privilege escalation (ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA...).
URL: ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA...
Новость: http://www.opennet.me/opennews/art.shtml?num=6785
В чем выражается отказ в обслуживании ? kernel panic ?
нормальные allow пакеты перестают проходить...
thanx for founded bug + respect
а я по жизни только deny и прописывал :-(
весёлый был тред, я хохотал до упаду. Особенно первый: "ну вот, началось!" :-))
Что можно сказать то здесь не в оффтопик?!
Ну нашли уязвимость, исправят теперь. Молодцы! Я тоже, кстати, кроме deny ничем не пользовался раньше. Даже и не знал о таких возможностях, надо почитать.
Надо вообще делать поменьше всяких прибамбахов. Нафиг они нужны, если никто не юзАет? KISS!
И pf я тоже юзаю. удобно пользовать pf для NAT и для логгинга, а ipfw для фильтрации. Незнаю, правда, эффективно ли это? в ядре сразу два фильтра наверное медленнее работает, чем один.Спасибо разработчикам!
> Я тоже, кстати, кроме deny ничем не пользовался раньше. Даже и не знал о таких возможностях, надо почитать.
Зря так. На компах через которые проходит веб-трафик, пакеты на как минимум один порт (113) надо не дропать, а режектить(т.е. ICMP посылать в ответ). Иначе часть сайтов (в основном - форумов) тормозить будет. Причем сильно.
Да, хотелось юы поподробнее узнать, в чем разница?
Нет ссылочки под рукой на разжёванное?
>Да, хотелось юы поподробнее узнать, в чем разница?
>Нет ссылочки под рукой на разжёванное?Некотарая часть сайтов при запросе страниц пытаются установить встречное соединение по этому порту. Если оно отбивается с port unreachable - то отдача страницы продолжается дальше сразу. Если в правилах стоит deny и в ответ ничего не приходит, то отдача страницы продолжается только по истечении таймаута на SYN+ACK ответ.
Для чего они так делают я точно не знаю, ответ можно поискать в RFC на auth сервис которому выделен этот порт.
>>Да, хотелось юы поподробнее узнать, в чем разница?
>>Нет ссылочки под рукой на разжёванное?
>
>Некотарая часть сайтов при запросе страниц пытаются установить встречное соединение по этому
>порту. Если оно отбивается с port unreachable - то отдача страницы
>продолжается дальше сразу. Если в правилах стоит deny и в ответ
>ничего не приходит, то отдача страницы продолжается только по истечении таймаута
>на SYN+ACK ответ.
>Для чего они так делают я точно не знаю, ответ можно поискать
>в RFC на auth сервис которому выделен этот порт.Чего-то я первый раз об этом слышу. Но, ИМХО, какая-то наркотическая практика, напоминающая active ftp transfer.
>Для чего они так делают я точно не знаю, ответ можно поискать
>в RFC на auth сервис которому выделен этот порт.Кстати, а можно URL'ы подобных ресурсов?
> Кстати, а можно URL'ы подобных ресурсов?Поскольку с этими граблями лет 5 назад разбирался, сейчас не вспомню. Тогда таких сайтов было немало.
Из того, что сейчас есть, можно глянуть, например, http://www.math.uwaterloo.ca/mfcf/faq/www_browse.html#www/id... - описание решения этой проблемы для http://www.math.uwaterloo.ca/mfcf/, но где там такие страницы расположены - не знаю, не искал.
поподробнее, почему так происходит? режектить надо на шлюзах?
>поподробнее, почему так происходит? режектить надо на шлюзах?Боюсь оскорбить BSD-шников (судя по долгим наблюдениям за форумом на opennet, многие из высказывающихся - воинствующие снобы), но моё мнение такое: режектить надо всё, что не нужно пропускать, за исключением случаев явных атак, ибо ICMP сообщение о недостижимости сервиса убыстряет, облегчает (и всё такое) отладку сети другими жителями интернета.
>судя по долгим наблюдениям за форумом на opennet, многие
>из высказывающихся - воинствующие снобы
согласен на 100%, но все таки лучше воинствующие снобы, чем воинствующие пустозвоны (это я про нехилую армия линуксоидов), правда?
А вот с мнением про тотальный reject я бы не согласился. Не надо забывать, что помимо админов есть еще и люди, занимающиеся безопасностью. Зачастую такие товарищи просто вынуждены в своей работе пользоваться разными там инструкциями и циркулярами, которые в основном требуют режектить траффик на локальных интерфейсах и тихо сбрасывать на внешних. Такие правила существуют не для красного словца, а почему так - это тема для нехилой статьи.
Могу посоветовать простой тест - сперва посканировать с помощью nmap firewall с правилами сброса типа deny, а потом заменить deny на reject и сравнить время, которое ушло на первый и второй скан. Для взломщика может такая разница и не важна, а вот безопаснику лишние несколько минут форы никогда не помешают. Опять же, больше режектов, более точный результат сканирования хоста на предмет определения действующих правил фильтрации. И т.д и т.п.