– закрывать все порты, кроме тех, что принадлежат публичным сетевым службам (HTTP, FTP, SMTP и т.д.);
– пакеты, приходящие на заданный порт, отправлять тем и только тем узлам, на которых установлены соответствующие службы (например, если WWW-сервер расположен на узле А, а FTP-сервер на узле B, то пакет, направленный на 80 порт узла B, должен блокироваться брандмауэром);
– блокировать входящие соединения из внешней сети, направленные в корпоративную сеть (правда, в этом случае пользователи сети не смогут работать с внешними FTP-серверами в активном режиме);
– блокировать исходящие соединения из DMZ-зоны, направленные во внутреннюю сеть (исключая FTP– и DNS-сервера, которым исходящие соединения необходимы);
– блокировать входящие соединения из DMZ-зоны, направленные во внутреннюю сеть (если этого не сделать, то атакующий, захвативший управление одним из публичных серверов, беспрепятственно проникнет и в корпоративную сеть).
– блокировать входящие соединения в DMZ-зону из внешней сети по служебным протоколам, часто использующимся для атаки (например, ICMP; правда, полное блокирование ICMP создает большие проблемы, в частности, перестает работать ping и становится невозможным автоматическое определение наиболее предпочтительного MTU);
– блокировать входящие/исходящие соединения с портами и/или IP-адресами внешней сети, заданными администратором.
Фактически роль брандмауэра сводится к ограждению корпоративной сети от всяких любопытствующих, блуждающих по просторам инета. Тем не менее, прочность этого ограждения только кажущаяся. Если клиент корпоративной сети использует уязвимую версию браузера или клиента электронной почты (а большая часть программного обеспечения уязвима!), атакующему достаточно заманить его на троянизированную WEB-страничку или послать ему письмо с вирусом внутри, и через короткое время локальная сеть окажется поражена. Даже если исходящие соединения из корпоративной сети запрещены, shell-код сможет воспользоваться уже установленным TCP-соединением, через которое он был заброшен на атакованный узел, передавая хакеру управление удаленной системой.
Брандмауэр может и сам являться объектом атаки, ведь он, как и всякая сложная программа, не обходится без дыр и уязвимостей. Дыры в брандмауэрах обнаруживаются практически каждый год и далеко не сразу затыкаются (особенно если брандмауэр реализован на «железном» уровне). Забавно, но плохой брандмауэр не только не увеличивает, но даже ухудшает защищенность системы (в первую очередь это относится к персональным брандмауэрам, популярность которых в последнее время необычайно высока).
Обнаружение и идентификация брандмауэра
Залогом успешной атаки является своевременное обнаружение и идентификация брандмауэра (или, в общем случае, IDS, но в контексте настоящей статьи мы будем исходить из того, что она совмещена с брандмауэром).
Большинство брандмауэров отбрасывают пакеты с истечением TTL (Time To Live – время жизни), блокируя тем самым трассировку маршрута, чем разоблачают себя. Аналогичным образом поступают и некоторые маршрутизаторы, однако, как уже говорилось выше, между маршрутизатором и пакетным фильтром нет принципиальной разницы.
Отслеживание маршрута обычно осуществляется утилитой traceroute, поддерживающей трассировку через протоколы ICMP и UDP, причем ICMP блокируется гораздо чаще. Выбрав узел, заведомо защищенный брандмауэром (например, www.intel.ru), попробуем отследить к нему маршрут командой traceroute –I wwww.intel.ru.
$traceroute –I wwww.intel.ru
Трассировка маршрута к bouncer.glb.intel.com [198.175.98.50]
с максимальным числом прыжков 30:
1 1352 ms 150 ms 150 ms 62.183.0.180
2 140 ms 150 ms 140 ms 62.183.0.220
3 140 ms 140 ms 130 ms 217.106.16.52
4 200 ms 190 ms 191 ms aksai-bbn0-po2-2.rt-comm.ru [217.106.7.25]
5 190 ms 211 ms 210 ms msk-bbn0-po1-3.rt-comm.ru [217.106.7.93]
6 200 ms 190 ms 210 ms spb-bbn0-po8-1.rt-comm.ru [217.106.6.230]
7 190 ms 180 ms 201 ms stockholm-bgw0-po0-3-0-0.rt-comm.ru [217.106.7.30]
8 180 ms 191 ms 190 ms POS4-0.GW7.STK3.ALTER.NET [146.188.68.149]
9 190 ms 191 ms 190 ms 146.188.5.33
10 190 ms 190 ms 200 ms 146.188.11.230
11 311 ms 310 ms 311 ms 146.188.5.197
12 291 ms 310 ms 301 ms so-0-0-0.IL1.DCA6.ALTER.NET [146.188.13.33]
13 381 ms 370 ms 371 ms 152.63.1.137
14 371 ms 450 ms 451 ms 152.63.107.150
15 381 ms 451 ms 450 ms 152.63.107.105
16 370 ms 461 ms 451 ms 152.63.106.33
17 361 ms 380 ms 371 ms 157.130.180.186
18 370 ms 381 ms 441 ms 192.198.138.68
19 * * * Превышен интервал ожидания для запроса.
20 * * * Превышен интервал ожидания для запроса.
Смотри: трассировка доходит до узла 192.198.138.68, а затем умирает, что указывает либо на брандмауэр, либо на недемократичный маршрутизатор. Чуть позже мы покажем, как можно проникнуть сквозь него, а пока выберем для трассировки другой узел, например, www.zenon.ru
Читать дальше