Что попадает в deny ip any any?
Большинство реализаций списков доступа подразумевает под собой поведение «всё что не разрешено, то запрещено». Разумный подход, с учётом того, что при проектировании мы заранее ожидаем тот или иной тип трафика в определённом направлении: если у нас подключен абонент или пиринговый партнёр, значит данных с других IP на этом интерфейсе быть не должно, а если у нас подключен Интернет, откуда там взяться частным адресам? А может зря всё это? Может и нет никакого паразитного трафика и безусловный запрет в ACL это только перевод ресурсов. Ведь клиентам оператор сам выдаёт адреса, а пиринговые партнёры и апстрим провайдеры братья связисты, которые должны понимать всю сложность и щекотливость ситуации. К сожалению, это совсем не так.Участники круглого стола посвящённому DDoS, прошедшего на YaC2013 очень сетовали на то, что при всех существующих рекомендациях никто не старается заниматься безопасностью своих сетей. То есть начинать надо в первую очередь с себя (с операторов связи), как минимум бороться с IP-спуфингом.От чего же защищает deny ip any any можно посмотреть далее, просто примеры из журналов мониторинга.Наша сеть это провайдер с абонентами, пиринг партнёрами и аплинками: 
Сначала первый интерфейс (один из) int1 в сторону абонентов, и простой список доступа на вход:
10 permit icmp any any (1483430 matches) 20 permit tcp any any established (26903 matches) 30 permit ip 10.100.x.0 0.0.0.255 any (923840 matches) 40 deny ip any any (201 matches)
Разрешили ICMP, уже установленные соединения и трафик только из подключенной части абонентской сети. Смотрим что попалось.Deny any со стороны абонентов 1. Множество публичных адресов источника, и один публичный адрес назначения. Никакие из адресов нам не принадлежат: denied tcp 81.200.20.77(64112) → 25.189.67.187(44335) denied tcp 46.147.230.241(60676) → 25.189.67.187(44335) denied tcp 95.154.77.187(49623) → 25.189.67.187(44335) denied udp 95.54.131.126(10000) → 25.189.67.187(44335) denied udp 95.221.80.35(20743) → 25.189.67.187(44335) denied tcp 212.92.250.137(52335) → 25.189.67.187(44335) denied tcp 93.124.112.244(62817) → 25.189.67.187(44335) В данном случае адрес назначения входит в блок принадлежащий министерству обороны Великобритании. Казалось бы, вот тут проявление сетевой солидарности — с миру по нитке и не надо никаких анти-DDoS средств. Но на самом деле это всего лишь вышедший из под контроля Hamachi со своими нелегальными глобальными IP адресами, когда трафик идёт не через туннель, а через общее маршрутизируемое пространство, то есть Великобритании, таки, достаётся.2. Источник — серверы имён, в основном реальные: Локальные нашей сети denied udp 10.10.0.2(domain) → 169.254.32.112(31049) denied udp 10.10.1.2(domain) → 169.254.37.66(52758) denied udp 10.10.1.2(domain) → 10.75.144.128(36985) Гугл denied udp 8.8.8.8(domain) → 172.22.81.195(7116) denied udp 8.8.8.8(domain) → 169.254.32.112(17726) denied udp 8.8.8.8(domain) → 169.254.32.112(21974) Мегафон denied udp 83.149.22.14(domain) → 172.22.81.195(32844) Билайн denied udp 217.118.66.243(domain) → 10.193.166.57(31159) denied udp 217.118.66.243(domain) → 10.205.222.222(42160) denied udp 217.118.66.243(domain) → 10.204.57.217(53646) denied udp 217.118.66.243(domain) → 10.198.108.220(2125) МТС denied udp 217.74.244.2(domain) → 10.108.170.22(31425) denied udp 217.74.244.2(domain) → 10.77.119.212(43896) denied udp 217.74.244.3(domain) → 10.86.224.44(25234) Частный адрес denied udp 192.168.1.1(domain) → 169.254.48.228(59050) В адресах назначения нет адресов принадлежащих нашей сети. Но так как серверы реальные, то можно предположить, что в каком-то случае может раскрываться внутренняя структура адресации, подключенного в данный момент или ранее подключенного у абонента провайдера.3. Множество публичных адресов источника (иногда адреса из абонентской сети) и один адрес назначения в абонентской сети: denied udp 5.76.188.102(6881) → 10.100.178.87(49001) denied udp 178.185.77.225(14548) → 10.100.178.87(16414) denied udp 83.149.44.138(3251) → 10.100.178.87(64375) denied tcp 10.100.38.30(51167) → 10.100.178.87(64375)
denied udp 178.216.69.13(1375) → 10.100.172.135(21787) Интересно, что источником данного трафика является узел, именно с тем адресом, который указан в качестве назначения.4. Близкое по форме с предыдущим вариантом, но в качестве адреса назначения выступает частный адрес не принадлежащий ни одному из известному узлу в сети: denied udp 82.238.44.240(42300) → 172.16.8.83(52987) denied udp 82.255.186.101(20344) → 172.16.8.83(52987) denied tcp 79.31.185.28(53369) → 172.16.8.83(52987)
denied tcp 10.100.34.79(50984) → 192.168.137.1(13472) denied tcp 10.100.236.119(54821) → 192.168.137.1(13472) denied tcp 188.244.185.76(2503) → 192.168.137.1(13472)
denied udp 86.176.51.60(36740) → 169.254.12.28(29970) denied udp 171.7.208.183(27161) → 169.254.12.28(29970) denied udp 24.53.252.132(24874) → 169.254.12.28(29970)
denied udp 89.110.5.117(36505) → 172.20.10.4(14957) denied tcp 80.255.155.125(60134) → 172.20.10.4(14957) denied tcp 128.70.16.74(51952) → 172.20.10.4(14957)
denied tcp 178.140.142.84(64797) → 10.0.16.19(61789) denied tcp 88.215.186.103(59343) → 10.0.16.19(61789) denied tcp 80.77.41.98(54474) → 10.0.16.19(61789) Здесь также как и в предыдущем случае, узел источник трафика имеет на интерфейсе одним из адресов указанный в качестве адреса назначения. Вот эти два случая остались для меня загадкой — кто, как и зачем?5. Один частный адрес источника и множество публичных адресов назначения (иногда адреса из абонентской сети): denied udp 192.168.0.17(45927) → 93.185.249.103(43213) denied tcp 192.168.0.17(52596) → 82.208.126.93(58025) denied udp 192.168.0.17(45927) → 46.72.40.240(19047)
denied udp 192.168.0.5(22475) → 188.18.233.101(42763) denied tcp 192.168.0.5(57165) → 109.61.147.132(46895)
denied udp 192.168.1.3(28199) → 136.169.166.182(42584) denied udp 192.168.1.3(28199) → 94.41.133.198(46843)
denied udp 192.168.0.101(43137) → 10.100.44.151(49393) denied udp 192.168.0.101(43137) → 10.100.26.39(20080) denied udp 192.168.0.101(43137) → 10.100.72.63(35692) Наверное самое объяснимое. В следствии того что адрес постоянен, то он либо настроен вторым на основном интерфейсе, либо на другом устройстве в сети абонента, или используется одним из приложений.Вышеперечисленные варианты встречаются во многих местах являются самыми массовыми, остальное лишь единичные случаи.
6. Источник — публичный адрес сети провайдера: denied udp 203.0.113.18(26585) → 213.67.20.238(6112) 7. Назначение — публичный адрес сети провайдера: denied udp 62.148.7.195(17278) → 203.0.113.65(40178) denied udp 62.148.7.195(19176) → 203.0.113.65(40180) denied udp 62.148.7.195(16186) → 203.0.113.65(40182) denied udp 62.148.7.195(19970) → 203.0.113.65(40184) Данные случаи стоит пояснить, поскольку все абоненты находятся за NAT и имеют частную адресацию, появление в сети в качестве источника публичного адреса провайдера, ровно как и адреса назначения это совсем не обычно.8. «Странные» даже в этом контексте, адреса и протоколы: denied 154 73.246.67.151() → 128.106.162.245() denied all 175.223.240.56() → 64.0.0.0() denied tcp 64.8.0.1(61445) → 0.0.0.1(128) Большинство из того что удалось исследовать и как-то объяснить не относится к каким-то преднамеренным или злонамеренным действиям, часто это ошибки конфигурации, в основном автоматической, при подключении второго провайдера (обычно 3G модемов), использовании различных туннельных программ (как Hamachi, в первом случае) или P2P клиентов.Deny any со стороны пиринг партнёра Теперь посмотрим на трафик со стороны пиринг партнёра int2: BGP стык и только известные публичные адреса. Список доступа чуть сложнее, дополнительно к предыдущему сделали отдельные правила для частных сетей: 10 permit icmp any any (1360250 matches) 20 permit tcp any any established (199798954 matches) 30 permit bgp host 192.0.2.1 host 192.0.2.2 (11887 matches)
40 permit ip 192.0.2.0 0.0.0.255 203.0.113.0 0.0.0.255 (775443105 matches)
50 deny ip 10.0.0.0 0.255.255.255 any (1280 matches) 60 deny ip 172.16.0.0 0.15.255.255 any (2 matches) 70 deny ip 192.168.0.0 0.0.255.255 any (1335 matches)
80 deny ip 169.254.0.0 0.0.255.255 any 90 deny ip 127.0.0.0 0.255.255.255 any
100 deny ip host 0.0.0.0 any 110 deny ip host 255.255.255.255 any
120 deny ip any any (540 matches) Стоит обратить внимание на соотношение количества совпадений deny и permit правил по отношению к предыдущему ACL. Непонятных вещей происходит меньше, примерно, 1 deny на 200000 permit, в предыдущем примере это отношение 1 к 5000, что говорит нам о наличии контролируемой сетевой структуре, которая присутствует у нашего партнёра и которая не присутствует у наших абонентов. Но и в этом случае всё равно что-то просачивается.1. Правила 50,60,70 — доступ с частных адресов не принадлежащих ни нам, ни пиринг партнёру, к нашим публичным адресам: denied udp 192.168.0.101(6881) → 203.0.113.251(6881) denied udp 192.168.0.249(47597) → 203.0.113.147(23392) denied udp 10.112.112.112(63973) → 203.0.113.249(42873) denied tcp 192.168.0.57(57055) → 203.0.113.38(37654) Событий не много, но можно предположить что данный случай чем-то перекликается с 5 вариантом в предыдущем разделе.2. А вот deny ip any any показало, внезапно, ожидаемые события — попытки доступа к интерфейсному адресу 192.0.2.2 с публичных адресов не принадлежащих пиринг партнёру: denied udp 5.255.68.168(7678) → 192.0.2.2(123) denied udp 84.105.139.67(42440) → 192.0.2.2(161) Адрес является глобально маршрутизируемым, а в желающих испытать на прочность безопасность сети недостатка не было никогда. Справедливости ради, надо отметить что подобные случаи происходят и во внутренней сети, но они отсекаются другим механизмом защиты, поэтому этого не было заметно в примерах выше.Deny any со стороны Интернета Осталось посмотреть что нам ждать из Интернета int3. Список доступа такой же как и раньше, но доступ теперь возможен со всех адресов, а не только с заранее известных. 10 permit icmp any any (142814260 matches) 20 permit tcp any any established (29633491483 matches) 30 permit bgp host 198.51.100.1 host 198.51.100.2 (1727903 matches)
40 permit ip any 203.0.113.0 0.0.0.255 (23122741548 matches)
50 deny ip 10.0.0.0 0.255.255.255 any (447026 matches) 60 deny ip 172.16.0.0 0.15.255.255 any (121911 matches) 70 deny ip 192.168.0.0 0.0.255.255 any (191732 matches)
80 deny ip 169.254.0.0 0.0.255.255 any (1733 matches) 90 deny ip 127.0.0.0 0.255.255.255 any (3415 matches)
100 deny ip host 0.0.0.0 any (46 matches) 110 deny ip host 255.255.255.255 any (9 matches)
120 deny ip any any (1278 matches) Сразу обращает на себя внимание большее разнообразие исходных адресов в том числе и 0.0.0.0 и 255.255.255.255. В остальном же имеем почти тоже самое что и с пиринг партнёром.1. Частный адрес из публично маршрутизируемого пространства на публичный адрес провайдера: denied udp 192.168.0.106(61104) → 203.0.113.84(18636) denied tcp 10.0.3.49(54996) → 203.0.113.243(21603) denied udp 10.240.77.25(38170) → 203.0.113.106(25175) denied tcp 172.20.56.135(49995) → 203.0.113.210(60623) denied tcp 10.60.33.69(49388) → 203.0.113.206(54312) 2. Тоже что и первый случай, но в качестве источника публичный адрес из нашей сети: denied udp 203.0.113.18(56425) → 203.0.113.21(6502) 3. Доступ к стыковочному адресу маршрутизатора, тоже что и в случае с пиринг партнёром: denied udp 116.10.191.170(6000) → 198.51.100.2(22) denied udp 5.152.192.210(5135) → 198.51.100.2(5060) В этот раз порты SSH и SIP.Вот пожалуй и всё. Коренное отличие работы с внешними подключениями это отсутствие попыток доступа не к нашим адресам. Все пакеты приходили куда надо, правда не всегда с тех адресов которые были бы уместны в данной ситуации. Также, в относительном измерении, из внешних сетей откровенной ерунды прилетает сильно меньше, чем от собственных абонентов. То есть, наличие в сети администратора решает почти все проблемы.
Конечно не являясь специалистом сетевой безопасности, я не всегда понимаю что означает та или иная строчка попавшая под запрет, но вроде ничего откровенно злонамеренного не попалось, как я уже говорил выше в основном ошибки конфигурации. В любом случае — будьте бдительны, защищайтесь сами от внешних, а в первую очередь от внутренних угроз, чтобы всем нам было спокойнее.
