MaLblsH

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

Да, было дело. Нам ещё Смотёшка прислала письмо о каких-то проблемах на 9-ке.

Судя по "*" в поле IP, надо лукапить эти домены и поддомены (какие ?!) и проверять, что в заблокированных в итоге IP нет IP из этих доменов..

По такой же причине переходим на сабж. С прошивкой 6.13.B025 ушли баги, которые мешали нам жить (проблемы с инкрементной загрузкой через TFTP) и сброс списка VLAN в DHCP_RELAY после ребута. Месяц стоят, полёт нормальный.

А как вы приостановление сервиса реализовали? Смотрешка предлагает каждый раз при блокировке отписывать юзера от пакетов и потом подписывать по-новой. Тоже интересует данный момент. Ибо в API не нашёл функционала по приостановлению услуг. Приостанавливать списание в биллинге Агента нет смысла - пока услуги висят на Абоненте, Агенту будут идти начисление. Остаётся только реализовывать кнопку "Временно приостановить услугу" в личном кабинете, по которой производить реальную отписку от пакетов данного клиента, а себе куда-то в базу записывать эти пакеты. А по нажатию на кнопку "Возобновить" подключать ранее отключённые пакеты, делая т.о. видимость приостановки услуг для клиента.

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

Пробовали ставить 8x и отключали автонастройку - скорость упала до 1-2 мбит/с. GPS синхронизацию попробуем. Разносили частоты, предварительно просканиронировав airView. Точно сейчас не скажу какие именно ставили, но разница у них была примерно 100 GHz. Скорость упала примерно в 2 раза. Скан сделаем завтра, точки сейчас отключены. Кстати реальная пропускная способность равна капасити, что уже радует. Но вот злосчастная "недосотка" настораживает. Как будто реально где-то упирается в полку и не может больше.

Скорее всего это был торрент, который мы ошибочно приняли за атаку.

Вам спасибо за труды! Логи нашёл сразу же, очень удобно! :) А нас продолжают "потрахивать", но теперь уже приходится блокировать полностью абонентов, т.к. 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 с нашей стороны постоянно разные. Я не склонен верить в теории заговоров, но есть шанс, что нас "заказали". Уж больно даты начала атак и ещё кое-какая дата сходятся. "Совпадение ? Не думаю" (с)

Ясен бен писать новую прошивку для регистраторов для исправления не основного, скажем так, функционала они если будут, то очень не скоро :) Это мы ещё давно закрыли, как только появились первые алерты в radar.qrator о том, что наши IPs с уязвимостью NTP используются для DDoS атак. Как только я увидел, что атака идёт на абонента, то первым делом просто заблочил весь трафик к нему на свитче поближе к "миру". Да и потом, как выяснилось, сначала атаковали его STEAM Сервер CS (27017 порт, под спойлером tcpdump-а он фигуририрует). Сейчас закинул ещё пару портов из того же STEAM-а. Да можно в принципе открыть только трафик с udp/123 на udp/123, а остальной трафик с udp/123 закрыть к чёртовой матери, но тем самым обломаю клиентов с NTPv2. Хотя их можно попросить использовать внутрисетевой NTP сервер. Всё равно как-то некрасиво. Вот похожие правила попросить бы прописать на нашем порту со стороны аплинка.

Можно конечно и письма разослать... Да вот только по нам хорошенько катком прошлись в последний раз: Это уже отсортированные уникальные записи. Итог: 4667 ip. Вот эти все товарищи накинулись на одного нашего абонента. Сгенерировали за несколько минут около 4 гигабит трафика (и то это был всплеск, который зафиксировал cacti, а значит могло быть гораздо больше). Если автоматизировать рассылку на abuse ящики контактным лицам, то нас самих быстрее забанят за спам :)

Эту тему читал. Это всё мы блокируем на своей сети. Как нам "заставить" это делать провайдера своего, который не хочет/не может или ещё по каким-то причинам не реализует blackhole ? Мы же платим за входящий трафик, который провайдером считается на порту подключения, к которому мы доступ естественно не имеем. Один провайдер действительно пошёл на встречу и сообщил, что сейчас они допиливают blackhole, а пока превышения считать не будут. А вот остальных надо как-то попросить/уговорить.

В последнее время начали периодически получать мощные всплески входящего трафика с UDP порта 123. Судя по всему это DDoS атака эксплуатирующая известную уязвимость в NTP серверах. Атакуются некоторые наши абоненты с внешними IP адресами (т.е. не за NAT'ом). fastnetmon выявляет эти атаки: Ну и немного tcpdump: Сейчас мы блокируем этот трафик на своём оборудовании, но в идеале мы вообще не хотим его получать и обрабатывать. Как бы "заставить" аплинков делать это за нас? Коллеги, прошу совета: может у кого-нибудь уже имеется опыт? P.S.> Всего 2 из нескольких наших аплинков обладают blackhole. P.P.S.> Уже думаем о том, чтобы попросить у наших аплинков доступ к их оборудованию, чтобы автоматически создавать блокирующие правила там. :)

Пользователи рунета пожаловались на недоступность сервисов Google. У меня не резолвится только plus.google.com (no answer). Это на PDNS. Работающий параллельно BIND9 нормально резолвит %)

Уверены? Точно уверены? А уверены, что вайршарк считает gratuitious arp тем же, что и апстрим? Ибо я - не уверен, и gratuitious arp может быть чем угодно в принципе, что не попадает под обязательные требования стандарта (т.е. arp who-has поиска соседа и arp reply на него). В частности, центос/рхел при старте ифейса опрашивает, а нет ли соседей с этим адресом, и если сосед есть - адрес не поднимает. Может, этот пакет определяется как gratuitious (ибо с т.з. апстрима кто-то третьий левый в сегменте вопрошает адрес второго конца пира). Согласен с Вами. Но я в самом начале переписки с немцами попросил их прислать дамп пакета, который они считают за gratuitious arp. В ответ на это от них тишина. Т.е. если бы они прислали дамп, я бы этот трафик вычислил и запретил.