Можно я слегка покритикую?
Спасибо! >;->
BECHED писал(а):
1. Вступление ]
Многие статьи, описывающие принципы обхождения брандмауэров не описывают главного!
Того как можно их обнаружить... В данной статье я постараюсь восполнить этот пробел и рассказать вам сразу о двух принципах : принципе обнаружения и обхождения фаерволла...
Итак поехали...
Поехали.
BECHED писал(а):
[ 2. Принцип обнаружения ]
Как и следует ожидать, каждый фаерволл имеет свое имя, значит имеет некое "клеймо" в сети, т.е. некоторые фаерволлы открывают спец. порт, по которому вы можете узнать версию, название и другую интересную информацию.
То, что каждый файрволл имеет своё имя это естественно, - практически каждый софс имеет своё имя, однако это вовсе не значит, что он имеет "клеймо" в сети. На сколько я понимаю термин "клеймо" - речь идёт о некоем управляющем сервисе/демоне, поднятом на специфическом порту, служащим для управления/мониторинга собственно файрвола, - так вот: только
полный непрофессионал оставит такого демона/сервис слушать на внешнем интерфейсе. В крайнем случае пустит на внешний интерфейс по этому порту только с определённый адресов, при условии, естественно работающей защиты от IP-spoofing`а
BECHED писал(а):
При обнаружении фаерволла нужно быть очень внимательным и не упускать ничего мимо своих глаз. По сути обнаружение фаерволла делится на несколько этапов...Это и банальное сканирование, это отслеживание маршрутов, считывание сервисных банеров и т.д. Про каждый пункт обнаружения я постараюсь рассказать
подробнее. Так же хочу сказать, что существует некоторое количество спец. утилит, которые очень хорошо помогают при обнаружении фаерволлов... Про них я тоже постараюсь подробнее рассказать.
Итак, пришло время подробнее узнать о принципах обнаружения.
IMHO правильнее говорить не об обнаружении файрвола, а о его идентификации. И начинать оную следует с идентификации OS, на которую он нахлобучен. Разобраться: а шо ж такоэ этот OS fingerprinting? >;->
Дабы не растекаться мыслею по древу, просто кладу линки на почитайки:
Remote OS detection via TCP/IP Stack FingerPrinting
http://nmap.org/nmap-fingerprinting-article.txt(стянуть сам nmap
http://nmap.org/download.html)
Remote OS detection
http://neworder.box.sk/newsread.php?newsid=6843А remote active OS fingerprinting tool using ICMP
http://74.125.39.104/search?q=cache:SGz ... =firefox-aИ, естественно, википедия:
TCP/IP stack fingerprinting
http://en.wikipedia.org/wiki/Passive_OS_FingerprintingBECHED писал(а):
A. Банальное сканирование
Надеюсь многие из вас сканировали в сети порты какого-либо IP-адреса... У каждого сервиса есть свой уникальный порт, будь то ftp (21), http (80), ssh (22) и т.д.,
Нужно сказать, что частенько можно встретить демона, слушающего на нестандартном порту, например sshd на 2121 и т.п. Считается, что это слегка уменьшает количество атак, проводимых роботами и биороботами >;-> - вышеупомянутый sshd, слушающий на 2121, подвергался в половину меньшему количеству попыток войти тупым перебором (brute force attack, одно из лекарств от оного
http://www.digitalgenesis.com/software/phrel/ )
BECHED писал(а):
не обошло вниманием и фаерволлов, но не всех... Сразу скажу, что не все фаерволлы слушают порт.
Файрвол в принципе не может слушать порт, порт слушает управдяющий файрволом часть софтинки. Файрвол - софтинка для манипуляции с пакетиками. Баста.
BECHED писал(а):
Некоторые маскируются под демоны вроде порта 23 (на них обычно висит Cisco Router или ему по добные).
>;->>>>>>>>>>
Конечно файрвол "не маскируется под демоны вроде порта 23", просто на киске поднят telnetd, для которого как раз и есть стандартным порт 23. Замечу, что telnet - старый протокол, ssh появился ему на замену - в общем случае можно сказать, что ssh - telnet с криптованым траффиком.
Вариант удалённого управления киской по 23 порту достаточно распространён (был) и ничего удивительного в том, что киска откликается на 23 порту нет. Кроме того, что нужно срочно, извините за прямолинейность, выeбaть админа, рулящего ею, ибо нефиг светить телнетом в мир, тем паче пользовать оный в агрессивной среде.
BECHED писал(а):
Приведу некоторый список портов, на которых иногда висят фаерволлы или их менеджеры по умолчанию :
приложение: порт:
cisco-manager (mgmt) 4001 (6001, 2001)
checkpoint DNS (53udp/tcp) RIP (520udp)
cisco-xremotesrv 9001
wingate 8080, 81
realsecure 2998/2997/2999
Я никогда не строил checkpoint, но есть подозрение, что у пакета просто есть свой DNS
BECHED писал(а):
Скажу еще, что грамотно сконфигурированный фаерволл не даст вам сканировать порты в "массах", т.е. вы не сможете просканировать адрес, при сканировании более одного порта...
В принципе детектирование сканированя - задача не файрвола, это другой класс софта, а-ля IDS.
Кроме того, спобов сканирования существует, мягко говоря, более одного.
Портов тоже более одного (65535) и т.п.
Так что детектирование сканирования - не файрвольная задача.
Почитайка про IDS (intrusion detection system)
http://en.wikipedia.org/wiki/Intrusion-detection_systemИз известных софтин-детекторов сканирования - PortSentry, в своё время известная везчь, однако в 2002 фирму прикупила CISCO и дело как-то подзаглохло.
http://www.openfree.org/pet/index.php/I ... Portsentryhttp://sourceforge.net/project/showfile ... p_id=80573Что ловит PortSentry
* Connect scans - These are full connection scans. The entire TCP three way handshake is completed before being torn down. These types of scans also are the most obvious since the target host may record the fact that a connection from the scanning IP address was made.
* SYN scans - Also known as "half-open" scans are one way an attacker can try to enumerate ports on a system in a stealthy manner. These scans only execute the first two steps of the TCP 3-way handshake. The initiating system sends a TCP SYN packets as though it were requesting to open a full connection. The target system responds with a SYN-ACK packet. The initiator then sends a TCP RST (reset) packet back to the target, thereby closing the connection. The idea here is to prevent the full connection from being established since it may possibly be logged.
* FIN scans - These scans use packets with the TCP FIN flag set. Typically FIN packets are only seen during the closing sequence of a connection. Unsolicited FIN packets sent to a closed TCP port should illicit a RST packet from the other side.
* NULL scans - NULL scans use packet without any of the TCP flags set. Again, as per RFC 793, this should illicit a RST packet in return.
* XMAS scans - XMAS scans have the FIN, URG, and PUSH TCP flags set in the TCP header. Again, these are not technically "normal" packets seen across the internet (or even on a local LAN) and should illicit a RST from a closed port.
* FULL-XMAS scan - This scan has all of the TCP flags set (SYN,ACK,RST, FIN,URG,PSH). This type of packet should never be seen on a LAN much less the Internet.
* UDP scan - This scan is detected by the presence of multiple UDP packets originating from a single IP address.
Ну и конечно Snort.
http://www.sourcefire.com/products/snort/ BECHED писал(а):
Тогда действительно задача атакующего усложняется и приходится выдумывать некие способы сканирования (будь то сканирование с подменной source адреса ).
Если админ грамотный и задейсвовал средства против IPspoofing, то это будет проблематично.
BECHED писал(а):
Так же хочу сказать, что некоторые фаерволлы конфигурируются так, что во внутреннюю сеть доступ запрещен всем, кроме их же внутренней сети т.е. вы не сможете присоединиться к портам, которые фильтруются фаерволлом, если вы не принадлежите к внутренней сети хостинга или
локальной сети... Способов обхода таких защит не так уж много. Скажу лишь то, что один из способов сканирования "за фаерволлом" придумал небезызвестный всем бывший редактор журнала Phrack - Route. Его утилита Firewalk способна сканировать порты как бы за фаерволлом. Но
при этом так же не нужно полагаться на все 100%, что она правильно просканирует порты т.к. многие фаерволлы конфигурируются так, что фаерволл может определить TLL пакета до его при бытия (проверки по списку). Поэтому пакеты типа ICMP оповещающие о истечении TLL будут отсылаться в любом случае...
Стоит добавить, что в связи с недостаточным количеством IP адресов всё чаще и чаще локальным сетям выдают так называемые fake-адреса (private), которые в принципе не должны маршрутизироваться за пределами этих локальных сетей.
Это адреса
класс А - 10.0.0.0/8
класс В - 172.16.0.0/16
класс С - 192.168.x.0/24
Хосты из такой локальной сети выпускаются "в мир" при помощи NATа либо прокси серверов.
Доступ извне к хостам такой локальной сети может быть осуществлён при помощи портмаппинга либо опять-таки прокси серверов.
По поводу Firewalk:
Firewalk is an active reconnaissance network security tool that attempts to determine what layer 4 protocols a given IP forwarding device will pass. Firewalk works by sending out TCP or UDP packets with a TTL one greater than the targeted gateway. If the gateway allows the traffic, it will forward the packets to the next hop where they will expire and elicit an ICMP_TIME_EXCEEDED message. If the gateway hostdoes not allow the traffic, it will likely drop the packets on the floor and we will see no response.
То есть определяется лишь возможность прохождения пакета за шлюз, но, конечно же, речь никак не идёт о сканировании хостов, расположенных за ним.
BECHED писал(а):
Теперь перейдем к пункту об отслеживании маршрута прохождения пакета по сети...
B. Tracerouting
Многие надеюсь, сталкивались с программой типа tracert или traceroute, так вот скажу, то что эти программы способны отследить маршрут прохождения пакета по сети...
В WIN32 системах, утилита tracert.exe, а в Unix Like системах - traceroute.
Давайте рассмотрим пример прохождения пакета, чтобы идентифицировать фаерволл на пути прохо
ждения нашего udp/icmp пакета :
Трассировка маршрута к 168.75.176.102
с максимальным числом прыжков 30:
1 * 4366 ms * Loopback0.GW8.ALA2.nursat.net [195.82.29.53]
2 3373 ms * 4287 ms Ethernet0-0-2.GW1.ALA2.nursat.net [195.82.28.7]
3 * 4463 ms * Serial6-1.GW2.MOW1.nursat.net [195.82.28.198]
4 * * * Превышен интервал ожидания для запроса.
5 * * * Превышен интервал ожидания для запроса.
6 * * * Превышен интервал ожидания для запроса.
7 * * * Превышен интервал ожидания для запроса.
8 2274 ms 971 ms 958 ms so-2-3-1-zar1.skt.cw.net [166.63.220.69]
9 928 ms 945 ms 958 ms ge-3-3-0-ycr1.skt.cw.net [166.63.220.129]
10 954 ms 958 ms * so-1-0-0-ycr1.cpi.cw.net [208.173.216.25]
11 958 ms 958 ms 971 ms so-2-0-0-ycr2.cpi.cw.net [208.173.216.2]
12 981 ms 958 ms 958 ms so-2-0-0-bcr1.amd.cw.net [208.173.211.233]
13 1059 ms 1050 ms 1049 ms dcr1.nyk.cw.net [195.2.1.3]
14 1050 ms 1037 ms 1036 ms 65.59.192.13
15 1041 ms 1050 ms 1063 ms ge-0-3-0.bbr2.NewYork1.Level3.net [209.247.9.209]
16 1050 ms 1036 ms 1076 ms ge-7-0-0.edge1.NewYork1.Level3.net [64.159.4.150]
17 1050 ms 1063 ms 1050 ms xo-level3-oc12.NewYork1.Level3.net [209.244.160.178]
18 1050 ms 1062 ms 1076 ms p5-0-0.RAR1.NYC-NY.us.xo.net [65.106.3.37]
19 1115 ms 1523 ms 1757 ms p6-0-0.RAR2.Chicago-IL.us.xo.net [65.106.0.29]
20 1324 ms 1471 ms 1324 ms p1-0-0.RAR1.Dallas-TX.us.xo.net [65.106.0.34]
21 1141 ms 1141 ms 1141 ms p6-0-0.RAR2.LA-CA.us.xo.net [65.106.0.14]
22 1732 ms 1377 ms 1456 ms p4-0-0.MAR2.LasVegas-NV.us.xo.net [65.106.5.34]
23 1155 ms 1141 ms 1128 ms p15-0.CHR1.LasVegas-NV.us.xo.net [207.88.81.78]
24 1404 ms 1181 ms * 66.238.47.34.ptr.us.xo.net [66.238.47.34]
25 1614 ms 1378 ms 1378 ms 168.75.176.102
Трассировка завершена.
В выше приведенном примере очень ярко отображается структура прохождения пакета по сети.
Не структура, а маршрут :)
BECHED писал(а):
Можно предположить, что фаерволл создает некую цепочку адресов, по которым проходит наш пакет...
Никоим образом не создаёт. Он просто показывает узлы, которые пробегает пакет, проходя от хоста А к хосту В.
BECHED писал(а):
В трассировке по прыжкам 1-3 можно наблюдать, что dialup сервер фильтрует входящие пакеты,
Да? И откуда это видно?
На самом деле можно сказать, что хопы с 4 по 7 не отвечают по ICMP, при этом честно переправляют пакет дальше.
BECHED писал(а):
далее происходит послание пакета по сети по цепочке адресов... В конечном итоге можно видеть, что наш пакет приходит к месту назначения - 168.75.176.102... В этом случае могу сказать, что вероятнее всего фаерволл - 66.238.47.34, хотя 100 процентных результатов я не даю, т.к. в этом деле нужно быть крайне внимательным...
Не нужно быть крайне внимательным, чтобы заметить, что несколько последних хопов идут по us.xo.net. Так что 66.238.47.34 - айпишка провайдера, а вот пункт назначения - 168.75.176.102 скорее всего и есть айпишка, смотрящая в мир и скорее всего это адрес интерфейса машинки/шелезяки, на которой и поднят файрвол. :)
BECHED писал(а):
C. Считывание сервисных банеров.
Ну этот способ я думаю крайне прост, хотя на данный момент крайне трудно найти такой фаерволл, который бы выводил о себе информацию, но опять же "чем черт не шутит"... Считывание банеров заключается в том, что при подключении к фаерволлу, вы получаете некое послание
от удаленного фаерволла... Т.е. при соединении, например 295 (порт CheckPoint Firewall), вам выводиться информация о версии фаерволла, тогда вы с уверенностью можете идти искать в bugtraq уязвимость в этом фаерволле, чаще всего, когда я сталкивался с фаерволлами CheckPoint, мне выходила некая информация, я поначалу совсем не понимал что она
обозначает... А заключается она в том, что при подключении к фаерволлу CheckPoint, он вы водит некую последовательность цифр, например: 30003, 30002 и т.д. Как позже я узнал, что это свойственно фаерволлу CheckPoint...
Повторюсь: админ, выставляющий в свободный доступ порт сервиса/демона, который рулит файрволом - полный профан. :)
И ещё: почему-то не упоминаются ipf/ipfw/pf/iptables. А ведь они очень распорстранены :)
BECHED писал(а):
Ну вот по сути самые распространенные способы обнаружения вражеского фаерволла... Теперь
я хочу поведать вам несколько способов обхода обнаруженного фаерволла...
Итак, поехали...
[ 3. Принцип обхода ]
Начнем мы с того, что каждый фаерволл настроен на то, чтобы фильтровать пакеты, которые вы посылаете, когда соединяетесь с каким-либо портом удаленной машины.
Не настроен, файрвол это и есть пакетный фильтр, причём это частный случай :)
В общем случае
A firewall is a device or set of devices configured to permit, deny, encrypt, or proxy all computer traffic between different security domains based upon a set of rules and other criteria.
BECHED писал(а):
А это происходит на основании составленных правил фаерволла. Т.е. при подключении фаерволл считывает пакет и анализирует все данные...
Не считывает, эт принципиально не правильно! Получает.
BECHED писал(а):
Т.е. если ваш адрес не стоит в базе фаерволла, фаерволл не пропустит вас во внутреннюю сеть...
Угу. Тока подход к построению правил бывает разный.
К примеру:
- по умолчанию запрещаем всё, а потом разрешаем только то, что нужно
- наоборот, по умолчанию разрешаем всё, а потом запрещаем то, что нужно запретить
Если ваш адрес "стоит в базе фаерволла", тока прописан он как "дропать все пакеты, приходящие с этого адреса", то файрвол таки "не пропустит вас во внутреннюю сеть..." :))))))))))))))))))
BECHED писал(а):
На ум приходит множество способов обхода фаерволла. Первый, пожалуй самый легкий способ обхода, это сканирование подсети фаерволла на нахождение уязвимых машин и последующим взломом их... Так же скажу, что не всегда этот способ прокатывает, т.к. хороший администратор скорее всего не будет ставить разрешение входа на всю подсеть, он скорее поставит разрешение на избранные сетевые машины...
Круто! Не зная что за файрволом, сканируем "его подсеть"!
BECHED писал(а):
Существует еще один очень интересный способ : Тунелирование ICMP/UDP пакетами... Оно заключаются в том, что у некоторых фаерволлов нет правила на блокирование ICMP ECHO, ICMP ECHO REPLY,
UDP. Все это способствует хорошей атаки... Сказу скажу, что этот способ проходит, если вы находитесь в подсети фаерволла. Для его осуществления вам понадобятся две программы - loki, lokid (демон). Для того чтобы осуществить атаку, вам следует установить демон за фаерволлом и последующей эксплуатацией с помощью утилиты loki...
Даже у сраной, дырявой как дуршлаг ХР, со второго сервиспака есть поигрушки с ICMP :)
И какое отношение имеет ICMP-тунель к взлому?
BECHED писал(а):
[ 4. Вывод ]
Вывод неутешительный: статья вопиюще безграмотна и ниочём. :)
Вход
FAQ
Поиск
