>Атакующий может вызвать крах прокси-сервера, послав единственный UDP пакет.

Уууууу... Вот кулхацкерам раздолье!

спасибо Sun-ch

А нечего на внешнем интерфейсе к нему доступ раздавать. И snmp прикрыть фильтром, открыв для хоста админа исключительно. Так что, фигня. :))

Саныч, признавайся -- у тебя много сквидов со включенным snmp? А не прикрытых файрволом?

Антон, тебе задание: найти squid с доступным snmp.

Положили? Надо было ставить Слаку!

а смысл?

Я чё то затупил.

Во всех конфигах такие строчки

acl snmppublic snmp_community public
acl snmpjoebloggs snmp_community joebloggs

Я так понимаю, что snmp у меня держит какой Джоеблогс, ну и фамилия :)

Кто это такой, может кто знает?

это Карабас-Барабас, только компьютерный:-)

Саныч, не бери разную херню в голову, Работает -- не трогай (с)... ;)

>> snmp у меня держит какой Джоеблогс

Список доступа. Действительно, можешь его хоть KarabasBarabas его назвать.

squid-2.5.STABLE7 все поправлено, а вышел он 3 дня назад

Но хватает перечитать дефолтный конфиг и перерыть сначала все руками 1 раз - столько всякой фигни выкидывается.

Squid подвержен не только remote DOS

Привет,
хорошая статья была (руководство для начинающего web-hackera)
http://www.sanctuminc.com/pdf/WhitePaper_HTTPResponse.pdf
Там есть параграф
"Cache Poisoning with Squid 2.4 - Practical Considerations"
Интересно, починили ли они это в Squid 2.5 Stable?

Regards. Марк Ковкин

<offtopic> Вопрос к админам: зачем использовать какие-то сквиды, когда есть IP Masquerading? </offtopic>

>зачем использовать какие-то сквиды, когда есть IP Masquerading?

функциональность прокси и NAT мало пересекаются. читай доки =)

> Вопрос к админам: зачем использовать какие-то сквиды, когда есть IP Masquerading?

Это глупый вопрос!

Точнее, прокси в себя включет всю функциональность по переадресации пакетов :-)

NAT - некэширующий пркси с широчайшими возможностями
squid - кэширующий прокси для ограниченного набора протоколов (если извращениями не заниматься).
:-)

>Точнее, прокси в себя включет всю функциональность по переадресации пакетов :-)

не всю =)

>> Точнее, прокси в себя включет всю функциональность по переадресации
>> пакетов :-)

> не всю =)

Всю. На то он и абстрактный прокси. :-)
А дальше пошли уже конкретные реализации с конкретными названиями и возможностями. ;-)

А что НАТ кэширует файлы?

>А что НАТ кэширует файлы?

а где я такое сказал?

>Всю. На то он и абстрактный прокси. :-)

не надо меня на слове ловить =)

посмотри на топик =)

SNMP не нужен

>Вопрос к админам: зачем использовать какие-то сквиды, когда есть IP Masquerading?

А кэшировать, рекламу и порнушку фильтровать? А отчеты по юзерам и пользованию Инетом получать? Или у Вас халявный Инет, юзеры чего хотят, то и творят?

Зачем НАТ? Можно абсолютно все сделать и без него через разного рода прокси и туннели...

Кэшировать порнушку и фильтровать рекламу...

> И snmp прикрыть фильтром, открыв для хоста админа исключительно

учитывая, что snmp - это udp, спуфить могут давже кулхакеры...

При правильной настройке это будет возможно только из локалки. Ну положит кулхацкер проксю, и будет, как хакер из анекдота, сидеть без интернета :)

А расскажите анекдот.

Блин, да! Есть пара серверов, на которых Squid поднят на фсех интерфейсах, пойду чинить пока не сломано :D Апдейтить лень как-то.

>NAT - некэширующий пркси с широчайшими возможностями

>squid - кэширующий прокси для ограниченного набора протоколов

Полное непонимание принципиального отличия NAT и proxy.

Первый просто форвардит оригинальные пакеты, на проходе подменяя поле src ip и, возможно, src port.

Второй выступает со стороны клиента в качестве сервера, а снаружи прикидывается клиентом. Т.е. исходные пакеты "поглощаются" проксей, а наружу выходят совершенно новые пакеты.

Из этого вытекает достаточно много следствий.

В принципе, NATу все равно какой протокол прикладного уровня пропускать (исключения - специфические протоколы, типа FTP, которые передают ip адреса в поле данных. Для таких протоколов нужна специальная поддержка). Прокси же всегда рассчитан на работу с конкретными протоколами 7-го уровня. И если для специфического протокола прокси еще не написан - труба! (Например PPTP. Я не знаю прокси для gre)

Со стороны клиента NAT абсолютно "прозрачен". В случае прокси - обязательна поддержка конкретного типа проксей в клиенте, что не всегда осуществимо.

Для NATa существует проблема фрагментации. У любого прокси - отсутствует.

Если на интерфейсах разные MTU, NAT может вовсе перестать работать, т.к. не способен пересобирать пакеты. Для любого прокси эта проблема решается естественным образом.

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

SNMP - Security is Not My Problem :)

Покажите мне идиота, у которого squid снаружи не прикрыт файрволом.

Ессно, надаже админу както денюжку на икорку нашукать

Поясните пожалуйста, почему у NAT должны быть проблемы с дефрагментацией?

Поверь на слово есть проблемы с MTU Классический пример: Локалка 192.168.x.x, на рутере реальный IP и туннель gre через который гонится весь трафик. Моментально огребаешься граблями по самое небалуйся.

Помогает -A POSTROUTING -o tunnel -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1360

Оно: http://www.google.ru/search?hl=ru&q=PPTP+proxy&btnG=%D0%9F%D0%BE%D0%B... ?

>Покажите мне идиота, у которого squid снаружи не прикрыт файрволом.

А это как? Stateful Packet Filter?

>Поверь на слово есть проблемы с MTU Классический пример

теорию объяснить слабО? Может всё дело в том, что некоторые "эксперты по безопасности" блокируют icmp? У меня с NAT и тоннелями никогда таких проблем не было.

Кулхацкеры из локалки получат по морде.

Ага, с тупыми админами можно положить все, что угодно

Абсолютно точно: NAT здесть ни при чем.

Поломал хакер провайдера, и теперь сидит, как дурак, без Интернета :)

2anonymous (*) (15.10.2004 5:59:17)
>Первый просто форвардит оригинальные пакеты, на проходе подменяя поле
> src ip и, возможно, src port.

>Второй выступает со стороны клиента в качестве сервера, а снаружи
> прикидывается клиентом. Т.е. исходные пакеты "поглощаются" проксей, а
> наружу выходят совершенно новые пакеты. 

Сюда еще добавить, что прокси организовывает ДВА ОТДЕЛЬНЫХ соединения. 
От клиента до себя и от себя до сервера.
NAT же, акромя подмены в заголовке пакета, ничего делать не должОн.
Все остальные навороты NAT-ов это свойства конкретных реализаций ;-)

Посему на firewall (не путайте с фильтрующим роутером) и возможно
применения только проксирования.  ;-)

>У меня с NAT и тоннелями никогда таких проблем не было.

Попробуй на своих виндовых клиентах выключить "Path MTU Discovery" и поставь фиксированное значение MTU=1500 (для ethernet). Тогда и поймешь, почему у тебя, якобы, нет проблем с тоннелями.

А представляешь себе, как "Path MTU Discovery" тормозит TCP стэк.

А на каких виндовых клиентах "Path MTU Discovery" включен по умолчанию?

ну у меня сквид снаружи не прикрыт фиреволом и что? мне удобно когда клиенты подсоединяются к конкурирующему провайдеру и видят сообщение об ошибке на русском языка

а что касается нат так попробуйте сквозь прокси какойнибудь real-time протокол типа rpd - полная лажа.

>Попробуй на своих виндовых клиентах выключить "Path MTU Discovery"

т.е. предлагается сначала самому что-то сломать, чтобы увидеть проблему? Гениально.

>А представляешь себе, как "Path MTU Discovery" тормозит TCP стэк.

"А мужики-то не знают"

>А на каких виндовых клиентах "Path MTU Discovery" включен по умолчанию?

да, afaik, на всех
PMTUD стар как мир

>> теорию объяснить слабО?

http://en.tldp.org/HOWTO/IP-Masquerade-HOWTO/mtu-issues.html

> > А на каких виндовых клиентах "Path MTU Discovery" включен по умолчанию?

> да, afaik, на всех
> PMTUD стар как мир

Ага, это я с EnablePMTUBHDetect перепутал, который по умолчанию выключен.