Jump to content
Калькуляторы

MaLblsH

Активный участник
  • Content Count

    113
  • Joined

  • Last visited

Everything posted by MaLblsH


  1. XYZ упал

    А сейчас ещё и W-IX флапнул всеми RS...
  2. XYZ упал

    Да, было дело. Нам ещё Смотёшка прислала письмо о каких-то проблемах на 9-ке.
  3. Судя по "*" в поле IP, надо лукапить эти домены и поддомены (какие ?!) и проверять, что в заблокированных в итоге IP нет IP из этих доменов..
  4. По такой же причине переходим на сабж. С прошивкой 6.13.B025 ушли баги, которые мешали нам жить (проблемы с инкрементной загрузкой через TFTP) и сброс списка VLAN в DHCP_RELAY после ребута. Месяц стоят, полёт нормальный.
  5. А как вы приостановление сервиса реализовали? Смотрешка предлагает каждый раз при блокировке отписывать юзера от пакетов и потом подписывать по-новой. Тоже интересует данный момент. Ибо в API не нашёл функционала по приостановлению услуг. Приостанавливать списание в биллинге Агента нет смысла - пока услуги висят на Абоненте, Агенту будут идти начисление. Остаётся только реализовывать кнопку "Временно приостановить услугу" в личном кабинете, по которой производить реальную отписку от пакетов данного клиента, а себе куда-то в базу записывать эти пакеты. А по нажатию на кнопку "Возобновить" подключать ранее отключённые пакеты, делая т.о. видимость приостановки услуг для клиента.
  6. AF 5U

    Система сама выставляет QPSK и остаётся такой же при частотном разносе tx и rx, но при этом мы не снижали Output power и раносили rx и tx в пределах 100. Сейчас одна из точек переедет на дом с кровлей, на которой можно произвести монтаж более точно: взято отсюда Как только наведёмся, будем пробовать разносить rx и tx на большее значение и уменьшать output power.
  7. AF 5U

    Пробовали ставить 8x и отключали автонастройку - скорость упала до 1-2 мбит/с. GPS синхронизацию попробуем. Разносили частоты, предварительно просканиронировав airView. Точно сейчас не скажу какие именно ставили, но разница у них была примерно 100 GHz. Скорость упала примерно в 2 раза. Скан сделаем завтра, точки сейчас отключены. Кстати реальная пропускная способность равна капасити, что уже радует. Но вот злосчастная "недосотка" настораживает. Как будто реально где-то упирается в полку и не может больше.
  8. Скорее всего это был торрент, который мы ошибочно приняли за атаку.
  9. В последнее время начали периодически получать мощные всплески входящего трафика с UDP порта 123. Судя по всему это DDoS атака эксплуатирующая известную уязвимость в NTP серверах. Атакуются некоторые наши абоненты с внешними IP адресами (т.е. не за NAT'ом). fastnetmon выявляет эти атаки: Ну и немного tcpdump: Сейчас мы блокируем этот трафик на своём оборудовании, но в идеале мы вообще не хотим его получать и обрабатывать. Как бы "заставить" аплинков делать это за нас? Коллеги, прошу совета: может у кого-нибудь уже имеется опыт? P.S.> Всего 2 из нескольких наших аплинков обладают blackhole. P.P.S.> Уже думаем о том, чтобы попросить у наших аплинков доступ к их оборудованию, чтобы автоматически создавать блокирующие правила там. :)
  10. Вам спасибо за труды! Логи нашёл сразу же, очень удобно! :) А нас продолжают "потрахивать", но теперь уже приходится блокировать полностью абонентов, т.к. SRC порт с которого летят запросы стал меняться: Пример 1: 2015-03-21 16:09:27.899272 212.76.17.56:41082 > x.x.x.x:63731 protocol: udp packets: 1 size: 1467 bytes sample ratio: 1 2015-03-21 16:09:27.899283 46.119.158.162:52514 > x.x.x.x:63731 protocol: udp packets: 1 size: 1480 bytes sample ratio: 1 2015-03-21 16:09:27.899319 93.81.126.90:27638 > x.x.x.x:63731 protocol: udp packets: 1 size: 1465 bytes sample ratio: 1 2015-03-21 16:09:27.899335 93.81.126.90:27638 > x.x.x.x:63731 protocol: udp packets: 1 size: 1465 bytes sample ratio: 1 2015-03-21 16:09:27.899338 5.18.174.244:53839 > x.x.x.x:63731 protocol: udp packets: 1 size: 1480 bytes sample ratio: 1 2015-03-21 16:09:27.899342 5.18.174.244:53839 > x.x.x.x:63731 protocol: udp packets: 1 size: 1480 bytes sample ratio: 1 2015-03-21 16:09:27.899466 46.119.158.162:52514 > x.x.x.x:63731 protocol: udp packets: 1 size: 1480 bytes sample ratio: 1 2015-03-21 16:09:27.899479 46.119.158.162:52514 > x.x.x.x:63731 protocol: udp packets: 1 size: 1480 bytes sample ratio: 1 2015-03-21 16:09:27.899483 109.252.169.127:31473 > x.x.x.x:63731 protocol: udp packets: 1 size: 1467 bytes sample ratio: 1 Пример 2: 2015-03-22 22:31:20.321858 222.43.140.83:1900 > x.x.x.x:80 protocol: udp packets: 1 size: 368 bytes sample ratio: 1 2015-03-22 22:31:20.321860 1.181.148.126:1900 > x.x.x.x:80 protocol: udp packets: 1 size: 310 bytes sample ratio: 1 2015-03-22 22:31:20.321861 112.12.158.83:1900 > x.x.x.x:80 protocol: udp packets: 1 size: 332 bytes sample ratio: 1 2015-03-22 22:31:20.321864 1.181.148.126:1900 > x.x.x.x:80 protocol: udp packets: 1 size: 332 bytes sample ratio: 1 2015-03-22 22:31:20.321868 1.181.148.126:1900 > x.x.x.x:80 protocol: udp packets: 1 size: 364 bytes sample ratio: 1 2015-03-22 22:31:20.321871 213.185.230.87:1900 > x.x.x.x:80 protocol: udp packets: 1 size: 289 bytes sample ratio: 1 Тут в принципе можно с 1900 порта закрыть на 80 и прочие порты, который находятся под атакой. Пример 3: 2015-03-20 21:12:23.564026 217.117.190.51:0 > x.x.x.x:0 protocol: icmp packets: 1 size: 70 bytes sample ratio: 1 2015-03-20 21:12:23.564068 185.2.127.213:0 > x.x.x.x:0 protocol: icmp packets: 1 size: 110 bytes sample ratio: 1 2015-03-20 21:12:23.564085 36.78.26.0:123 > x.x.x.x:123 protocol: udp packets: 1 size: 482 bytes sample ratio: 1 2015-03-20 21:12:23.564089 36.78.26.0:123 > x.x.x.x:123 protocol: udp packets: 1 size: 482 bytes sample ratio: 1 2015-03-20 21:12:23.564092 36.78.26.0:123 > x.x.x.x:123 protocol: udp packets: 1 size: 482 bytes sample ratio: 1 2015-03-20 21:12:23.564212 71.171.62.128:0 > x.x.x.x:0 protocol: icmp packets: 1 size: 70 bytes sample ratio: 1 2015-03-20 21:12:23.564311 36.78.26.0:123 > x.x.x.x:123 protocol: udp packets: 1 size: 482 bytes sample ratio: 1 2015-03-20 21:12:23.564323 72.87.175.21:0 > x.x.x.x:0 protocol: icmp packets: 1 size: 70 bytes sample ratio: 1 А вот тут уже печаль-беда: трафик с порта 123 на 123 порт глобально закрывать не хотелось бы. Приходит пока решение автоматом банить не весь трафик к атакуемому IP, а в связке с DST портом. Хотя если в итоге атакуемый IP засовывать в blackhole к провайдеру, чтобы убрать трафик с аплинков, то и работать у абонента ничего не будет. Забыл уточнить: IP с нашей стороны постоянно разные. Я не склонен верить в теории заговоров, но есть шанс, что нас "заказали". Уж больно даты начала атак и ещё кое-какая дата сходятся. "Совпадение ? Не думаю" (с)
  11. Ясен бен писать новую прошивку для регистраторов для исправления не основного, скажем так, функционала они если будут, то очень не скоро :) Это мы ещё давно закрыли, как только появились первые алерты в radar.qrator о том, что наши IPs с уязвимостью NTP используются для DDoS атак. Как только я увидел, что атака идёт на абонента, то первым делом просто заблочил весь трафик к нему на свитче поближе к "миру". Да и потом, как выяснилось, сначала атаковали его STEAM Сервер CS (27017 порт, под спойлером tcpdump-а он фигуририрует). Сейчас закинул ещё пару портов из того же STEAM-а. Да можно в принципе открыть только трафик с udp/123 на udp/123, а остальной трафик с udp/123 закрыть к чёртовой матери, но тем самым обломаю клиентов с NTPv2. Хотя их можно попросить использовать внутрисетевой NTP сервер. Всё равно как-то некрасиво. Вот похожие правила попросить бы прописать на нашем порту со стороны аплинка.
  12. Можно конечно и письма разослать... Да вот только по нам хорошенько катком прошлись в последний раз: Это уже отсортированные уникальные записи. Итог: 4667 ip. Вот эти все товарищи накинулись на одного нашего абонента. Сгенерировали за несколько минут около 4 гигабит трафика (и то это был всплеск, который зафиксировал cacti, а значит могло быть гораздо больше). Если автоматизировать рассылку на abuse ящики контактным лицам, то нас самих быстрее забанят за спам :)
  13. Эту тему читал. Это всё мы блокируем на своей сети. Как нам "заставить" это делать провайдера своего, который не хочет/не может или ещё по каким-то причинам не реализует blackhole ? Мы же платим за входящий трафик, который провайдером считается на порту подключения, к которому мы доступ естественно не имеем. Один провайдер действительно пошёл на встречу и сообщил, что сейчас они допиливают blackhole, а пока превышения считать не будут. А вот остальных надо как-то попросить/уговорить.
  14. Пользователи рунета пожаловались на недоступность сервисов Google. У меня не резолвится только plus.google.com (no answer). Это на PDNS. Работающий параллельно BIND9 нормально резолвит %)
  15. Приветствую, коллеги! Недавно подключились к DE-CIX и буквально через пару дней получили от них уведомление: Далее перечислены все наши интерфейсы на маршрутизаторе. В качестве маршрутизатора на стыке в ними у нас стоит Linux Debian 6.0.3: Гугление по gratuitous arp вывело на это: arp_notify - BOOLEAN Define mode for notification of address and device changes. 0 - (default): do nothing 1 - Generate gratuitous arp requests when device is brought up or hardware address changes. arp_accept - BOOLEAN Define behavior for gratuitous ARP frames who's IP is not already present in the ARP table: 0 - don't create new entries in the ARP table 1 - create new entries in the ARP table Both replies and requests type gratuitous arp will trigger the ARP table to be updated, if this setting is on. If the ARP table already contains the IP address of the gratuitous arp frame, the arp table will be updated regardless if this setting is on or off. С accept понятно, отвечает за приём. А вот notify проверил: # cat /proc/sys/net/ipv4/conf/*/arp_notify 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 На всякий случай проверил и accept (тоже всё по нулям). Уже несколько часов пытаюсь tcpdump'ом поймать данные самообращенные широковещательные ARP-запросы. Только стандартный who-has. Пока не нашёл ни одного с одинаковыми souce и destination. Прочитал, что данный ARP генерируется при назначении IP-адреса интерфейсу, проверяя тем самым отсутствие конфликта IP. Пробовал удалять IP-адрес у интерфейса и добавлять - в tcpdump тишина (смотрел как с фильтром по ARP так и без). Прочитал, что некоторые процессы могу генерировать данный ARP-запрос. У нас стоит только QUAGGA и используется 2 демона: bgpd ну и zebra, но гугление в эту сторону не даёт никакого результата. Не могу понять, где я что упустил. Уже появляется дурные мысли по блокировке на L2 выше с помощью ACL этих ARP. Уж очень не хочется, чтобы товарищи немцы отправили нас в карантинный VLAN.
  16. Уверены? Точно уверены? А уверены, что вайршарк считает gratuitious arp тем же, что и апстрим? Ибо я - не уверен, и gratuitious arp может быть чем угодно в принципе, что не попадает под обязательные требования стандарта (т.е. arp who-has поиска соседа и arp reply на него). В частности, центос/рхел при старте ифейса опрашивает, а нет ли соседей с этим адресом, и если сосед есть - адрес не поднимает. Может, этот пакет определяется как gratuitious (ибо с т.з. апстрима кто-то третьий левый в сегменте вопрошает адрес второго конца пира). Согласен с Вами. Но я в самом начале переписки с немцами попросил их прислать дамп пакета, который они считают за gratuitious arp. В ответ на это от них тишина. Т.е. если бы они прислали дамп, я бы этот трафик вычислил и запретил.
  17. Эх... зеркалировал порт и смотрел wireshark-ом ARP-ы с фильтром "arp.gratuitious == 1". Делал ifdown/ifup, физически кабель перетыкал, рестартил сеть: не генерируется нифига этот ARP. Поставил утилитку arping и сгенерировал руками командой по примеру: arping -c 4 -A -I eth0 10.0.1.1 В wireshark увидел пакет и в его info написано, что это gratuitious arp (это я к тому, что фильтр правильно был настроен). Чтобы удовлетворить наших друзей немцев, решили просто перенести стык с ними на Juniper и уже на нём спокойно применить no-gratuitous-arp-request. Просто пока я не увижу глазами пакет, бессмысленно разбирать скрипты ifup/ifdown, играться с параметрами sysctl и пр. Всем спасибо за помощь!
  18. Спасибо, попробую. Я уже в эту сторону думал, но беглым взглядом ничего подозрительного не обнаружил. Попробую отмирорить порт и сделать ifdown/ifup интерфейсу и посмотреть какие ARP сыпятся с него.
  19. Нет ни одного ни другого (avahi и systemd). Список под спойлером:
  20. И всё таки - где в документации Вы увидели параметр versionNum = '2' ?? Некорректно написал - сорри. В заголовке выгрузки должно быть указано formatVersion="2.0" Вот тут http://forum.nag.ru/forum/index.php?showtopic=79836&view=findpost&p=999498 человек поделился новым форматом выгрузки. Там есть formatVersion="2.0". У меня почему-то нет, хотя запрос выглядит так, как я указывал в http://forum.nag.ru/forum/index.php?showtopic=79836&view=findpost&p=994624 try // попытаться произвести запрос на получение РЗС { // подключиться к веб-службе РЗС по протоколу SOAP $rzs = new SoapClient ($wsdl_url); // произвести запрос $response = $rzs -> sendRequest ( array ( 'requestFile' => $request, // запрос 'signatureFile' => $sign, // подпись 'dumpFormatVersion' => '2.0', // версия выгрузки ) ); // сохранить уникальный код запроса в отдельную переменную $request_code = $response -> code; } Вот таким запросом я получаю дамп formatVersion="2.0".
  21. И всё таки - где в документации Вы увидели параметр versionNum = '2' ??
  22. Пока тоже 2.0 не могу получить - приходит в старом формате. Запрашиваю через PHP SoapClient. При этом если использовать тестовый сервис (http://vigruzki.rkn.gov.ru/services/OperatorRequestTest/?wsdl), то возвращает в новом формате. И если смотреть метод с тестового, то он идентичен: <xsd:element name="sendRequest"> <xsd:annotation> <xsd:documentation>запрос на выгрузку реестра</xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:element name="requestFile" type="xsd:base64Binary"/> <xsd:element name="signatureFile" type="xsd:base64Binary"/> <xsd:element name="dumpFormatVersion" type="xsd:string" minOccurs="0"/> </xsd:sequence> </xsd:complexType> </xsd:element> Если выставлять dumpFormatVersion="1.0", то тестовая система возвращает по-старому. У меня подозрение, что они что-то не успели и пока отдают старую версию всегда.
  23. Спасибо за ответ. Значит придётся допиливать ещё одну защиту от дурака.
  24. Как мне показалось, странновато целую подсеть блокировать. А если есть и IP и ipSubnet нужно блокировать и то и то ?
  25. Приветствую, коллеги! Вопрос по логике блокировке, а особенно по введению подсетей (ipSubnet). Получил тестовый список: <?xml version="1.0" encoding="windows-1251"?> <reg:register updateTime="2014-02-02T12:00:00+04:00" updateTimeUrgently="2014-02-01T11:00:00" formatVersion="2.0" xmlns:reg="http://rsoc.ru" xmlns:tns="http://rsoc.ru"> <content id="1101" includeTime="2013-12-01T10:00:05" entryType="1"> <decision date="2013-12-01" number="9" org="Роспотребнадзор"/> <url><![CDATA[http://site1.com/index.php]]></url> <domain><![CDATA[site1.com]]></domain> <ip>1.1.1.1</ip> </content> <content id="1202" includeTime="2013-12-01T10:00:05" entryType="2"> <decision date="2013-12-01" number="9" org="Мосгорсуд"/> <url><![CDATA[http://site2.com/page1.php]]></url> <url><![CDATA[http://site2.com/page2.php]]></url> <url><![CDATA[http://site2.com/page3.php]]></url> <domain><![CDATA[site2.com]]></domain> <ip>1.1.1.1</ip> <ip>1.1.1.2</ip> </content> <content id="1303" includeTime="2014-02-01T15:17:51" urgencyType="1" entryType="3"> <decision date="2014-02-01" number="номер документа" org="Генпрокуратура"/> <url><![CDATA[http://site3.com/page1.html]]></url> <domain><![CDATA[site3.com]]></domain> <ip>1.2.3.4</ip> </content> <content id="1404" includeTime="2014-02-01T16:19:32" entryType="4"> <decision date="2014-02-01" number="номер документа" org="Роскомнадзор"/> <domain><![CDATA[site4.com]]></domain> <domain><![CDATA[site5.com]]></domain> <ip>1.2.3.4</ip> <ipSubnet>8.1.1.0/24</ipSubnet> </content> <content id="1505" includeTime="2014-02-01T17:08:23" entryType="4"> <decision date="2014-02-01" number="номер документа" org="Роскомнадзор"/> <ipSubnet>8.2.1.0/16</ipSubnet> </content> </reg:register> С первыми 4-мя записями всё понятно (хотя для меня было удивлением узнать, что одна запись может содержать несколько URL и IP, по которым нужно так же осуществлять блокировку). А вот 5 запись имеет только ipSubnet. Получается, что нужно всю подсеть блокировать ? Из информационного сообщения не совсем ясно: 1. Для каждой записи в выгрузке вводится обязательный атрибут entryType с типом реестровой записи в виде числового кода. Возможные значения: Код Значение 1 Реестр ЕАИС 2 Реестр НАП 3 Реестр 398-ФЗ 4 Реестр 97-ФЗ, организаторы распространения информации 2. Вводится дополнительный тег ipSubnet для указания ip-подсети. Он располагается внутри тега content и имеет следующий вид (после символа «/» указывается количество бит, приходящихся на адрес сети): <ipSubnet>192.168.10.0/24</ipSubnet> 3. На уровне xsd-схемы теги url, domain, ip, ipSubnet становятся необязательными. Тем не менее, для записей типа entryType=1,2,3 сохраняется прежняя логика – в каждой записи всегда есть одно доменное имя, один или несколько указателей страниц сайтов и один или несколько сетевых адресов. Для записей типа entryType=4 обязательно будет присутствовать хотя бы один сетевой адрес либо хотя бы одна подсеть. Домены и указатели страниц сайтов для таких записей могут отсутствовать. Получается, что записи entryType=4 могут иметь только IP или подсеть. Неужели нужно подсеть будет блокировать ?