Время на прочтение
19 мин
Количество просмотров 60K
По долгу службы мне часто приходится сталкиваться с DDOS на сервера, но некоторое время назад столкнулся с другой атакой, к которой был не готов. Атака производилась на роутер Juniper MX80 поддерживающий BGP сессии и выполняющий анонс подсетей дата-центра. Целью атакующих был веб-ресурс расположенный на одном из наших серверов, но в результате атаки, без связи с внешним миром остался весь дата-центр. Подробности атаки, а также тесты и методы борьбы с такими атаками под катом.
История атаки
Исторически сложилось, что на роутере блокируется весь UDP трафик летящий в нашу сеть. Первая волна атаки (в 17:22) была как раз UDP трафиком, график unicast пакетов с аплинка роутера:
и график unicast пакетов с порта свича подключенного к роутеру:
демонстрируют, что весь трафик осел на фильтре роутера. Поток unicast пакетов на аплинке роутера увеличился на 400 тысяч и атака только UDP пакетами продолжалась до 17:33. Далее атакующие изменили стратегию и добавили к атаке UDP еще и атаку TCP SYN пакетами на атакуемый сервер, а также на сам роутер. Как видно по графику, роутеру стало настолько плохо, что он перестал отдавать SNMP в zabbix. После волны SYN на порты роутера стали отваливаться BGP сессии с пирами (используется три аплинка с каждого получаем full view по ipv4 и по ipv6), в логах появились трагические записи:
Jun 27 17:35:07 ROUTER rpd[1408]: bgp_hold_timeout:4035: NOTIFICATION sent to ip.ip.ip.ip (External AS 1111): code 4 (Hold Timer Expired Error), Reason: holdtime expired for ip.ip.ip.ip (External AS 1111), socket buffer sndcc: 19 rcvcc: 0 TCP state: 4, snd_una: 1200215741 snd_nxt: 1200215760 snd_wnd: 15358 rcv_nxt: 4074908977 rcv_adv: 4074925361, hold timer out 90s, hold timer remain 0s
Jun 27 17:35:33 ROUTER rpd[1408]: bgp_hold_timeout:4035: NOTIFICATION sent to ip.ip.ip.ip (External AS 1111): code 4 (Hold Timer Expired Error), Reason: holdtime expired for ip.ip.ip.ip (External AS 1111), socket buffer sndcc: 38 rcvcc: 0 TCP state: 4, snd_una: 244521089 snd_nxt: 244521108 snd_wnd: 16251 rcv_nxt: 3829118827 rcv_adv: 3829135211, hold timer out 90s, hold timer remain 0s
Jun 27 17:37:26 ROUTER rpd[1408]: bgp_hold_timeout:4035: NOTIFICATION sent to ip.ip.ip.ip (External AS 1111): code 4 (Hold Timer Expired Error), Reason: holdtime expired for ip.ip.ip.ip (External AS 1111), socket buffer sndcc: 19 rcvcc: 0 TCP state: 4, snd_una: 1840501056 snd_nxt: 1840501075 snd_wnd: 16384 rcv_nxt: 1457490093 rcv_adv: 1457506477, hold timer out 90s, hold timer remain 0s
Как было выяснено позже, после атаки, волна TCP SYN увеличила нагрузку на routing engine роутера после чего упали все BGP сессии и роутер не смог самостоятельно восстановить работу. Атака на роутер длилась несколько минут, но из-за дополнительной нагрузки, роутер не мог обработать full view с трех аплинков и сессии снова рвались. Восстановить работу удалось только поочередным поднятием всех BGP сессий. Дальнейшая атака шла на сам сервер.
Испытание в условиях стенда и воспроизведение атаки
В качестве цели атаки использовался Juniper MX80 с той же версией прошивки, что и на боевом роутере. В качестве атакующего использовался сервер с 10Gb картой и установленной на нем ubuntu server + quagga. Генератором трафика выступал скрипт с вызовом утилиты hping3. Для проверки пагубного воздействия “всплесков” трафика, скрипт генерировал трафик с временными разрывами: 30 секунд атака — 2 секунды атаки нет. Также, для чистоты эксперимента, была поднята BGP сессия между роутером и сервером. В установленной на тот момент конфигурации боевого роутера, порты BGP и SSH были открыты на всех интерфейсах/адресах роутера и не фильтровались. Аналогичная конфигурация была перенесена на стендовый роутер.
Первым этапом испытаний стала атака TCP SYN на BGP (179) порт роутера. Ip адрес источника совпадал с адресом пира в конфиге. IP address spoofing не исключался, так как у наших аплинков не включен uPRF. Сессия была установлена. Со стороны quagga:
BGP router identifier 9.4.8.2, local AS number 9123
RIB entries 3, using 288 bytes of memory
Peers 1, using 4560 bytes of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
9.4.8.1 4 1234 1633 2000 0 0 0 00:59:56 0
Total number of neighbors 1
Со стороны Juniper:
user@MX80> show bgp summary
Groups: 1 Peers: 1 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0
2 1 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
9.4.8.2 4567 155 201 0 111 59:14 1/2/2/0 0/0/0/0
После начала атаки (13:52) на роутер летит ~1.2 Mpps трафика:
или 380Mbps:
Нагрузка на CPU RE и CPU FE роутера возрастает:
После таймаута (90 сек) BGP сессия падает и больше не поднимается:
Jul 4 13:54:01 MX80 rpd[1407]: bgp_hold_timeout:4035: NOTIFICATION sent to 9.4.8.2 (External AS 4567): code 4 (Hold Timer Expired Error), Reason: holdtime expired for 9.4.8.2 (External AS 4567), socket buffer sndcc: 38 rcvcc: 0 TCP state: 4, snd_una: 3523671294 snd_nxt: 3523671313 snd_wnd: 114 rcv_nxt: 1556791630 rcv_adv: 1556808014, hold timer out 90s, hold timer remain 0s
Роутер занят обработкой прилетающего TCP SYN на порт BGP и не может установить сессию. На порту множество пакетов:
user@MX80> monitor traffic interface ge-1/0/0 count 20
13:55:39.219155 In IP 9.4.8.2.2097 > 9.4.8.1.bgp: S 1443462200:1443462200(0) win 512
13:55:39.219169 In IP 9.4.8.2.27095 > 9.4.8.1.bgp: S 295677290:295677290(0) win 512
13:55:39.219177 In IP 9.4.8.2.30114 > 9.4.8.1.bgp: S 380995480:380995480(0) win 512
13:55:39.219184 In IP 9.4.8.2.57280 > 9.4.8.1.bgp: S 814209218:814209218(0) win 512
13:55:39.219192 In IP 9.4.8.2.2731 > 9.4.8.1.bgp: S 131350916:131350916(0) win 512
13:55:39.219199 In IP 9.4.8.2.2261 > 9.4.8.1.bgp: S 2145330024:2145330024(0) win 512
13:55:39.219206 In IP 9.4.8.2.z39.50 > 9.4.8.1.bgp: S 1238175350:1238175350(0) win 512
13:55:39.219213 In IP 9.4.8.2.2098 > 9.4.8.1.bgp: S 1378645261:1378645261(0) win 512
13:55:39.219220 In IP 9.4.8.2.30115 > 9.4.8.1.bgp: S 1925718835:1925718835(0) win 512
13:55:39.219227 In IP 9.4.8.2.27096 > 9.4.8.1.bgp: S 286229321:286229321(0) win 512
13:55:39.219235 In IP 9.4.8.2.2732 > 9.4.8.1.bgp: S 1469740166:1469740166(0) win 512
13:55:39.219242 In IP 9.4.8.2.57281 > 9.4.8.1.bgp: S 1179645542:1179645542(0) win 512
13:55:39.219254 In IP 9.4.8.2.2262 > 9.4.8.1.bgp: S 1507663512:1507663512(0) win 512
13:55:39.219262 In IP 9.4.8.2.914c/g > 9.4.8.1.bgp: S 1219404184:1219404184(0) win 512
13:55:39.219269 In IP 9.4.8.2.2099 > 9.4.8.1.bgp: S 577616492:577616492(0) win 512
13:55:39.219276 In IP 9.4.8.2.267 > 9.4.8.1.bgp: S 1257310851:1257310851(0) win 512
13:55:39.219283 In IP 9.4.8.2.27153 > 9.4.8.1.bgp: S 1965427542:1965427542(0) win 512
13:55:39.219291 In IP 9.4.8.2.30172 > 9.4.8.1.bgp: S 1446880235:1446880235(0) win 512
13:55:39.219297 In IP 9.4.8.2.57338 > 9.4.8.1.bgp: S 206377149:206377149(0) win 512
13:55:39.219305 In IP 9.4.8.2.2789 > 9.4.8.1.bgp: S 838483872:838483872(0) win 512
Вторым этапом испытаний стала атака TCP SYN на BGP (179) порт роутера. Ip адрес источника выбирался рандомно и не совпадал с адресом пира указанным в конфиге роутера. Эта атака произвела на роутер такой же эффект. Дабы не растягивать статью однообразными выводами логов, приведу только график нагрузки:
По графику отчетливо видно момент начала атаки. BGP сессия также упала и не смогла восстановиться.
Концепция построения защиты RE роутера
Особенность работы оборудования Juniper заключается в разделении задач между routing engine (RE) и packet forwarding engine (PFE). PFE обрабатывает весь поток проходящего трафика осуществляя его фильтрацию и маршрутизацию по заранее сформированной схеме. RE занимается обработкой прямых обращений к роутеру (traceroute, ping, ssh), обработкой пакетов для служебных сервисов (BGP, NTP, DNS, SNMP) и формирует схемы фильтрации и маршрутизации трафика для PFE роутера.
Основная идея защиты роутера состоит в фильтрации всего трафика предназначенного для RE. Создание фильтра позволит перенести нагрузку, создаваемую DDOS атакой, с CPU RE на CPU PFE роутера, что даст возможность RE обрабатывать только реальные пакеты и не тратить процессорное время на другой трафик. Для построения защиты необходимо определить, что фильтруем. Схема написания фильтров для IPv4 была взята из книги Douglas Hanks Jr. — Day One Book: Securing the Routing Engine on M, MX and T series. В моем случае на роутере схема была следующей:
По протоколу IPv4
- BGP — фильтруем пакеты по source и destination ip, source ip может быть любой из списка bgp neighbor. Разрешаем только подключения tcp established, то есть фльтр будет отбрасывать все SYN прилетающие на этот порт, а сессия BGP будет начинаться только от нас (BGP сосед аплинка работает в пассивном режиме).
- TACACS+ — фильтруем пакеты по source и destination ip, source ip может быть только из внутренней сети. Ограничиваем полосу пропускания в 1Mb/s.
- SNMP — фильтруем пакеты по source и destination ip, source ip может быть любой из списка snmp-clients в конфиге.
- SSH — фильтруем пакеты по destination ip, source ip может быть любой, так как есть необходимость экстренного доступа к устройству из любой сети. Ограничиваем полосу пропускания в 5Mb/s.
- NTP — фильтруем пакеты по source и destination ip, source ip может быть любой из списка ntp servers конфига. Ограничиваем полосу пропускания в 1Mb/s (в дальнейшем порог был уменьшен до 512Kb/s).
- DNS — фильтруем пакеты по source и destination ip, source ip может быть любой из списка dns servers конфига. Ограничиваем полосу пропускания в 1Mb/s.
- ICMP — фильтруем пакеты, пропускаем только на адреса принадлежащие роутеру. Ограничиваем полосу пропускания в 5Mb/s (в дальнейшем порог был уменьшен до 1Mb/s).
- TRACEROUTE — фильтруем пакеты, пропускаем только пакеты с TTL равным 1 и только на адреса принадлежащие роутеру. Ограничиваем полосу пропускания в 1Mb/s.
По протоколу IPv6, в моем случае, фильтры накладывались только на BGP, NTP, ICMP, DNS и traceroute. Единственное отличие в фильтрации ICMP трафика, так как IPv6 использует ICMP в служебных целях. Остальные протоколы не использовали IPv6 адресацию.
Написание конфигурации
Для написания фильтров в juniper существует удобный инструмент — prefix-list, который позволяет динамически составлять списки ip адресов/подсетей для подстановки в фильтры. Например, для создания списка адресов ipv4 BGP соседей указанных в конфиге, используется следующая структура:
prefix-list BGP-neighbors-v4 {
apply-path "protocols bgp group <*> neighbor <*.*>";
}результат составления списка:
show configuration policy-options prefix-list BGP-neighbors-v4 | display inheritance
##
## apply-path was expanded to:
## 1.1.1.1/32;
## 2.2.2.2/32;
## 3.3.3.3/32;
##
apply-path «protocols bgp group <*> neighbor <*.*>»;
Составляем динамические списки префиксов для всех фильтров:
/* Список всех ipv4 адресов соседей BGP */
prefix-list BGP-neighbors-v4 {
apply-path "protocols bgp group <*> neighbor <*.*>";
}
/* Список всех ipv6 адресов соседей BGP */
prefix-list BGP-neighbors-v6 {
apply-path "protocols bgp group <*> neighbor <*:*>";
}
/* Список всех ipv4 серверов NTP */
prefix-list NTP-servers-v4 {
apply-path "system ntp server <*.*>";
}
/* Список всех ipv6 серверов NTP */
prefix-list NTP-servers-v6 {
apply-path "system ntp server <*:*>";
}
/* Список всех ipv4 адресов назначеных роутеру */
prefix-list LOCALS-v4 {
apply-path "interfaces <*> unit <*> family inet address <*>";
}
/* Список всех ipv6 адресов назначеных роутеру */
prefix-list LOCALS-v6 {
apply-path "interfaces <*> unit <*> family inet6 address <*>";
}
/* Список всех ipv4 адресов SNMP клиентов */
prefix-list SNMP-clients {
apply-path "snmp client-list <*> <*>";
}
prefix-list SNMP-community-clients {
apply-path "snmp community <*> clients <*>";
}
/* Список всех серверов TACACS+ */
prefix-list TACPLUS-servers {
apply-path "system tacplus-server <*>";
}
/* Список адресов роутера которые принадлежат внутренней сети */
prefix-list INTERNAL-locals {
/* В моем случае лучший вариант - ручное указание адреса */
192.168.0.1/32;
}
/* Список адресов роутера на интерфейсе управления, для доступа по SSH */
prefix-list MGMT-locals {
apply-path "interfaces fxp0 unit 0 family inet address <*>";
}
/* Приватные сети */
prefix-list rfc1918 {
10.0.0.0/8;
172.16.0.0/12;
192.168.0.0/16;
}
/* Loopback */
prefix-list localhost-v6 {
::1/128;
}
prefix-list localhost-v4 {
127.0.0.0/8;
}
/* Список всех ipv4 локальных адресов BGP */
prefix-list BGP-locals-v4 {
apply-path "protocols bgp group <*> neighbor <*.*> local-address <*.*>";
}
/* Список всех ipv6 локальных адресов BGP */
prefix-list BGP-locals-v6 {
apply-path "protocols bgp group <*> neighbor <*:*> local-address <*:*>";
}
/* Список всех ipv4 серверов DNS */
prefix-list DNS-servers-v4 {
apply-path "system name-server <*.*>";
}
/* Список всех ipv6 серверов DNS */
prefix-list DNS-servers-v6 {
apply-path "system name-server <*:*>";
}
Составляем полисеры для ограничения пропускной способности:
/* Ограничение в 1Mb */
policer management-1m {
apply-flags omit;
if-exceeding {
bandwidth-limit 1m;
burst-size-limit 625k;
}
/* Все что не помещается дропаем */
then discard;
}
/* Ограничение в 5Mb */
policer management-5m {
apply-flags omit;
if-exceeding {
bandwidth-limit 5m;
burst-size-limit 625k;
}
/* Все что не помещается дропаем */
then discard;
}
/* Ограничение в 512Kb */
policer management-512k {
apply-flags omit;
if-exceeding {
bandwidth-limit 512k;
burst-size-limit 25k;
}
/* Все что не помещается дропаем */
then discard;
}
Ниже, под «копи-паст», конфигурация фильтров конечного варианта защиты (были уменьшены пороги пропускной способности трафика NTP и ICMP, причины снижения порогов подробно описаны в разделе тестирования). Настраиваем фильтры ipv4:
IPv4 filter
/* Фильтр BGP трафика */
filter accept-bgp {
interface-specific;
term accept-bgp {
from {
source-prefix-list {
BGP-neighbors-v4;
}
destination-prefix-list {
BGP-locals-v4;
}
/* пассивный режим работы соседа. Сессия начинается с нашей стороны. */
tcp-established;
protocol tcp;
port bgp;
}
then {
count accept-bgp;
accept;
}
}
}
/* Фильтр SSH трафика */
filter accept-ssh {
apply-flags omit;
term accept-ssh {
from {
destination-prefix-list {
MGMT-locals;
}
protocol tcp;
destination-port ssh;
}
then {
/* ограничение пропускной способности */
policer management-5m;
count accept-ssh;
accept;
}
}
}
/* Фильтр SNMP трафика */
filter accept-snmp {
apply-flags omit;
term accept-snmp {
from {
source-prefix-list {
SNMP-clients;
SNMP-community-clients;
}
destination-prefix-list {
/* Подключение только на адрес внутренней сети */
INTERNAL-locals;
}
protocol udp;
destination-port [ snmp snmptrap ];
}
then {
count accept-snmp;
accept;
}
}
}
/* Фильтр ICMP трафика */
filter accept-icmp {
apply-flags omit;
/* Отбрасываем фрагментированные пакеты ICMP */
term discard-icmp-fragments {
from {
is-fragment;
protocol icmp;
}
then {
count discard-icmp-fragments;
discard;
}
}
term accept-icmp {
from {
protocol icmp;
icmp-type [ echo-reply echo-request time-exceeded unreachable source-quench router-advertisement parameter-problem ];
}
then {
/* ограничение пропускной способности */
policer management-1m;
count accept-icmp;
accept;
}
}
}
/* фильтр traceroute трафика */
filter accept-traceroute {
apply-flags omit;
term accept-traceroute-udp {
from {
destination-prefix-list {
LOCALS-v4;
}
protocol udp;
/* ограничение в TTL = 1 */
ttl 1;
destination-port 33434-33450;
}
then {
/* ограничение пропускной способности */
policer management-1m;
count accept-traceroute-udp;
accept;
}
}
term accept-traceroute-icmp {
from {
destination-prefix-list {
LOCALS-v4;
}
protocol icmp;
/* ограничение в TTL = 1 */
ttl 1;
icmp-type [ echo-request timestamp time-exceeded ];
}
then {
/* ограничение пропускной способности */
policer management-1m;
count accept-traceroute-icmp;
accept;
}
}
term accept-traceroute-tcp {
from {
destination-prefix-list {
LOCALS-v4;
}
protocol tcp;
/* ограничение в TTL = 1 */
ttl 1;
}
then {
/* ограничение пропускной способности */
policer management-1m;
count accept-traceroute-tcp;
accept;
}
}
}
/* фильтр DNS трафика */
filter accept-dns {
apply-flags omit;
term accept-dns {
from {
source-prefix-list {
DNS-servers-v4;
}
destination-prefix-list {
LOCALS-v4;
}
protocol udp;
source-port 53;
}
then {
/* ограничение пропускной способности */
policer management-1m;
count accept-dns;
accept;
}
}
}
/* фильтр для отбрасывания не прошедших все проверки пакетов */
filter discard-all {
apply-flags omit;
term discard-ip-options {
from {
ip-options any;
}
then {
/* счетчик пакетов для сбора статистики */
count discard-ip-options;
log;
discard;
}
}
term discard-TTL_1-unknown {
from {
ttl 1;
}
then {
/* счетчик пакетов для сбора статистики */
count discard-TTL_1-unknown;
log;
discard;
}
}
term discard-tcp {
from {
protocol tcp;
}
then {
/* счетчик пакетов для сбора статистики */
count discard-tcp;
log;
discard;
}
}
term discard-udp {
from {
protocol udp;
}
then {
/* счетчик пакетов для сбора статистики */
count discard-udp;
log;
discard;
}
}
term discard-icmp {
from {
destination-prefix-list {
LOCALS-v4;
}
protocol icmp;
}
then {
/* счетчик пакетов для сбора статистики */
count discard-icmp;
log;
discard;
}
}
term discard-unknown {
then {
/* счетчик пакетов для сбора статистики */
count discard-unknown;
log;
discard;
}
}
}
/* фильтр TACACS+ трафика */
filter accept-tacacs {
apply-flags omit;
term accept-tacacs {
from {
source-prefix-list {
TACPLUS-servers;
}
destination-prefix-list {
INTERNAL-locals;
}
protocol [ tcp udp ];
source-port [ tacacs tacacs-ds ];
tcp-established;
}
then {
/* ограничение пропускной способности */
policer management-1m;
count accept-tacacs;
accept;
}
}
}
/* фильтр NTP трафика */
filter accept-ntp {
apply-flags omit;
term accept-ntp {
from {
source-prefix-list {
NTP-servers-v4;
localhost-v4;
}
destination-prefix-list {
localhost-v4;
LOCALS-v4;
}
protocol udp;
destination-port ntp;
}
then {
/* ограничение пропускной способности */
policer management-512k;
count accept-ntp;
accept;
}
}
}
/* родительский фильтр для ветвления фильтрации и упрощения применения фильтра на интерфейс */
filter accept-common-services {
term protect-TRACEROUTE {
filter accept-traceroute;
}
term protect-ICMP {
filter accept-icmp;
}
term protect-SSH {
filter accept-ssh;
}
term protect-SNMP {
filter accept-snmp;
}
term protect-NTP {
filter accept-ntp;
}
term protect-DNS {
filter accept-dns;
}
term protect-TACACS {
filter accept-tacacs;
}
}
Аналогичный фильтр для ipv6:
IPv6 filter
/* фильтр BGP трафика */
filter accept-v6-bgp {
interface-specific;
term accept-v6-bgp {
from {
source-prefix-list {
BGP-neighbors-v6;
}
destination-prefix-list {
BGP-locals-v6;
}
tcp-established;
next-header tcp;
port bgp;
}
then {
count accept-v6-bgp;
accept;
}
}
}
/* фильтр ICMP трафика */
filter accept-v6-icmp {
apply-flags omit;
term accept-v6-icmp {
from {
next-header icmp6;
/* фильтр по типу более лояльный, так как ipv6 требуется icmp */
icmp-type [ echo-reply echo-request time-exceeded router-advertisement parameter-problem destination-unreachable packet-too-big router-solicit neighbor-solicit neighbor-advertisement redirect ];
}
then {
policer management-1m;
count accept-v6-icmp;
accept;
}
}
}
/* фильтр traceroute трафика */
filter accept-v6-traceroute {
apply-flags omit;
term accept-v6-traceroute-udp {
from {
destination-prefix-list {
LOCALS-v6;
}
next-header udp;
destination-port 33434-33450;
hop-limit 1;
}
then {
policer management-1m;
count accept-v6-traceroute-udp;
accept;
}
}
term accept-v6-traceroute-tcp {
from {
destination-prefix-list {
LOCALS-v6;
}
next-header tcp;
hop-limit 1;
}
then {
policer management-1m;
count accept-v6-traceroute-tcp;
accept;
}
}
term accept-v6-traceroute-icmp {
from {
destination-prefix-list {
LOCALS-v6;
}
next-header icmp6;
icmp-type [ echo-reply echo-request router-advertisement parameter-problem destination-unreachable packet-too-big router-solicit neighbor-solicit neighbor-advertisement redirect ];
hop-limit 1;
}
then {
policer management-1m;
count accept-v6-traceroute-icmp;
accept;
}
}
}
/* фильтр DNS трафика */
filter accept-v6-dns {
apply-flags omit;
term accept-v6-dns {
from {
source-prefix-list {
DNS-servers-v6;
}
destination-prefix-list {
LOCALS-v6;
}
next-header udp;
source-port 53;
}
then {
policer management-1m;
count accept-v6-dns;
accept;
}
}
}
/* фильтр NTP трафика */
filter accept-v6-ntp {
apply-flags omit;
term accept-v6-ntp {
from {
source-prefix-list {
NTP-servers-v6;
localhost-v6;
}
destination-prefix-list {
localhost-v6;
LOCALS-v6;
}
next-header udp;
destination-port ntp;
}
then {
policer management-512k;
count accept-v6-ntp;
accept;
}
}
}
/* фильтр отбрасывающий остальные пакеты */
filter discard-v6-all {
apply-flags omit;
term discard-v6-tcp {
from {
next-header tcp;
}
then {
count discard-v6-tcp;
log;
discard;
}
}
term discard-v6-udp {
from {
next-header udp;
}
then {
count discard-v6-udp;
log;
discard;
}
}
term discard-v6-icmp {
from {
destination-prefix-list {
LOCALS-v6;
}
next-header icmp6;
}
then {
count discard-v6-icmp;
log;
discard;
}
}
term discard-v6-unknown {
then {
count discard-v6-unknown;
log;
discard;
}
}
}
/* родительский фильтр для ветвления фильтрации и упрощения применения фильтра на интерфейс */
filter accept-v6-common-services {
term protect-TRACEROUTE {
filter accept-v6-traceroute;
}
term protect-ICMP {
filter accept-v6-icmp;
}
term protect-NTP {
filter accept-v6-ntp;
}
term protect-DNS {
filter accept-v6-dns;
}
}
Далее необходимо применить фильтры на служебный интерфейс lo0.0. В системе JunOS этот интерфейс используется для передачи данных между PFE и RE. Конфигурация примет следующий вид:
lo0 {
unit 0 {
family inet {
filter {
input-list [ accept-bgp accept-common-services discard-all ];
}
}
family inet6 {
filter {
input-list [ accept-v6-bgp accept-v6-common-services discard-v6-all ];
}
}
}
}
Порядок указания фильтров в input-list интерфейса очень важен. Каждый пакет будет проверяться на валидность проходя по фильтрам указанным в input-list слева направо.
Тестирование фильтров
После применения фильтров, провел ряд тестов на том же стенде. После каждого теста выполнялась очистка счетчиков firewall. Нормальная (без атаки) нагрузка на роутере видна на графиках в 11:06 — 11:08. График pps за весь период тестов:
График CPU за весь период тестов:
Первым проводился тест флуда icmp c порогом трафика 5Мб/с (на графиках 10:21 — 10:24). По счетчикам фильтра и на графике видно ограничение по трафика по пропускной способности, но даже этого потока было достаточно для повышения нагрузки, поэтому порог был уменьшен до 1Мб/с. Счетчики:
Filter: lo0.0-i
Counters:
Name Bytes Packets
accept-bgp-lo0.0-i 0 0
accept-icmp-lo0.0-i 47225584 1686628
accept-ntp-lo0.0-i 152 2
accept-snmp-lo0.0-i 174681 2306
accept-ssh-lo0.0-i 38952 702
accept-traceroute-icmp-lo0.0-i 0 0
accept-traceroute-tcp-lo0.0-i 841 13
accept-traceroute-udp-lo0.0-i 0 0
discard-TTL_1-unknown-lo0.0-i 0 0
discard-icmp-lo0.0-i 0 0
discard-icmp-fragments-lo0.0-i 0 0
discard-ip-options-lo0.0-i 0 0
discard-tcp-lo0.0-i 780 13
discard-udp-lo0.0-i 18743 133
discard-unknown-lo0.0-i 0 0
Policers:
Name Bytes Packets
management-1m-accept-ntp-lo0.0-i 0 0
management-1m-accept-traceroute-icmp-lo0.0-i 0 0
management-1m-accept-traceroute-tcp-lo0.0-i 0 0
management-1m-accept-traceroute-udp-lo0.0-i 0 0
management-5m-accept-icmp-lo0.0-i 933705892 33346639
management-5m-accept-ssh-lo0.0-i 0 0
Повторный тест флуда icmp c порогом трафика 1Мб/с (на графиках 10:24 — 10:27). Нагрузка на RE роутера упала с 19% до 10%, нагрузка на PFE до 30%. Счетчики:
Filter: lo0.0-i
Counters:
Name Bytes Packets
accept-bgp-lo0.0-i 0 0
accept-icmp-lo0.0-i 6461448 230766
accept-ntp-lo0.0-i 0 0
accept-snmp-lo0.0-i 113433 1497
accept-ssh-lo0.0-i 33780 609
accept-traceroute-icmp-lo0.0-i 0 0
accept-traceroute-tcp-lo0.0-i 0 0
accept-traceroute-udp-lo0.0-i 0 0
discard-TTL_1-unknown-lo0.0-i 0 0
discard-icmp-lo0.0-i 0 0
discard-icmp-fragments-lo0.0-i 0 0
discard-ip-options-lo0.0-i 0 0
discard-tcp-lo0.0-i 360 6
discard-udp-lo0.0-i 12394 85
discard-unknown-lo0.0-i 0 0
Policers:
Name Bytes Packets
management-1m-accept-icmp-lo0.0-i 665335496 23761982
management-1m-accept-ntp-lo0.0-i 0 0
management-1m-accept-traceroute-icmp-lo0.0-i 0 0
management-1m-accept-traceroute-tcp-lo0.0-i 0 0
management-1m-accept-traceroute-udp-lo0.0-i 0 0
management-5m-accept-ssh-lo0.0-i 0 0
Следующим был проведен тест флуда на порт BGP роутера с постороннего (не включеного в конфиг) ip адреса (на графиках 10:29 — 10:36). Как видно из счетчиков, весь флуд осел на discard-tcp фильтре RE и лишь увеличил нагрузку на PFE. Нагрузка на RE не изменилась. Счетчики:
Filter: lo0.0-i
Counters:
Name Bytes Packets
accept-bgp-lo0.0-i 824 26
accept-icmp-lo0.0-i 0 0
accept-ntp-lo0.0-i 0 0
accept-snmp-lo0.0-i 560615 7401
accept-ssh-lo0.0-i 33972 585
accept-traceroute-icmp-lo0.0-i 0 0
accept-traceroute-tcp-lo0.0-i 1088 18
accept-traceroute-udp-lo0.0-i 0 0
discard-TTL_1-unknown-lo0.0-i 0 0
discard-icmp-lo0.0-i 0 0
discard-icmp-fragments-lo0.0-i 0 0
discard-ip-options-lo0.0-i 0 0
discard-tcp-lo0.0-i 12250785600 306269640
discard-udp-lo0.0-i 63533 441
discard-unknown-lo0.0-i 0 0
Policers:
Name Bytes Packets
management-1m-accept-icmp-lo0.0-i 0 0
management-1m-accept-ntp-lo0.0-i 0 0
management-1m-accept-traceroute-icmp-lo0.0-i 0 0
management-1m-accept-traceroute-tcp-lo0.0-i 0 0
management-1m-accept-traceroute-udp-lo0.0-i 0 0
management-5m-accept-ssh-lo0.0-i 0 0
сессия не падает:
user@MX80# run show bgp summary
Groups: 1 Peers: 1 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0
2 1 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
9.4.8.2 4567 21 22 0 76 8:49 1/2/2/0 0/0/0/0
Четвертым был проведен тест флуда (на графиках 10:41 — 10:46) UDP на порт NTP (в настройках фильтра взаимодействие по этому порту ограничивается серверами указанными в конфиге роутера). По графику, нагрузка поднимается только на PFE роутера до 28%. Счетчики:
Filter: lo0.0-i
Counters:
Name Bytes Packets
accept-bgp-lo0.0-i 0 0
accept-icmp-lo0.0-i 0 0
accept-ntp-lo0.0-i 0 0
accept-snmp-lo0.0-i 329059 4344
accept-ssh-lo0.0-i 22000 388
accept-traceroute-icmp-lo0.0-i 0 0
accept-traceroute-tcp-lo0.0-i 615 10
accept-traceroute-udp-lo0.0-i 0 0
discard-TTL_1-unknown-lo0.0-i 0 0
discard-icmp-lo0.0-i 0 0
discard-icmp-fragments-lo0.0-i 0 0
discard-ip-options-lo0.0-i 0 0
discard-tcp-lo0.0-i 0 0
discard-udp-lo0.0-i 1938171670 69219329
discard-unknown-lo0.0-i 0 0
Policers:
Name Bytes Packets
management-1m-accept-icmp-lo0.0-i 0 0
management-1m-accept-ntp-lo0.0-i 0 0
management-1m-accept-traceroute-icmp-lo0.0-i 0 0
management-1m-accept-traceroute-tcp-lo0.0-i 0 0
management-1m-accept-traceroute-udp-lo0.0-i 0 0
management-5m-accept-ssh-lo0.0-i 0 0
Пятым был проведен тест флуда (на графиках 10:41 — 11:04) UDP на порт NTP с IP spoofing. Нагрузка на RE увеличилась на 12%, нагрузка на PFE увеличилась до 22%. По счетчикам видно, что флуд упирается в порог 1Мб/с, но этого достаточно для повышения нагрузки на RE. Порог трафика в итоге был уменьшен до 512Кб/с. Счетчики:
Filter: lo0.0-i
Counters:
Name Bytes Packets
accept-bgp-lo0.0-i 0 0
accept-icmp-lo0.0-i 0 0
accept-ntp-lo0.0-i 34796804 1242743
accept-snmp-lo0.0-i 630617 8324
accept-ssh-lo0.0-i 20568 366
accept-traceroute-icmp-lo0.0-i 0 0
accept-traceroute-tcp-lo0.0-i 1159 19
accept-traceroute-udp-lo0.0-i 0 0
discard-TTL_1-unknown-lo0.0-i 0 0
discard-icmp-lo0.0-i 0 0
discard-icmp-fragments-lo0.0-i 0 0
discard-ip-options-lo0.0-i 0 0
discard-tcp-lo0.0-i 0 0
discard-udp-lo0.0-i 53365 409
discard-unknown-lo0.0-i 0 0
Policers:
Name Bytes Packets
management-1m-accept-icmp-lo0.0-i 0 0
management-1m-accept-ntp-lo0.0-i 3717958468 132784231
management-1m-accept-traceroute-icmp-lo0.0-i 0 0
management-1m-accept-traceroute-tcp-lo0.0-i 0 0
management-1m-accept-traceroute-udp-lo0.0-i 0 0
management-5m-accept-ssh-lo0.0-i 0 0
Повторный тест флуда (на графике ниже 11:29 — 11:34) UDP на порт NTP с IP spoofing, но с порогом трафика 512Кб/с. График нагрузки:
Счетчики:
Filter: lo0.0-i
Counters:
Name Bytes Packets
accept-bgp-lo0.0-i 0 0
accept-icmp-lo0.0-i 0 0
accept-ntp-lo0.0-i 21066260 752363
accept-snmp-lo0.0-i 744161 9823
accept-ssh-lo0.0-i 19772 347
accept-traceroute-icmp-lo0.0-i 0 0
accept-traceroute-tcp-lo0.0-i 1353 22
accept-traceroute-udp-lo0.0-i 0 0
discard-TTL_1-unknown-lo0.0-i 0 0
discard-icmp-lo0.0-i 0 0
discard-icmp-fragments-lo0.0-i 0 0
discard-ip-options-lo0.0-i 0 0
discard-tcp-lo0.0-i 0 0
discard-udp-lo0.0-i 82745 602
discard-unknown-lo0.0-i 0 0
Policers:
Name Bytes Packets
management-1m-accept-icmp-lo0.0-i 0 0
management-1m-accept-traceroute-icmp-lo0.0-i 0 0
management-1m-accept-traceroute-tcp-lo0.0-i 0 0
management-1m-accept-traceroute-udp-lo0.0-i 0 0
management-512k-accept-ntp-lo0.0-i 4197080384 149895728
management-5m-accept-ssh-lo0.0-i 0 0
Заключение
В итоге всех проведенных тестов удалось получить, устойчивую к DDOS атакам, конфигурацию фильтров трафика RE. В настоящий момент эта конфигурация уже применена на боевом роутере и проблем не выявлено. По счетчикам с боевого MX80:
Filter: lo0.0-i
Counters:
Name Bytes Packets
accept-v6-bgp-lo0.0-i 31091878 176809
accept-v6-icmp-lo0.0-i 1831144 26705
accept-v6-ntp-lo0.0-i 0 0
accept-v6-traceroute-icmp-lo0.0-i 0 0
accept-v6-traceroute-tcp-lo0.0-i 48488 684
accept-v6-traceroute-udp-lo0.0-i 0 0
discard-v6-icmp-lo0.0-i 0 0
discard-v6-tcp-lo0.0-i 0 0
discard-v6-udp-lo0.0-i 0 0
discard-v6-unknown-lo0.0-i 0 0
Policers:
Name Bytes Packets
management-1m-accept-v6-icmp-lo0.0-i 0 0
management-1m-accept-v6-traceroute-icmp-lo0.0-i 0 0
management-1m-accept-v6-traceroute-tcp-lo0.0-i 0 0
management-1m-accept-v6-traceroute-udp-lo0.0-i 0 0
management-512k-accept-v6-ntp-lo0.0-i 0 0
Filter: lo0.0-i
Counters:
Name Bytes Packets
accept-bgp-lo0.0-i 135948400 698272
accept-dns-lo0.0-i 374 3
accept-icmp-lo0.0-i 121304849 1437305
accept-ntp-lo0.0-i 87780 1155
accept-snmp-lo0.0-i 1265470648 12094967
accept-ssh-lo0.0-i 2550011 30897
accept-tacacs-lo0.0-i 702450 11657
accept-traceroute-icmp-lo0.0-i 28824 636
accept-traceroute-tcp-lo0.0-i 75378 1361
accept-traceroute-udp-lo0.0-i 47328 1479
discard-TTL_1-unknown-lo0.0-i 27790 798
discard-icmp-lo0.0-i 26400 472
discard-icmp-fragments-lo0.0-i 0 0
discard-ip-options-lo0.0-i 35680 1115
discard-tcp-lo0.0-i 73399674 1572144
discard-udp-lo0.0-i 126386306 694603
discard-unknown-lo0.0-i 0 0
Policers:
Name Bytes Packets
management-1m-accept-dns-lo0.0-i 0 0
management-1m-accept-icmp-lo0.0-i 38012 731
management-1m-accept-tacacs-lo0.0-i 0 0
management-1m-accept-traceroute-icmp-lo0.0-i 0 0
management-1m-accept-traceroute-tcp-lo0.0-i 0 0
management-1m-accept-traceroute-udp-lo0.0-i 0 0
management-512k-accept-ntp-lo0.0-i 0 0
management-5m-accept-ssh-lo0.0-i 0 0
видно какое количество “левого” трафика оседает на фильтре discard.
Буду рад ответить на все вопросы в комментариях.
Как устроить DDoS атаку на WIFI соседа
Локнетовцы, здарова! Раздражает сосед или просто хотите подшутить над ним? Тогда эта статья для вас. Мы научимся устраивать DDoS атаки на любые роутеры. Желаю вам приятного чтения!
Замечу, что эта статья написана только для образовательных целей. Мы никого ни к чему не призываем, только в целях ознакомления! Автор не несёт ответственности за ваши действия!
Установка.
В качестве ОС в нашем случае выступает Parrot Security OS.
- Как всегда будем работать через рут доступ, чтобы его получить надо ввести su и если попросит пароль вводим toor.
- Обновляем репозитории командой apt update
- Клонируем программу mdk4 c github’a, для этого вводим команду: git clone https://github.com/aircrack-ng/mdk4.git
- Устанавливаем зависимости apt-get install pkg-config libnl-3-dev libnl-genl-3-dev libpcap-dev
- Устанавливаем сам mdk4. Пишем cd mdk4 дальше make а потом вводим команду sudo make install
Работа с mdk4
Итак, mdk4 имеет 9 видов атак. Но мы же рассмотрим 2 из них, а именно
Beacon Flooding и Authentication Denial-Of-Service
Beacon Flooding
Этот модуль создает множество WIFI точек, и тем самым нагружая все устройства со включенными Wifi. Данный вид атаки очень опасен для слабых адаптеров старых телефонов, так как чрезмерная нагрузка на сетевой адаптер может сильно нагреть материнскую плату, что приведет к его полному сгоранию.
Начинаем
- Просим рут доступ командой su . Если попросит пароль пишем toor
- Узнаем название своего адаптера командой ifconfig
В нашем случае это wlan0
3. Включаем режим мониторинга для этой сетевой карты командой airmon-ng start wlan0
Внимание: при включении режима мониторинга пропадает интернет соединение
После включения режима мониторинга мы можем узнать новое название нашего интерфейса, все той же командой ifconfig
4. Теперь все готово к запуску программы
[название команды + название интерфейса + режим атаки + параметры атаки]
Получается вот такая команда: mdk4 wlan0mon b
- mdk4 — название программы которую мы используем
- wlan0mon — название интерфейса
- b — указывает использование атаки Beacon Flooding
- При желании можно указать название точек доступа которые будут создаваться, для этого после b пишем параметр -n [название точки доступа]
Получается вот такая команда: mdk4 wlan0mon b -n вася
Наши пакеты пошли и вот что мы видим при поиске Wifi:
Чтобы остановить нужно нажать ctrl+c
Чтобы остановить режим мониторинга нужно ввести airmon-ng stop wlan0mon
Authentication Denial-Of-Service
- Чтобы использовать этот вид атаки, нужно все так же включить режим мониторинга как описано в пунктах 2-3 в Beacon Flooding
- Для того чтобы отключить какую-либо точку доступа, нужно знать его Mac адресс.
Чтобы узнать какой мак адресс у точки доступа жертвы, вводим такую команду:
airodump-ng wlan0mon
3. Далее работаем все по той же схеме [название команды + название интерфейса + режим атаки + параметры атаки]
Получаем вот такую команду:
mdk4 wlan0mon a -a 50:FF:20:24:B8:BE
- mdk4 — название программы которую мы используем
- wlan0mon — название интерфейса
- a — выбираем тип атаки Authentication Denial-Of-Service
- -a — это параметр который указывает что за ним пойдет мак адресс точки доступа
Вот у нас пошли пакеты деаутентификации и теперь никто не сможет подключиться к данному Wifi.
ВАЖНЫЕ ССЫЛКИ:
Мой второй канал LOCKNET | MONEY — ТЫК
Обучающий канал LOCKNET | Обучение — ТЫК
Без роутера уже сложно представить офис или дом. Он создает частную сеть, благодаря которой выходят в интернет, чтобы работать, учиться или просто смотреть контент. Через него проходит весь трафик: поисковые запросы, файлы, электронные письма, фотографии, фильмы и многое другое. Важно обеспечить безопасность роутеру, чтобы он не вышел из строя, а также сохранил конфиденциальность входящих и исходящих данных пользователей.
В тексте читатель встретит два понятия: роутер и маршрутизатор. В чем их разница? На самом деле это два разных названия одного и того же устройства. «Роутер» — это транслитерация английского слова «router», которым обозначается аппарат для маршрутизации пакетов данных между различными сегментами сети на основе специальных таблиц. Отсюда и появился второй термин — «маршрутизатор». Оба слова использовать корректно.
Может ли роутер быть атакован
Генерация большого количества запросов выводит из строя сайт. Пользователь не может совершить покупку в интернет-магазине или зайти в личный кабинет. Зачастую такие сбои в работе сайта провоцируют кибератаки. То же самое может произойти и с роутером.
3 распространённых угрозы для маршрутизатора:
1. DDoS-атака
Злоумышленники утилизируют полосы пропускания, чтобы вывести систему из строя из-за исчерпания системных ресурсов (каналов связи, процессов, памяти). Все типы подобных атак совершаются путем отправки большого количества запросов на атакуемый ресурс.
2. Взлом сети
Более изощренные зловреды атакуют маршрутизатор, чтобы получить доступ к корпоративной сети организации или домашней сети пользователя. Они перехватывают весь трафик, который через них проходит, чтобы использовать его в своих целях.
3. Поглощение ботнетом
Роутер заражают вредоносным ПО, и он становится частью ботнета, принимая участие в DDoS-атаках. Зараженный роутер может стать инструментом для шпионажа через IoT (Интернет вещей), накручивать число просмотров роликов или статей или скрыто майнить криптовалюту.
Всемирная организация по борьбе со спамом Spamhaus занимается изучением спама и других киберпреступлений. Согласно анализу за 2021 год, было зафиксировано 9491 атак с помощью ботнетов. Ожидаем, что данные за 2022 покажут небывалый прирост в количестве инцидентов с участием ботнетов
Как защитить свою сеть и что делать, если ваш роутер оказался под атакой — рассмотрим далее.
Рядовой пользователь вряд ли обнаружит атаку самостоятельно, но может заметить ее «симптомы»: медленный интернет, долгая загрузка страниц, сбои в работе подключения. Если пользователь обладает базовыми знаниями по системному администрированию, можно использовать диагностику операционной системы.
Если у вас Windows, откройте встроенную программу «Просмотр событий» — она покажет ошибки. У Linux за это отвечает просмотр log-файла. Также пользователь может подключиться к роутеру и запустить проверочные утилиты:
- Victoria — используют для оценки состояния жесткого диска.
- BlueScreenView — чтобы понять причину «синего экрана смерти».
- Memtest — для проверки состояния оперативной памяти.
Специалист по сетевой безопасности с помощью анализа базового состояния сети сможет определить, как сеть работает в обычном режиме и увидит, если возникнет нетипичное поведение.
Второй способ обнаружения и блокировки кибератак — использование flow-протоколов. Это один из самых эффективных инструментов, которым не следует пренебрегать. Суть flow-протокола заключается в анализе «слепка трафика». Он проходит через определенные интерфейсы, и специалист видит данные о пакетах, а впоследствии сможет накапливать аналитику. Это поможет увидеть аномалии и оперативно заблокировать их. Вариантов использования flow-протоколов множество — все зависит от того, что поддерживает конкретный маршрутизатор.
Могут ли DDoS-атаки повредить маршрутизатор
Если представить, что атакующий — это грозный злоумышленник с кувалдой, который ворвется в серверную, а потом со всего маху ударит по маршрутизатору, в таком случае, он, конечно же, выйдет из строя. В реальности DDoS-атаки физически повредить роутеру едва ли смогут, но создадут временные трудности или сделают сервис недоступным.
Перезапуск маршрутизатора как попытка спастись от DDoS
В сети можно найти советы по борьбе с кибератаками путем полного отключения или перезапуска маршрутизатора. Авторы статей рекомендуют выключить роутер во время кибератаки, чтобы интернет-провайдер назначил новый IP-адрес. Но важно понимать, что изменится только динамический IP, статический же останется прежним. И если у злоумышленника будет именно он, то такой способ борьбы с кибератакой бесполезен. Также стоит отметить, что данный пример относится исключительно к сегменту домашнего интернета и как способ борьбы с DDoS в корпоративных сетях даже не рассматривается.
После мощных атак может случиться так называемое «залипание соединения». Атака завершилась, но маршрутизатор не пропускает пакеты данных. В таком случае лучше перезагрузить технику. Это частный пример, который встречается довольно редко.
Зачастую перезапуск маршрутизатора ничего не исправит, а напротив — выполнит цель злоумышленника. Ведь в таком случае техника выключится, что приведет к недоступности ресурса, а это именно то, чего и добиваются атакующие.
Как остановить DDoS-атаку на роутер
Легче предупредить, чем лечить — идеальный пример того, как строить защиту своей сети. Но что делать в ситуации, когда атака идет, а защиты нет? Представьте сильный дождь, который застал путника в дороге. Что он сделает, чтобы защититься от него? Будет искать укрытие. Например, под зонтиком. В этой роли выступит провайдер, который защитит инфраструктуру от нападения. Вы сможете выбрать почасовую тарификацию и платить только тогда, когда вас атакуют или подобрать специализированное решение под ваш проект.
Как защитить маршрутизатор от DDoS
Частота DDoS-атак растет из года в год. Данные международной организации Spamhaus за 2021 год и наша статистика тому подтверждение. Незащищенная сеть может стать причиной серьезных убытков. Чтобы избежать этого, достаточно следовать нескольким правилам, которые для удобства разделим на две категории: «защита домашней сети» и «защита корпоративной сети». Так как задачи и нагрузочные мощности разные, способы их защиты будут отличаться.
Чтобы защитить домашний роутер от несанкционированного доступа, следуйте нескольким правилам:
Придумайте надежный пароль. Он должен иметь как минимум 9 знаков, среди которых будут цифры, символы, прописные и строчные буквы. Также каждые пол года рекомендуется менять пароль.
Проверяйте обновления на сайте производителя роутера. Обновляйте прошивку по мере выхода новых патчей. Узнать, как обновить ПО устройства, можно на сайте поставщика.
Отключите удаленный доступ к настройкам администратора. Инструкция по отключению будет на сайте поставщика вашего роутера.
Сделайте вашу сеть Wi-Fi невидимой. Используйте руководство пользователя для вашей модели роутера. Ваша сеть перестанет отображаться в списке доступных беспроводных сетей, и обнаружить ее будет очень сложно.
Проверьте, корректно ли работает встроенный фаервол в вашем роутере. В настройках исключите свободный доступ к устройству из интернета.
Не используйте конфигурации и файлы, скачанные из интернета. Они могут нести в себе скрытую угрозу в виде вредоносного вируса, который передаст ваши данные злоумышленнику или повредит их.
Основная защита маршрутизатора корпоративной сети должна строится на комплексе двух мер:
1. Control Plane Policing
Технология превентивной защиты от сетевых атак, которая ограждает ресурсы от внешнего воздействия. CoPP фильтрует и ограничивает трафик, поступающий на маршрутизатор.
2. Защита сети по модели SaaS
Чтобы обеспечить бесперебойную работу корпоративной инфраструктуры, используйте надежную защиту сети, которая создаст оптимальную маршрутизацию трафика с фильтрацией от всех известных видов DDoS-атак, а также сможет защитить онлайн-сервисы вне зависимости от используемых протоколов.
Читайте в телеграм-канале DDoS-Guard
Анонсы, статьи, истории и советы по кибербезопасности. Каждый месяц собираем дайджест о самых громких событиях
Подписаться
Are you interested in learning how to DDoS a router as a pro? There is nothing ethical in launching DDoS, but this page is educational. You can’t talk about DDoS without mentioning his junior partner, the DoS. While the acronym DDoS means Distributed Denial of Service, DoS stands for Denial of Service. DDoS and DoS are potent attacks on the server or network by directing excessive traffic aiming to cripple it down.
Are There Differences Between DDoS And DoS?
Both activities aim towards attacking a website or service with voluminous information that is hard to process. Although the two have a similar objective, DDoS launches its attack from multiple sources, whereas DoS attacks the victim by flooding the information from a single source.
Due to the nature of the attack, DDoS is more potent than its partner in crime, DoS.
Imagine a scenario where your power supply is excessive. In such a scenario, it destroys all electronic and lighting devices connected to it as it has no other escape route. This is what is replicated in your router when it is bombarded with excessive information than it can process.
Why Should Anybody DDoS A Router?
DDoS attacks are destructive and difficult to control. From the economic perspective, the attacks don’t make sense. However, cybercriminals use these attacks as a weapon to slow down competitors. The criminals might target a cyber-security tool hosted by a specific site or decapitate an online business competing with their products.
The other reason cybercriminals attack networks with distributed Denial of service is to extort. In this scenario, the victim is disabled until payment is done for the attack to stop.
Others use the attack as a smokescreen and infect the victim with malware, or worse still, extract the desired information.
Did you know that cybercrooks might bombard traffic to your router without any motive? You might wonder why anybody in the right frame of mind can waste time and resources launching an expensive multi-attack such as DDoS to your router. However, note that some crooks attack services for fun, test their abilities, or cause destruction.
Can You DDoS Someone Cyber Crook Style?
If you have the resolve, there are numerous tools to DDoS any router in the badass style. You are not limited to a single way of launching your Denial of service attacks, but you rather have several methods at your disposal.
Even armatures without hacking experience can cause considerable harm if they access the right tools. You can hire the tools and hit your target hard to achieve your desired goals.
Here is how you can attack your target’s router successfully:
1. DDoS A Router Using Botnets
Botnets is s term used to describe computers or internet-connected devices that bear malware and can be controlled by a central computer known as the command and control center.
Bigger bonnets compromise millions of devices and place them under their web without their owners’ knowledge.
Cybercriminals use botnets in conducting a wide variety of unlawful activities such as cryptocurrency mining, phishing, or pushing spam emails.
Some botnets are available for hire if you can afford them. With your hands on these compromised devices, you can launch a DDoS attack of a larger magnitude.
2. Attacking A Router Using DDoS Tools And Programs
If you are a low-scale hacker, chances are you cannot afford the luxury of botnets. Your only possible option is using your computer for the task. It would help if you had unique tools to direct the traffic to your targeted router to accomplish the job.
Though the amount of traffic sent by one computer is small, the effect is magnified by cloud sourcing a few thousand other users. Here, a hacker gets smarter by asking followers to download a specific tool and stay active on a messaging platform like IRC at a designated time. They then launch an attack simultaneously to bring down the targeted router or other devices.
Here is a list of tools that hackers utilize in carrying out DDoS attacks:
1. Low Orbit Ion Cannon (LOIC).
2. XOIC.
3. HTTP Unbearable King (HULK).
4. Tor’s Hammer.
5. R-U-Dead-Yet.
6. Layer 7 DDoS Simulator (DDSSIM)
3. Using A Cmd To DDoS An IP
This method uses a fundamental denial of service method christened the “ping of death” to hack into smaller devices like routers and a single computer. It uses a command to infiltrate and bombard the targeted device with data packets.
The ping of death can’t attack massive targets. The attacks are effective against smaller targets such as:
1. A Wireless Router: When you flood the router with packets of data, you hinder its ability to send traffic to all connected devices. The endgame is cutting internet to all devices connected to the router.
2. A Single Computer: To send a ping of death to a single computer requires you to acquire its IP address and use it to wreak havoc on the device.
A ping of death might be a basic and small attack that can only harm small devices like routers. Still, if you use multiple computers to simultaneously send the ping of death, you will cause massive and irreparable damage to smaller websites.
4. Teardrop DDoS Router Attacks
The information transmitted between a client and a server is voluminous that it can’t be sent as one piece. For easy handling, data is broken down into small packets that reassemble once they reach the server.
The server is equipped with a parameter known as “offset,” which rebuilds the information correctly.
Teardrop DDoS attacks take advantage of this process by sending confusing data to the server. The data sent contain dysfunctional or overlapping offset parameters.
When the server receives such data, it tries to rearrange it in vain; due to the compromised offset parameters, the end game is the grinding down of the router or website.
5. Amplifying DDoS Attack On A Router
You can maximize the byte by amplifying its flood via DNS reflection attacks. The process is done in multi-steps:
1. First, you assume the identity of the targeted router’s IP address by forging it.
2. Use the forged identity to send numerous DNS queries to a DNS resolver.
3. Each query’s information is sent back to the targeted router after processing. Nonetheless, the data packets sent back by the DNS resolver are voluminous compared to the sent queries.
Typically, every single bite of data gets amplified to 30 or 40 bytes. Sometimes amplification surpasses these parameters. If you have access to botnets, you can amplify the traffic further to bring down the router or even a website.
Types Of DDoS Attacks
The Denial of service attacks come in two broad categories hinging on the vector of the attack. The categories are:
1. Application Layer.
2. Network Layer.
Application Layer Attacks
Application layer attacks target particular software or programs routinely used by the device or websites.
Application layer distributed denial of service compromises one of the two used commands (POST and GET) commands to bombard the device or website with overwhelming requests that are difficult to handle.
Network Layer Attacks
This type of DDoS attack focuses its energy on flooding the infrastructure hosting a website with unbearable data.
These kinds of layer attacks come in numerous sizes and shapes. Below are the common ones:
1. UDP Amplified Attacks.
2. SYN or Synchronize Attacks.
3. DNS Reflecting Attacks.
The disadvantage of amplified attacks DDoS attacks is that a massive amount of traffic bombards the victims; thus, it is easier to identify the type of attack facing them.
Additional Distributed Denial Of Service Attack Tools
Here are the additional tools available for you to use in launching DDoS Attacks:
1. Nemesy– the Nemesy tool is used in generating random packets and is compatible with windows. Download the tool online. However, if your computer is equipped with antivirus, it will detect the program as a virus.
2. Land and La Tierra- the land and La Tierra tool can be effectively used to spoof the IP address and open TCP connections.
3. Blast- the blast tool is fatal in performing DDoS attacks and is readily available for download.
4. The Panther tool- if you desire to flood your target’s network or device with UDP packets, the panther DDoS attack tool is your ideal companion.
Ways Of Guarding Your Router Against DDoS
Generally, it isn’t easy to protect your router from becoming compromised. However, you can take the following measures to maximize its security:
1. Use a robust firewall to thwart crooks from identifying your router’s IP address.
2. Ensure all devices connected to the internet have an up-to-date antivirus to guard them against DDoS attacks.
3. Update your operating system at all times.
4. Ensure that your router’s software is up-to-date
5. Update all your voice chart programs.
6. Avoid using third-party servers.
7. Use a VPN.
Conclusion
Launching a DDoS attack on a router is doable. Everything connected to the internet is at the mercy of denial of service attacks from cyber crooks. The process might be complicated and expensive for armatures, but it is not rocket science; thus, you can do it. However, be aware that DDoS attacks are not an excellent game regardless of the endgame.
DDOS атаки на маршрутизатор и методы защиты Juniper routing engine
По долгу службы мне часто приходится сталкиваться с DDOS на сервера, но некоторое время назад столкнулся с другой атакой, к которой был не готов. Атака производилась на маршрутизатор Juniper MX80 поддерживающий BGP сессии и выполняющий анонс сетей дата-центра. Целью атакующих был веб-ресурс расположенный на одном из наших серверов, но в результате атаки, без связи с внешним миром остался весь дата-центр. Подробности атаки, а также тесты и методы борьбы с такими атаками под катом.
История атаки
Исторически сложилось, что на маршрутизаторе блокируется весь UDP трафик летящий в нашу сеть. Первая волна атаки (в 17:22) была как раз UDP трафиком, график unicast пакетов с аплинка маршрутизатора:
и график unicast пакетов с порта свича подключенного к роутеру:
демонстрируют, что весь трафик осел на фильтре маршрутизатора. Поток unicast пакетов на аплинке маршрутизатора увеличился на 400 тысяч и атака только UDP пакетами продолжалась до 17:33. Далее атакующие изменили стратегию и добавили к атаке UDP еще и атаку TCP SYN пакетами на атакуемый сервер, а также на сам маршрутизатор. Как видно по графику, маршрутизатору стало настолько плохо, что он перестал отдавать SNMP в zabbix. После волны SYN на порты маршрутизатора стали отваливаться BGP сессии с пирами (используется три аплинка с каждого получаем full view по ipv4 и по ipv6), в логах появились трагические записи:
Jun 27 17:35:07 ROUTER rpd[1408]: bgp_hold_timeout:4035: NOTIFICATION sent to ip.ip.ip.ip (External AS 1111): code 4 (Hold Timer Expired Error), Reason: holdtime expired for ip.ip.ip.ip (External AS 1111), socket buffer sndcc: 19 rcvcc: 0 TCP state: 4, snd_una: 1200215741 snd_nxt: 1200215760 snd_wnd: 15358 rcv_nxt: 4074908977 rcv_adv: 4074925361, hold timer out 90s, hold timer remain 0s
Jun 27 17:35:33 ROUTER rpd[1408]: bgp_hold_timeout:4035: NOTIFICATION sent to ip.ip.ip.ip (External AS 1111): code 4 (Hold Timer Expired Error), Reason: holdtime expired for ip.ip.ip.ip (External AS 1111), socket buffer sndcc: 38 rcvcc: 0 TCP state: 4, snd_una: 244521089 snd_nxt: 244521108 snd_wnd: 16251 rcv_nxt: 3829118827 rcv_adv: 3829135211, hold timer out 90s, hold timer remain 0s
Jun 27 17:37:26 ROUTER rpd[1408]: bgp_hold_timeout:4035: NOTIFICATION sent to ip.ip.ip.ip (External AS 1111): code 4 (Hold Timer Expired Error), Reason: holdtime expired for ip.ip.ip.ip (External AS 1111), socket buffer sndcc: 19 rcvcc: 0 TCP state: 4, snd_una: 1840501056 snd_nxt: 1840501075 snd_wnd: 16384 rcv_nxt: 1457490093 rcv_adv: 1457506477, hold timer out 90s, hold timer remain 0s
Как было выяснено позже, после атаки, волна TCP SYN увеличила нагрузку на routing engine маршрутизатора после чего упали все BGP сессии и маршрутизатор не смог самостоятельно восстановить работу. Атака на маршрутизатор длилась несколько минут, но из-за дополнительной нагрузки, маршрутизатор не мог обработать full view с трех аплинков и сессии снова рвались. Восстановить работу удалось только поочередным поднятием всех BGP сессий. Дальнейшая атака шла на сам сервер.
Испытание в условиях стенда и воспроизведение атаки
В качестве цели атаки использовался Juniper MX80 с той же версией прошивки, что и на боевом роутере. В качестве атакующего использовался сервер с 10Gb картой и установленной на нем ubuntu server + quagga. Генератором трафика выступал скрипт с вызовом утилиты hping3. Для проверки пагубного воздействия “всплесков” трафика, скрипт генерировал трафик с временными разрывами: 30 секунд атака — 2 секунды атаки нет. Также, для чистоты эксперимента, была поднята BGP сессия между маршрутизатором и сервером. В установленной на тот момент конфигурации боевого маршрутизатора, порты BGP и SSH были открыты на всех интерфейсах/адресах маршрутизатора и не фильтровались. Аналогичная конфигурация была перенесена на стендовый маршрутизатор.
Первым этапом испытаний стала атака TCP SYN на BGP (179) порт маршрутизатора. IP адрес источника совпадал с адресом пира в конфигурации маршрутизатора. IP address spoofing не исключался, так как у наших аплинков не включен uPRF. Сессия была установлена. Со стороны quagga:
BGP router identifier 9.4.8.2, local AS number 9123
RIB entries 3, using 288 bytes of memory
Peers 1, using 4560 bytes of memoryNeighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
9.4.8.1 4 1234 1633 2000 0 0 0 00:59:56 0
Total number of neighbors 1
Со стороны Juniper:
user@MX80> show bgp summary
Groups: 1 Peers: 1 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0
2 1 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
9.4.8.2 4567 155 201 0 111 59:14 1/2/2/0 0/0/0/0
После начала атаки (13:52) на маршрутизатор летит ~1.2 Mpps трафика:
или 380Mbps:
Нагрузка на CPU RE и CPU FE маршрутизатора возрастает:
После задержки (90 сек) BGP сессия падает и больше не поднимается:
Jul 4 13:54:01 MX80 rpd[1407]: bgp_hold_timeout:4035: NOTIFICATION sent to 9.4.8.2 (External AS 4567): code 4 (Hold Timer Expired Error), Reason: holdtime expired for 9.4.8.2 (External AS 4567), socket buffer sndcc: 38 rcvcc: 0 TCP state: 4, snd_una: 3523671294 snd_nxt: 3523671313 snd_wnd: 114 rcv_nxt: 1556791630 rcv_adv: 1556808014, hold timer out 90s, hold timer remain 0s
Маршрутизатор занят обработкой прилетающего TCP SYN на порт BGP и не может установить сессию. На порту множество пакетов:
user@MX80> monitor traffic interface ge-1/0/0 count 20
13:55:39.219155 In IP 9.4.8.2.2097 > 9.4.8.1.bgp: S 1443462200:1443462200(0) win 512
13:55:39.219169 In IP 9.4.8.2.27095 > 9.4.8.1.bgp: S 295677290:295677290(0) win 512
13:55:39.219177 In IP 9.4.8.2.30114 > 9.4.8.1.bgp: S 380995480:380995480(0) win 512
13:55:39.219184 In IP 9.4.8.2.57280 > 9.4.8.1.bgp: S 814209218:814209218(0) win 512
13:55:39.219192 In IP 9.4.8.2.2731 > 9.4.8.1.bgp: S 131350916:131350916(0) win 512
13:55:39.219199 In IP 9.4.8.2.2261 > 9.4.8.1.bgp: S 2145330024:2145330024(0) win 512
13:55:39.219206 In IP 9.4.8.2.z39.50 > 9.4.8.1.bgp: S 1238175350:1238175350(0) win 512
13:55:39.219213 In IP 9.4.8.2.2098 > 9.4.8.1.bgp: S 1378645261:1378645261(0) win 512
13:55:39.219220 In IP 9.4.8.2.30115 > 9.4.8.1.bgp: S 1925718835:1925718835(0) win 512
13:55:39.219227 In IP 9.4.8.2.27096 > 9.4.8.1.bgp: S 286229321:286229321(0) win 512
13:55:39.219235 In IP 9.4.8.2.2732 > 9.4.8.1.bgp: S 1469740166:1469740166(0) win 512
13:55:39.219242 In IP 9.4.8.2.57281 > 9.4.8.1.bgp: S 1179645542:1179645542(0) win 512
13:55:39.219254 In IP 9.4.8.2.2262 > 9.4.8.1.bgp: S 1507663512:1507663512(0) win 512
13:55:39.219262 In IP 9.4.8.2.914c/g > 9.4.8.1.bgp: S 1219404184:1219404184(0) win 512
13:55:39.219269 In IP 9.4.8.2.2099 > 9.4.8.1.bgp: S 577616492:577616492(0) win 512
13:55:39.219276 In IP 9.4.8.2.267 > 9.4.8.1.bgp: S 1257310851:1257310851(0) win 512
13:55:39.219283 In IP 9.4.8.2.27153 > 9.4.8.1.bgp: S 1965427542:1965427542(0) win 512
13:55:39.219291 In IP 9.4.8.2.30172 > 9.4.8.1.bgp: S 1446880235:1446880235(0) win 512
13:55:39.219297 In IP 9.4.8.2.57338 > 9.4.8.1.bgp: S 206377149:206377149(0) win 512
13:55:39.219305 In IP 9.4.8.2.2789 > 9.4.8.1.bgp: S 838483872:838483872(0) win 512
Вторым этапом испытаний стала атака TCP SYN на BGP (179) порт маршрутизатора. IP адрес источника выбирался случайно и не совпадал с адресом пира указанным в конфигурации маршрутизатора. Эта атака произвела на маршрутизатор такой же эффект. Дабы не растягивать статью однообразными выводами логов, приведу только график нагрузки:
По графику отчетливо видно момент начала атаки. BGP сессия также упала и не смогла восстановиться.
Концепция построения защиты RE маршрутизатора
Особенность работы оборудования Juniper заключается в разделении задач между routing engine (RE) и packet forwarding engine (PFE). PFE обрабатывает весь поток проходящего трафика осуществляя его фильтрацию и маршрутизацию по заранее сформированной схеме. RE занимается обработкой прямых обращений к маршрутизатору (traceroute, ping, ssh), обработкой пакетов для служб BGP, NTP, DNS, SNMP и формирует схемы фильтрации и маршрутизации трафика для PFE маршрутизатора.
Основная идея защиты маршрутизатора состоит в фильтрации всего трафика предназначенного для RE. Создание фильтра позволит перенести нагрузку, создаваемую DDOS атакой, с CPU RE на CPU PFE маршрутизатора, что даст возможность RE обрабатывать только реальные пакеты и не тратить процессорное время на другой трафик. Для построения защиты необходимо определить, что фильтруем. Схема написания фильтров для IPv4 была взята из книги Douglas Hanks Jr. — Day One Book: Securing the Routing Engine on M, MX and T series. В моем случае на маршрутизаторе схема была следующей:
По протоколу IPv4
- BGP — фильтруем пакеты по source и destination ip, source ip может быть любой из списка bgp neighbor. Разрешаем только подключения tcp established, то есть фльтр будет отбрасывать все SYN прилетающие на этот порт, а сессия BGP будет начинаться только от нас (BGP сосед аплинка работает в пассивном режиме).
- TACACS+ — фильтруем пакеты по source и destination ip, source ip может быть только из внутренней сети. Ограничиваем полосу пропускания в 1Mb/s.
- SNMP — фильтруем пакеты по source и destination ip, source ip может быть любой из списка snmp-clients в конфигурации.
- SSH — фильтруем пакеты по destination ip, source ip может быть любой, так как есть необходимость экстренного доступа к устройству из любой сети. Ограничиваем полосу пропускания в 5Mb/s.
- NTP — фильтруем пакеты по source и destination ip, source ip может быть любой из списка ntp servers конфигурации. Ограничиваем полосу пропускания в 1Mb/s (в дальнейшем порог был уменьшен до 512Kb/s).
- DNS — фильтруем пакеты по source и destination ip, source ip может быть любой из списка dns servers конфигурации. Ограничиваем полосу пропускания в 1Mb/s.
- ICMP — фильтруем пакеты, пропускаем только на адреса принадлежащие маршрутизатору. Ограничиваем полосу пропускания в 5Mb/s (в дальнейшем порог был уменьшен до 1Mb/s).
- TRACEROUTE — фильтруем пакеты, пропускаем только пакеты с TTL равным 1 и только на адреса принадлежащие маршрутизатору. Ограничиваем полосу пропускания в 1Mb/s.
По протоколу IPv6, в моем случае, фильтры накладывались только на BGP, NTP, ICMP, DNS и traceroute. Единственное отличие в фильтрации ICMP трафика, так как IPv6 использует ICMP в служебных целях. Остальные протоколы не использовали IPv6 адресацию.
Написание конфигурации
Для написания фильтров в juniper существует удобный инструмент — prefix-list, который позволяет динамически составлять списки ip адресов/подсетей для подстановки в фильтры. Например, для создания списка адресов ipv4 BGP соседей указанных в конфигурации, используется следующая структура:
prefix-list BGP-neighbors-v4 {
apply-path "protocols bgp group <*> neighbor <*.*>";
}результат составления списка:
show configuration policy-options prefix-list BGP-neighbors-v4 | display inheritance
##
## apply-path was expanded to:
## 1.1.1.1/32;
## 2.2.2.2/32;
## 3.3.3.3/32;
##
apply-path «protocols bgp group <*> neighbor <*.*>»;
Составляем динамические списки префиксов для всех фильтров:
/* Список всех ipv4 адресов соседей BGP */
prefix-list BGP-neighbors-v4 {
apply-path "protocols bgp group <*> neighbor <*.*>";
}
/* Список всех ipv6 адресов соседей BGP */
prefix-list BGP-neighbors-v6 {
apply-path "protocols bgp group <*> neighbor <*:*>";
}
/* Список всех ipv4 серверов NTP */
prefix-list NTP-servers-v4 {
apply-path "system ntp server <*.*>";
}
/* Список всех ipv6 серверов NTP */
prefix-list NTP-servers-v6 {
apply-path "system ntp server <*:*>";
}
/* Список всех ipv4 адресов назначеных роутеру */
prefix-list LOCALS-v4 {
apply-path "interfaces <*> unit <*> family inet address <*>";
}
/* Список всех ipv6 адресов назначеных роутеру */
prefix-list LOCALS-v6 {
apply-path "interfaces <*> unit <*> family inet6 address <*>";
}
/* Список всех ipv4 адресов SNMP клиентов */
prefix-list SNMP-clients {
apply-path "snmp client-list <*> <*>";
}
prefix-list SNMP-community-clients {
apply-path "snmp community <*> clients <*>";
}
/* Список всех серверов TACACS+ */
prefix-list TACPLUS-servers {
apply-path "system tacplus-server <*>";
}
/* Список адресов роутера которые принадлежат внутренней сети */
prefix-list INTERNAL-locals {
/* В моем случае лучший вариант - ручное указание адреса */
192.168.0.1/32;
}
/* Список адресов роутера на интерфейсе управления, для доступа по SSH */
prefix-list MGMT-locals {
apply-path "interfaces fxp0 unit 0 family inet address <*>";
}
/* Приватные сети */
prefix-list rfc1918 {
10.0.0.0/8;
172.16.0.0/12;
192.168.0.0/16;
}
/* Loopback */
prefix-list localhost-v6 {
::1/128;
}
prefix-list localhost-v4 {
127.0.0.0/8;
}
/* Список всех ipv4 локальных адресов BGP */
prefix-list BGP-locals-v4 {
apply-path "protocols bgp group <*> neighbor <*.*> local-address <*.*>";
}
/* Список всех ipv6 локальных адресов BGP */
prefix-list BGP-locals-v6 {
apply-path "protocols bgp group <*> neighbor <*:*> local-address <*:*>";
}
/* Список всех ipv4 серверов DNS */
prefix-list DNS-servers-v4 {
apply-path "system name-server <*.*>";
}
/* Список всех ipv6 серверов DNS */
prefix-list DNS-servers-v6 {
apply-path "system name-server <*:*>";
}
Составляем политики для ограничения пропускной способности:
/* Ограничение в 1Mb */
policer management-1m {
apply-flags omit;
if-exceeding {
bandwidth-limit 1m;
burst-size-limit 625k;
}
/* Все что не помещается дропаем */
then discard;
}
/* Ограничение в 5Mb */
policer management-5m {
apply-flags omit;
if-exceeding {
bandwidth-limit 5m;
burst-size-limit 625k;
}
/* Все что не помещается дропаем */
then discard;
}
/* Ограничение в 512Kb */
policer management-512k {
apply-flags omit;
if-exceeding {
bandwidth-limit 512k;
burst-size-limit 25k;
}
/* Все что не помещается дропаем */
then discard;
}
Ниже, под «копи-паст», конфигурация фильтров конечного варианта защиты (были уменьшены пороги пропускной способности трафика NTP и ICMP, причины снижения порогов подробно описаны в разделе тестирования). Настраиваем фильтры ipv4:
IPv4 filter
Аналогичный фильтр для ipv6:
IPv6 filter
Далее необходимо применить фильтры на служебный интерфейс lo0.0. В системе JunOS этот интерфейс используется для передачи данных между PFE и RE. Конфигурация примет следующий вид:
lo0 {
unit 0 {
family inet {
filter {
input-list [ accept-bgp accept-common-services discard-all ];
}
}
family inet6 {
filter {
input-list [ accept-v6-bgp accept-v6-common-services discard-v6-all ];
}
}
}
}
Порядок указания фильтров в input-list интерфейса очень важен. Каждый пакет будет проверяться на валидность проходя по фильтрам указанным в input-list слева направо.
Тестирование фильтров
После применения фильтров, провел ряд тестов на том же стенде. После каждого теста выполнялась очистка счетчиков firewall. Нормальная (без атаки) нагрузка на роутере видна на графиках в 11:06 — 11:08. График pps за весь период тестов:
График CPU за весь период тестов:
Первым проводился тест флуда icmp c порогом трафика 5Мб/с (на графиках 10:21 — 10:24). По счетчикам фильтра и на графике видно ограничение по трафика по пропускной способности, но даже этого потока было достаточно для повышения нагрузки, поэтому порог был уменьшен до 1Мб/с. Счетчики:
Filter: lo0.0-i
Counters:
Name Bytes Packets
accept-bgp-lo0.0-i 0 0
accept-icmp-lo0.0-i 47225584 1686628
accept-ntp-lo0.0-i 152 2
accept-snmp-lo0.0-i 174681 2306
accept-ssh-lo0.0-i 38952 702
accept-traceroute-icmp-lo0.0-i 0 0
accept-traceroute-tcp-lo0.0-i 841 13
accept-traceroute-udp-lo0.0-i 0 0
discard-TTL_1-unknown-lo0.0-i 0 0
discard-icmp-lo0.0-i 0 0
discard-icmp-fragments-lo0.0-i 0 0
discard-ip-options-lo0.0-i 0 0
discard-tcp-lo0.0-i 780 13
discard-udp-lo0.0-i 18743 133
discard-unknown-lo0.0-i 0 0
Policers:
Name Bytes Packets
management-1m-accept-ntp-lo0.0-i 0 0
management-1m-accept-traceroute-icmp-lo0.0-i 0 0
management-1m-accept-traceroute-tcp-lo0.0-i 0 0
management-1m-accept-traceroute-udp-lo0.0-i 0 0
management-5m-accept-icmp-lo0.0-i 933705892 33346639
management-5m-accept-ssh-lo0.0-i 0 0
Повторный тест флуда icmp c порогом трафика 1Мб/с (на графиках 10:24 — 10:27). Нагрузка на RE роутера упала с 19% до 10%, нагрузка на PFE до 30%. Счетчики:
Filter: lo0.0-i
Counters:
Name Bytes Packets
accept-bgp-lo0.0-i 0 0
accept-icmp-lo0.0-i 6461448 230766
accept-ntp-lo0.0-i 0 0
accept-snmp-lo0.0-i 113433 1497
accept-ssh-lo0.0-i 33780 609
accept-traceroute-icmp-lo0.0-i 0 0
accept-traceroute-tcp-lo0.0-i 0 0
accept-traceroute-udp-lo0.0-i 0 0
discard-TTL_1-unknown-lo0.0-i 0 0
discard-icmp-lo0.0-i 0 0
discard-icmp-fragments-lo0.0-i 0 0
discard-ip-options-lo0.0-i 0 0
discard-tcp-lo0.0-i 360 6
discard-udp-lo0.0-i 12394 85
discard-unknown-lo0.0-i 0 0
Policers:
Name Bytes Packets
management-1m-accept-icmp-lo0.0-i 665335496 23761982
management-1m-accept-ntp-lo0.0-i 0 0
management-1m-accept-traceroute-icmp-lo0.0-i 0 0
management-1m-accept-traceroute-tcp-lo0.0-i 0 0
management-1m-accept-traceroute-udp-lo0.0-i 0 0
management-5m-accept-ssh-lo0.0-i 0 0
Следующим был проведен тест флуда на порт BGP роутера с постороннего (не включеного в конфиг) ip адреса (на графиках 10:29 — 10:36). Как видно из счетчиков, весь флуд осел на discard-tcp фильтре RE и лишь увеличил нагрузку на PFE. Нагрузка на RE не изменилась. Счетчики:
Filter: lo0.0-i
Counters:
Name Bytes Packets
accept-bgp-lo0.0-i 824 26
accept-icmp-lo0.0-i 0 0
accept-ntp-lo0.0-i 0 0
accept-snmp-lo0.0-i 560615 7401
accept-ssh-lo0.0-i 33972 585
accept-traceroute-icmp-lo0.0-i 0 0
accept-traceroute-tcp-lo0.0-i 1088 18
accept-traceroute-udp-lo0.0-i 0 0
discard-TTL_1-unknown-lo0.0-i 0 0
discard-icmp-lo0.0-i 0 0
discard-icmp-fragments-lo0.0-i 0 0
discard-ip-options-lo0.0-i 0 0
discard-tcp-lo0.0-i 12250785600 306269640
discard-udp-lo0.0-i 63533 441
discard-unknown-lo0.0-i 0 0
Policers:
Name Bytes Packets
management-1m-accept-icmp-lo0.0-i 0 0
management-1m-accept-ntp-lo0.0-i 0 0
management-1m-accept-traceroute-icmp-lo0.0-i 0 0
management-1m-accept-traceroute-tcp-lo0.0-i 0 0
management-1m-accept-traceroute-udp-lo0.0-i 0 0
management-5m-accept-ssh-lo0.0-i 0 0
сессия не падает:
user@MX80# run show bgp summary
Groups: 1 Peers: 1 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0
2 1 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
9.4.8.2 4567 21 22 0 76 8:49 1/2/2/0 0/0/0/0
Четвертым был проведен тест флуда (на графиках 10:41 — 10:46) UDP на порт NTP (в настройках фильтра взаимодействие по этому порту ограничивается серверами указанными в конфиге роутера). По графику, нагрузка поднимается только на PFE роутера до 28%. Счетчики:
Filter: lo0.0-i
Counters:
Name Bytes Packets
accept-bgp-lo0.0-i 0 0
accept-icmp-lo0.0-i 0 0
accept-ntp-lo0.0-i 0 0
accept-snmp-lo0.0-i 329059 4344
accept-ssh-lo0.0-i 22000 388
accept-traceroute-icmp-lo0.0-i 0 0
accept-traceroute-tcp-lo0.0-i 615 10
accept-traceroute-udp-lo0.0-i 0 0
discard-TTL_1-unknown-lo0.0-i 0 0
discard-icmp-lo0.0-i 0 0
discard-icmp-fragments-lo0.0-i 0 0
discard-ip-options-lo0.0-i 0 0
discard-tcp-lo0.0-i 0 0
discard-udp-lo0.0-i 1938171670 69219329
discard-unknown-lo0.0-i 0 0
Policers:
Name Bytes Packets
management-1m-accept-icmp-lo0.0-i 0 0
management-1m-accept-ntp-lo0.0-i 0 0
management-1m-accept-traceroute-icmp-lo0.0-i 0 0
management-1m-accept-traceroute-tcp-lo0.0-i 0 0
management-1m-accept-traceroute-udp-lo0.0-i 0 0
management-5m-accept-ssh-lo0.0-i 0 0
Пятым был проведен тест флуда (на графиках 10:41 — 11:04) UDP на порт NTP с IP spoofing. Нагрузка на RE увеличилась на 12%, нагрузка на PFE увеличилась до 22%. По счетчикам видно, что флуд упирается в порог 1Мб/с, но этого достаточно для повышения нагрузки на RE. Порог трафика в итоге был уменьшен до 512Кб/с. Счетчики:
Filter: lo0.0-i
Counters:
Name Bytes Packets
accept-bgp-lo0.0-i 0 0
accept-icmp-lo0.0-i 0 0
accept-ntp-lo0.0-i 34796804 1242743
accept-snmp-lo0.0-i 630617 8324
accept-ssh-lo0.0-i 20568 366
accept-traceroute-icmp-lo0.0-i 0 0
accept-traceroute-tcp-lo0.0-i 1159 19
accept-traceroute-udp-lo0.0-i 0 0
discard-TTL_1-unknown-lo0.0-i 0 0
discard-icmp-lo0.0-i 0 0
discard-icmp-fragments-lo0.0-i 0 0
discard-ip-options-lo0.0-i 0 0
discard-tcp-lo0.0-i 0 0
discard-udp-lo0.0-i 53365 409
discard-unknown-lo0.0-i 0 0
Policers:
Name Bytes Packets
management-1m-accept-icmp-lo0.0-i 0 0
management-1m-accept-ntp-lo0.0-i 3717958468 132784231
management-1m-accept-traceroute-icmp-lo0.0-i 0 0
management-1m-accept-traceroute-tcp-lo0.0-i 0 0
management-1m-accept-traceroute-udp-lo0.0-i 0 0
management-5m-accept-ssh-lo0.0-i 0 0
Повторный тест флуда (на графике ниже 11:29 — 11:34) UDP на порт NTP с IP spoofing, но с порогом трафика 512Кб/с. График нагрузки:
Счетчики:
Filter: lo0.0-i
Counters:
Name Bytes Packets
accept-bgp-lo0.0-i 0 0
accept-icmp-lo0.0-i 0 0
accept-ntp-lo0.0-i 21066260 752363
accept-snmp-lo0.0-i 744161 9823
accept-ssh-lo0.0-i 19772 347
accept-traceroute-icmp-lo0.0-i 0 0
accept-traceroute-tcp-lo0.0-i 1353 22
accept-traceroute-udp-lo0.0-i 0 0
discard-TTL_1-unknown-lo0.0-i 0 0
discard-icmp-lo0.0-i 0 0
discard-icmp-fragments-lo0.0-i 0 0
discard-ip-options-lo0.0-i 0 0
discard-tcp-lo0.0-i 0 0
discard-udp-lo0.0-i 82745 602
discard-unknown-lo0.0-i 0 0
Policers:
Name Bytes Packets
management-1m-accept-icmp-lo0.0-i 0 0
management-1m-accept-traceroute-icmp-lo0.0-i 0 0
management-1m-accept-traceroute-tcp-lo0.0-i 0 0
management-1m-accept-traceroute-udp-lo0.0-i 0 0
management-512k-accept-ntp-lo0.0-i 4197080384 149895728
management-5m-accept-ssh-lo0.0-i 0 0
Заключение
В итоге всех проведенных тестов удалось получить, устойчивую к DDOS атакам, конфигурацию фильтров трафика RE. В настоящий момент эта конфигурация уже применена на боевом роутере и проблем не выявлено. По счетчикам с боевого MX80:
Filter: lo0.0-i
Counters:
Name Bytes Packets
accept-v6-bgp-lo0.0-i 31091878 176809
accept-v6-icmp-lo0.0-i 1831144 26705
accept-v6-ntp-lo0.0-i 0 0
accept-v6-traceroute-icmp-lo0.0-i 0 0
accept-v6-traceroute-tcp-lo0.0-i 48488 684
accept-v6-traceroute-udp-lo0.0-i 0 0
discard-v6-icmp-lo0.0-i 0 0
discard-v6-tcp-lo0.0-i 0 0
discard-v6-udp-lo0.0-i 0 0
discard-v6-unknown-lo0.0-i 0 0
Policers:
Name Bytes Packets
management-1m-accept-v6-icmp-lo0.0-i 0 0
management-1m-accept-v6-traceroute-icmp-lo0.0-i 0 0
management-1m-accept-v6-traceroute-tcp-lo0.0-i 0 0
management-1m-accept-v6-traceroute-udp-lo0.0-i 0 0
management-512k-accept-v6-ntp-lo0.0-i 0 0Filter: lo0.0-i
Counters:
Name Bytes Packets
accept-bgp-lo0.0-i 135948400 698272
accept-dns-lo0.0-i 374 3
accept-icmp-lo0.0-i 121304849 1437305
accept-ntp-lo0.0-i 87780 1155
accept-snmp-lo0.0-i 1265470648 12094967
accept-ssh-lo0.0-i 2550011 30897
accept-tacacs-lo0.0-i 702450 11657
accept-traceroute-icmp-lo0.0-i 28824 636
accept-traceroute-tcp-lo0.0-i 75378 1361
accept-traceroute-udp-lo0.0-i 47328 1479
discard-TTL_1-unknown-lo0.0-i 27790 798
discard-icmp-lo0.0-i 26400 472
discard-icmp-fragments-lo0.0-i 0 0
discard-ip-options-lo0.0-i 35680 1115
discard-tcp-lo0.0-i 73399674 1572144
discard-udp-lo0.0-i 126386306 694603
discard-unknown-lo0.0-i 0 0
Policers:
Name Bytes Packets
management-1m-accept-dns-lo0.0-i 0 0
management-1m-accept-icmp-lo0.0-i 38012 731
management-1m-accept-tacacs-lo0.0-i 0 0
management-1m-accept-traceroute-icmp-lo0.0-i 0 0
management-1m-accept-traceroute-tcp-lo0.0-i 0 0
management-1m-accept-traceroute-udp-lo0.0-i 0 0
management-512k-accept-ntp-lo0.0-i 0 0
management-5m-accept-ssh-lo0.0-i 0 0
видно какое количество “левого” трафика оседает на фильтре discard.
Буду рад ответить на все вопросы в комментариях.