The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

ipfw из комплекта FreeBSD 6.0 подвержен DoS атаке

13.01.2006 00:08

В пакетном фильтре ipfw, входящем в состав FreeBSD 6.0, обнаружена неприятная уязвимость. Удаленный злоумышленник может вызвать отказ в обслуживании отправив специально сформированный пакет, подпадающий под "reset", "reject" или "unreach" правило фаервола.

Проблем можно избежать заменив все "reset", "reject" и "unreach" действия на "deny".

Также опубликованы еще три сообщения о незначительных проблемах безопасности во входящих в базовую поставку FreeBSD 6.0 приложений:

  1. Multiple vulnerabilities cpio;
  2. ee temporary file privilege escalation;
  3. Texindex temporary file privilege escalation.


  1. Главная ссылка к новости (ftp://ftp.freebsd.org/pub/Free...)
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/6785-freebsd
Ключевые слова: freebsd, security, ipfw
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (14) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 12:45, 13/01/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    В чем выражается отказ в обслуживании ? kernel panic ?
     
     
  • 2.5, ws (ok), 13:54, 13/01/2006 [^] [^^] [^^^] [ответить]  
  • +/
    нормальные allow пакеты перестают проходить...
     
  • 2.3, cp dev (?), 13:38, 13/01/2006 [^] [^^] [^^^] [ответить]  
  • +/
    thanx for founded bug + respect
     

  • 1.4, Аноним (-), 13:53, 13/01/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    а я по жизни только deny и прописывал :-(
     
  • 1.19, link (??), 19:46, 14/01/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    весёлый был тред, я хохотал до упаду. Особенно первый: "ну вот, началось!" :-))
    Что можно сказать то здесь не в оффтопик?!
    Ну нашли уязвимость, исправят теперь. Молодцы! Я тоже, кстати, кроме deny ничем не пользовался раньше. Даже и не знал о таких возможностях, надо почитать.
    Надо вообще делать поменьше всяких прибамбахов. Нафиг они нужны, если никто не юзАет? KISS!
    И pf я тоже юзаю. удобно пользовать pf для NAT и для логгинга, а ipfw для фильтрации. Незнаю, правда, эффективно ли это? в ядре сразу два фильтра наверное медленнее работает, чем один.

    Спасибо разработчикам!

     
     
  • 2.20, Wulf (?), 01:36, 15/01/2006 [^] [^^] [^^^] [ответить]  
  • +/
    > Я тоже, кстати, кроме deny ничем не пользовался раньше. Даже и не знал о таких возможностях, надо почитать.
    Зря так. На компах через которые проходит веб-трафик, пакеты на как минимум один порт (113) надо не дропать, а режектить(т.е. ICMP посылать в ответ). Иначе часть сайтов (в основном - форумов) тормозить будет. Причем сильно.
     
     
  • 3.22, link (??), 14:14, 15/01/2006 [^] [^^] [^^^] [ответить]  
  • +/
    Да, хотелось юы поподробнее узнать, в чем разница?
    Нет ссылочки под рукой на разжёванное?
     
     
  • 4.23, Wulf (?), 17:00, 15/01/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >Да, хотелось юы поподробнее узнать, в чем разница?
    >Нет ссылочки под рукой на разжёванное?

    Некотарая часть сайтов при запросе страниц пытаются установить встречное соединение по этому порту. Если оно отбивается с port unreachable - то отдача страницы продолжается дальше сразу. Если в правилах стоит deny и в ответ ничего не приходит, то отдача страницы продолжается только по истечении таймаута на SYN+ACK ответ.
    Для чего они так делают я точно не знаю, ответ можно поискать в RFC на auth сервис которому выделен этот порт.

     
     
  • 5.24, chip (ok), 17:02, 15/01/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >>Да, хотелось юы поподробнее узнать, в чем разница?
    >>Нет ссылочки под рукой на разжёванное?
    >
    >Некотарая часть сайтов при запросе страниц пытаются установить встречное соединение по этому
    >порту. Если оно отбивается с port unreachable - то отдача страницы
    >продолжается дальше сразу. Если в правилах стоит deny и в ответ
    >ничего не приходит, то отдача страницы продолжается только по истечении таймаута
    >на SYN+ACK ответ.
    >Для чего они так делают я точно не знаю, ответ можно поискать
    >в RFC на auth сервис которому выделен этот порт.

    Чего-то я первый раз об этом слышу. Но, ИМХО, какая-то наркотическая практика, напоминающая active ftp transfer.

     
  • 5.25, chip (ok), 17:02, 15/01/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >Для чего они так делают я точно не знаю, ответ можно поискать
    >в RFC на auth сервис которому выделен этот порт.

    Кстати, а можно URL'ы подобных ресурсов?


     
     
  • 6.28, Wulf (?), 14:51, 16/01/2006 [^] [^^] [^^^] [ответить]  
  • +/
    > Кстати, а можно URL'ы подобных ресурсов?

    Поскольку с этими граблями лет 5 назад разбирался, сейчас не вспомню. Тогда таких сайтов было немало.
    Из того, что сейчас есть, можно глянуть, например, http://www.math.uwaterloo.ca/mfcf/faq/www_browse.html#www/ident_timeout.faq - описание решения этой проблемы для http://www.math.uwaterloo.ca/mfcf/, но где там такие страницы расположены - не знаю, не искал.

     

  • 1.21, airo (?), 12:09, 15/01/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    поподробнее, почему так происходит? режектить надо на шлюзах?
     
     
  • 2.26, impatt (??), 08:05, 16/01/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >поподробнее, почему так происходит? режектить надо на шлюзах?

    Боюсь оскорбить BSD-шников (судя по долгим наблюдениям за форумом на opennet, многие из высказывающихся - воинствующие снобы), но моё мнение такое: режектить надо всё, что не нужно пропускать, за исключением случаев явных атак, ибо ICMP сообщение о недостижимости сервиса убыстряет, облегчает (и всё такое) отладку сети другими жителями интернета.


     
     
  • 3.29, scum (??), 18:05, 17/01/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >судя по долгим наблюдениям за форумом на opennet, многие
    >из высказывающихся - воинствующие снобы
    согласен на 100%, но все таки лучше воинствующие снобы, чем воинствующие пустозвоны (это я про нехилую армия линуксоидов), правда?
    А вот с мнением про тотальный reject я бы не согласился. Не надо забывать, что помимо админов есть еще и люди, занимающиеся безопасностью. Зачастую такие товарищи просто вынуждены в своей работе пользоваться разными там инструкциями и циркулярами, которые в основном требуют режектить траффик на локальных интерфейсах и тихо сбрасывать на внешних. Такие правила существуют не для красного словца, а почему так - это тема для нехилой статьи.
    Могу посоветовать простой тест - сперва посканировать с помощью nmap firewall с правилами сброса типа deny, а потом заменить deny на reject и сравнить время, которое ушло на первый и второй скан. Для взломщика может такая разница и не важна, а вот безопаснику лишние несколько минут форы никогда не помешают. Опять же, больше режектов, более точный результат сканирования хоста на предмет определения действующих правил фильтрации. И т.д и т.п.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру