Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Cisco standard IOS extended ACL & RST,ACK & established 02.08.04 02:58 Число просмотров: 1414
Автор: void <Grebnev Valery> Статус: Elderman
|
Полгода назад обсуждалась тема по поводу возможности использования пакетов с одновременно установленными флагами RST, ACK для исследования систем.
Был неплохой коментарий одного из гостей форума в этой части. Напомню, что суть комментария
была в том, что ответ хоста на нестандартный пакет ("неправильный" с точки зрения RFC) можно использовать, в качестве части работы по идентификации системы. Ниже о дополнительной возможности исследования систем и о том, как немного поправить положение.
Стандартный IOS Cisco не держит "по-настоящему" установленные TCP соединения. Это значит, что
популярная у админов в extended ACL строчка на внешнем интерфейсе для входящего из инет трафика:
permit tcp any x.y.w.z 0.0.0.n established
будет легко пропускать указанные пакеты. Связано это с тем, что стандартный IOS понимает established
весьма тупо - она только контролирует наличие флагов RST и ACK в хедере TCP. Если есть эти флаги,
то стандартный IOS циски думает, что пакеты принадлежат к ранее установленным соединениям и легко
пропускает это хозяйство внутрь сети. Ранее упомянутая "популярность" связана с тем, что многие админы для "установленных" соединений ограничиваются только одной строчкой.
Таким образом, можно определить, что стоит в горле сетки, и более того -" RST, ACK просканить" внутренюю сетку за межсетевым экраном (циской). Здесь RST, ACK - сканирование мы, разумеется, не путаем с тупым SYN-сканированием, которое будет невозможно при минимально качественных ACL.
Как улучшить ситуацию ясно, думаю, всем:
1) купить расширенную версию IOS с фаревольными функциями, что держит рефлексив ACL. Здесь cisco должна по аналогии с фареволом контролировать не только флаги пакетов, но и "истинную" принадлежность пакетов к установленным соединениям по значению поля (полей, приналичии SACK permited), что определяет текущую полследовательность байт. Лично мне этот опыт неизвестен.
Вернее, мы купили. Но не работает.
2) ещё дороже решение - покупать cisco PIX.
3) не очень дорогое решение - купить фаревол, хоть бы от M$. Поставить его за циской, за её внутренним интерфейсом. Почти не сомневаюсь, что низкокачественные фаревольные решения M$в_паре_с_цискойдадут не плохой результат. Это так, ибо изделия M$ умеют отслеживать последовательности байт в полях ACK и опциях TCP (если разрешён SACK для текущего соединения).
4) писать стандартные ACL, где разрешаются установленные соединения (established) только от тех сервисов в инете, что надо. Это немного снизит, число "исследователей":
permit tcp any eq domain x.y.w.z 0.0.0.n established
permit tcp any eq www x.y.w.z 0.0.0.n established
permit tcp any eq 443 x.y.w.z 0.0.0.n established
...
...
По моему опыту, п.4 практически полностью (пока ;))) ) избавил меня от RST,ACK. Хотя, конечно, с точки зрения нормального фаревол, где достаточно одной строчки для established - ACL выглядит гиморно и параноидально ;((
|
- Cisco standard IOS extended ACL & RST,ACK & established - void 02.08.04 02:58 [1414]
|
|
|
подробно о проекте
Анализ криптографических сетевых...
