Что попадает в deny ip any any?

    Большинство реализаций списков доступа подразумевает под собой поведение «всё что не разрешено, то запрещено». Разумный подход, с учётом того, что при проектировании мы заранее ожидаем тот или иной тип трафика в определённом направлении: если у нас подключен абонент или пиринговый партнёр, значит данных с других IP на этом интерфейсе быть не должно, а если у нас подключен Интернет, откуда там взяться частным адресам? А может зря всё это? Может и нет никакого паразитного трафика и безусловный запрет в ACL это только перевод ресурсов. Ведь клиентам оператор сам выдаёт адреса, а пиринговые партнёры и апстрим провайдеры братья связисты, которые должны понимать всю сложность и щекотливость ситуации. К сожалению, это совсем не так.
    Участники круглого стола посвящённому DDoS, прошедшего на YaC2013 очень сетовали на то, что при всех существующих рекомендациях никто не старается заниматься безопасностью своих сетей. То есть начинать надо в первую очередь с себя (с операторов связи), как минимум бороться с IP-спуфингом.
    От чего же защищает deny ip any any можно посмотреть далее, просто примеры из журналов мониторинга.

    Наша сеть это провайдер с абонентами, пиринг партнёрами и аплинками:image

    Сначала первый интерфейс (один из) 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.

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

    Конечно не являясь специалистом сетевой безопасности, я не всегда понимаю что означает та или иная строчка попавшая под запрет, но вроде ничего откровенно злонамеренного не попалось, как я уже говорил выше в основном ошибки конфигурации. В любом случае — будьте бдительны, защищайтесь сами от внешних, а в первую очередь от внутренних угроз, чтобы всем нам было спокойнее.
    Support the author
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 19

      0
      Может сможете ответить на давно мучающий меня вопрос. Как то заметил, что на мой веб сервер (белый, статический IP) поступают запросы, для которых у меня нету виртуальных хостов, посмотрел повнимательнее, и увидел странное. Запросов много, но они есть, приходят от различных пользователей, с различных ОС и браузеров, на различные ресурсы, типа Google, Yandex, VK, но на мой сетевой интерфейс, причём в запросах указаны куки пользователей. Записал дамп, и увидел совсем невероятное, для подобных запросов в dst значился реальный адрес назначения, там не было моего адреса, но пакет почему то прилетал ко мне. Наблюдал подобное поведение в течение года, потом тот IP адрес у меня забрали. Как такое вообще возможно?
        0
        Тоже вижу много таких запросов в логах. Мне кажется, это автоматический поиск открытых прокси-серверов, по крайней мере в части случаев.
          0
          В тех случаях, когда src — мой адрес — да, это могут быть сканеры открытых прокси, но в большинстве случаев это не так, и это для меня кажется странным.
            0
            Тогда невероятное предположение, если ни src ни dst совсем не близко, тогда возможно кто-то считал ваш адрес маршрутизатором (какая-то виртуальная сеть, как с Hamachi. TOR?), в локальной сети соседа можно по маку посмотреть, он то точно не должен был отличаться разнообразием, чтобы понять хотя бы откуда всё это.
            Обычно в случае с провайдерами видны кучами netbios и arp запросы от всех соседей по коммутатору.
        +1
        Так сложно сказать. Простейшее, что можно предположить — первый кадр прилетающий на коммутатор, с мак адресом не присутствующим в таблице коммутации отправляется на все доступные интерфейсы (это стандартное поведение), тоже происходит при исчерпании таблицы коммутации (здесь надо думать о расширении). Тоже в общем касается и маршрутизаторов, основная задача передать данные, если при этом нам не хватает ресурсов на анализ — тогда передаём данные любой ценой.
        В качестве расследования, как мне кажется надо искать общую разделяемую среду, если это облачная инфраструктура значит сервер делит с кем-то физическую сетевую карту и драйвер. Если физическая инфраструктура то общие коммутаторы, маршрутизаторы. Смотрим находимся ли мы с источником или получателем в одной или близкой сети, если запросы реальные то адреса должны быть реальные.
          0
          Сервер стоял дома, подключен к обычному городскому интернет провайдеру. Если бы src были из сети провайдера, я бы понял, но src из разных стран и от разных провайдеров.
            0
            Кривость в инфраструктуре провйдера.
          +1
          Скажите, а зачем прописывать кучу deny шз с разными адресами, если в конце всё равно идёт deny ip any any?
          Разве это правило не покроет все предыдущие deny? Или это чтобы конкретно видеть, что запрещается по данному правилу?
            +1
            В данном случае, чтобы конкретно видеть. А так всё попадает в deny any any.
            +2
            узел источник трафика имеет на интерфейсе одним из адресов указанный в качестве адреса назначения


            Объясняю. Железка хотела поговорить сама с собой или принять чей-то траффик. Только в этот момент один из ее IP-адресов был (временно) снят, и она отправилась его искать согласно таблице маршрутизации.
              +1
              «Вот эти два случая остались для меня загадкой — кто, как и зачем?»

              Элементарно. У кого-то за роутером своя сетка с серой адресацией. Пока в ней все ок, к вам ничего не утекает. Потом пропадает какой-то внутренний линк между какими-то площадками, специфические правильные внутренние маршруты исчезают и все (на адреса назначения отвалившей подсети) начинает улетать по дефолт роуту к вам (в том числе с белых ип срц, если люди используют NAT). У людей отсутствует защитный маршрут в Null с завышенной по сравнению с AD динамического протокола дистанцией. А еще лучше делать такие маршруты не в Null, а куда-нибудь в сторонку, и там банить и логгировать. Я так массу интересных вещей ловлю.

              А еще есть добивающий меня приколы. Многие провайдеры не фильтруют у себя нифига, в итоге с их линков на выданные ими белые ип прилетает трафик с серых сетей (причем не из провайдерской сети, а именно с инета), на выход они это тоже часто не фильтруют. Один из провайдеров у нас например не фильтрует даже белые ип срц и в итоге можно через два линка от разных провов мутить асимметричный трафик. Уходит через одного, с неродным для него ип, назад прилетает через другого, для которого этот ип корректен. СОРМ у каждого провайдера видит только половину трафика :)
                +1
                Ну и клиенты тоже хороши. Получая трафик с серых ип с инета, их роутеры часто честно шлют ицмп эхо ответы или там анричиблы какие внутрь корпоративных ЛВС, что дает возможность элементарного флуда с инета в приватные сети (главное знать внутренню адресацию). И это у многих даже при включенном NAT-е и жестком фильтре на входе.

                А еще недавно в корп. MPLS VPN проанонсировал гугловский 8.8.8.8 и оказалось, что многие регионы нашей большой распределенной организации не фильтруют в бгп маршруты и ко мне потек днс трафик :)
                  0
                  Вполне может быть. Но у нас клиент в основном, это частное лицо — роутер, пару устройств за ним. Так что здесь надо что-то автоматическое и легкодоступное искать, потому что такого добра реально много.

                  Многие не фильтруют это точно. Как провайдер могу сказать, что когда у тебя в сети автоматическая маршрутизация, то практически с любого линка можно добраться до интернета, причём с любого адреса. Причины — uRPF накладная по производительности вещь и к тому же не каждая железка такое умеет. Уникальные ACL опять же под каждый линк, это организационно сложно и опять же дорого в плане расходования памяти. Конечно ради собственного спокойствия приходится жертвовать, но унификация наше всё.

                  Так что если провайдер что-то упустил, то лучше его предупредить, пока кто-нибудь не воспользовался и не сделал бяку всем, и провайдеру, и его клиентам и себе в том числе. А уж предупредить, как я выразился в статье «собрата провайдера», если что-то у тебя пошло не так или что-то нашёл странное, это вообще без вопросов должно быть.
                    0
                    Предупредить мироеда? Мы раз билайну пытались что-то доказать про упавшую емкость канала, последняя миля которого собрана из e1 потоков. Неделя нервов и только личный контакт с четким челом из Мск офиса этой контоны через forum.nag.ru спас ситуацию на вторую неделю мытарств. Похожие истории с ростелекомом. Ну а указывать им на какие-то ошибки, даже не могу представить себе такую картину.
                    На счет уникальных ACL — может они и не нужны массово. Но хотя бы на int3 из вашей схемки лист повесить можно с запретом на инпут с серых диапазонов и запретом на аут с белыми ип срц, вам не принадлежащими. Вроде все весьма лаконично должно получиться, не портянка.
                      0
                      Это печально и грустно, я представлю себе ситуацию отлично, просто очень хочется чтобы все друг к другу с уважением относились, а forum.nag.ru нужен был бы, чтобы в обеденный перерыв «за жизнь поговорить».

                      Про ACL, есть одна беда масштабируемости — пусть у нас 256 интерфейсов на маршрутизаторе с сетями по /24, общая агрегированная сеть значит /16. И если мы блокируем сеть целиком по /16 со стороны абонентов, тогда абонент может заспуфить 65535 адресов, глобально в Интернете это не будет заметно, но провайдер в таком объёме получить ощутимые неприятности внутри своей сети. Т.е. унифицированный ACL для каждого абонентского интерфейса может привести к «китайской» проблеме, вроде всё своё родное, но его так много что не справиться.
                      Если на каждый интерфейс вешать одинаковые ACL различающиеся только сетью абонентов /24, то у нас 256 ACL, не такая большая беда в общем, но визуально уже трудноуловимо, да и памяти у некоторых устройств уже может не хватать.
                      Если продолжить масштабировать дальше и представить себе 100 таких устройств… (Цифры беру вовсе не с потолка).

                      Так что как и в любом деле — разумный компромисс — цена, надёжность, безопасность, масштабируемость, управляемость, профессионализм. У всех по разному получается.
                        0
                        Я в комментарии выше имел в виду немного другое. Не надо со стороны абонентов. Можно на OUT в сторону магистрала. По вашему рисунку это int3. И там это будет не более десятка строк, типа 10.0.0.0/8, 192.168.0.0/16 и т.д. Зачем вам их выпускать в мир?
                        А если и внутри своих сетей пресекать спуфинг, то можно не плодить эти правила в ядре, нагружая его, можно (если позволяет железо), делать это на доступе, зачем мусор тянуть через всю сеть, когда трафик можно почистить максимально близко к его источнику. Благо доступ давно сильно поумнел, а провайдеры приноровились скриптами творить чудеса автоматизации по настройке этого самого доступа :)
                          0
                          Я понял насчёт int3 :) я чуть-чуть аналогию дальше увёл просто. Всё же для провайдера частных абонентов, важнее внутренне спокойствие этих самых абонентов, соответственно надёжность внутренней сети.

                          А выход в мир, как правило самое простое — потому что стоит хорошее железо — нужно BGP, и память, и трафика много молотить, не надо распыляться на множество интерфейсов — несколько входов, несколько выходов, картинка полностью охватывается и редко меняются условия. С внешней стороны, опять же, качественно управляемые сети, собственно в примерах в статье видно, что при больших объёмах трафика мусора сильно меньше. Конечно, надо обезопасить себя от Интернета и Интернет от себя, но так как это край сети то здесь сходятся большие агрегированные сети, поэтому правил получается меньше при том, что возможности написать много правил существенно больше.

                          А вот чем глубже в сеть тем интереснее, объёмы трафика на конкретном устройстве меньше, а самих устройств сильно-сильно больше — соответственно устройства дешевеют, по производительности и по возможностям, даже при том что они сильно поумнели, иначе была бы вообще катастрофа. При этом внутренних угроз больше (конечные подключения слабоуправляемые), а средств защиты от них меньше.

                          З.Ы. При скрипты, кстати, это вообще отдельная песня :)
                            0
                            Было время — были вот такие, например, вещи — nag.ru/articles/article/16988/upravlyaem-neupravlyaemyim.html
                            И уровень мусора был совсем другой. И сети умудрялись быть достаточно большими и даже большую часть времени функционировать, а не лежать.

                            Сейчас все сильно проще все же.
                              0
                              Стало проще, несомненно, но время ушло пока не очень далеко.

                              Пару недель назад был на конференции — один из технических докладов:
                              Кулибинские решения. Как сделать из неуправляемого коммутатора управляемый и другое.

                Only users with full accounts can post comments. Log in, please.