[Foxeevna]

Всем доброго дня!

Вопрос в следующем имеется Cisco ASR-1002 ESP5

как на ней зарезать SYN spoofed пакеты

 

Атака к примеру генерится прогой hping3 и выдает с компа снаружи 200000pps и каждый син пакет идет с нового ip адреса. и по факту кот считает этот траифк валидным и пропускает через себя.

есть ли методы борьбы с SYN spoofed атакой посредством SCE. Если кто знает подскажите что включить.

[visir]

uRPF?

[Foxeevna]

да вот прям счас досят этим долбаным hping3

генерят 200000 ппс на 80й порт

 

асрке пофик не обращает внимания.

за асркой стоит SCE2020 но она син пакеты пропускает ибо 1 с каждого нового ипа.

вариант остановить только на ASR1002

трафика то не много но его хватает чтоб свалить третий и последний шлюз на микротике еслине ставлю на атакуемый ип дроп пакетов.

http://46.149.46.129/graphs/iface/Internet/

 

вот и есть задача тормознуть SYN на ASR но вопрос как

[visir]

Столько слов, но так и непонятно: сервак-источник находится в вашей сети и Вы хотите зафильтровать флуд уходящий с него во вне, или же Вас из вне долбят?

[Foxeevna]

Столько слов, но так и непонятно: сервак-источник находится в вашей сети и Вы хотите зафильтровать флуд уходящий с него во вне, или же Вас из вне долбят?

 

меня из вне долбят.

[fomka31ru]

напиши фильтр:

для протокола tcp и tcp-flag (syn & !ack) | fin | rst)

ограничить полосу например до 10 метров.

 

Как минимум часть флуда зарежешь

Edited August 20, 2012 by fomka31ru

[Foxeevna]

напиши фильтр:

для протокола tcp и tcp-flag (syn & !ack) | fin | rst)

ограничить полосу например до 10 метров.

 

Как минимум часть флуда зарежешь

 

я полагаю это приведет и к неустановки сессии с нормальными клиентами те которые на сайт попасть хотят.

в этом то вся и фишка я ищу вариант на ASRке проверять и адреса ли источника пришел запрос или это подстава.

но пока не соображаю куда копать.

в данный момент каждый запрос приходит с нового ипа. и таких запросов около 200000ппс

резать что либо не вариант. они на этой зарезке просто не дадут обычным клиентам цепляться син запросом к вебсерверу.

 

вот и задачка. включить (если функция конечно есть) какую нить проверку адреса источника пакета с фактическим.

[nnm]

Там вроде TCP SYN Cookie есть. Как раз для таких случаев. Правда не понятно работает или нет :)

[Foxeevna]

на SCE2020 это выглядит так

 

 

SCE2000#sh interface LineCard 0 attack-filter current-attacks

 

---|---------------|-----------|------------|----------|------|------|------

#|Source IP -> |Side / |Open rate / |Handled |Action|HW- |force-

| Dest IP|Protocol |Susp. rate | flows / | |filter|filter

| | | |Duration | | |

---|---------------|-----------|------------|----------|------|------|------

1|* |Network | N/A| N/A|Report|Yes |No

| 46.149.46.187|TCP:80 | N/A| 107077| | |

---|---------------|-----------|------------|----------|------|------|------

2|* |Network | N/A| N/A|Report|Yes |No

| 46.149.46.187|TCP | N/A| 107077| | |

---|---------------|-----------|------------|----------|------|------|------

 

Total 2 attacks listed.

 

* Duration is displayed in seconds.

* Open / DDos-suspected flows show the current rate (flows per second).

 

адрес источника не виден просто тупо "*"

[Foxeevna]

Там вроде TCP SYN Cookie есть. Как раз для таких случаев. Правда не понятно работает или нет :)

 

включила это. не помогает.

[fomka31ru]

как на ней зарезать SYN spoofed пакеты

 

напиши фильтр:

для протокола tcp и tcp-flag (syn & !ack) | fin | rst)

ограничить полосу например до 10 метров.

 

Как минимум часть флуда зарежешь

 

резать что либо не вариант.

 

Определись...

 

вот и задачка. включить (если функция конечно есть) какую нить проверку адреса источника пакета с фактическим.

 

Вот это ваще не понятно, с каким фактическим проверка адреса?

[nnm]

Покажите

show policy-firewall stats vrf global

[Foxeevna]

Покажите

show policy-firewall stats vrf global

 

 

 

asr#show policy-firewall stats vrf global

Global table statistics

Total Session Count: 0

Total Exceed Count: 0

TCP Half Open Count: 0

TCP Syn Packet Exceed Count: 0

 

 

я пытаюсь ковырять примерно в эту сторону. вот статейка. но это к сину походу применения не имеет.

http://techoover.blogspot.com/2007/11/unicast-reverse-path-forwarding.html

хотя это примерно то что надо

[nnm]

asr#show policy-firewall stats vrf global

Global table statistics

Total Session Count: 0

Total Exceed Count: 0

TCP Half Open Count: 0

TCP Syn Packet Exceed Count: 0

Судя по тому, что везде нули, что-то не так с конфигурацией firewall/SYN cookie.

 

я пытаюсь ковырять примерно в эту сторону. вот статейка. но это к сину походу применения не имеет.

http://techoover.blogspot.com/2007/11/unicast-reverse-path-forwarding.html

хотя это примерно то что надо

 

URPF Вам скорее всего не поможет. URPF это механизм, который оператор включает на СВОИХ линках доступа чтобы его клиенты не могли подделывать IP-адреса и DDOS-ить остальных. Для атакуемого оператора он не очень полезен.

Кроме того, есть вероятность, что долбят Вас с ботнета и все Src-адреса, которые к Вам прилетают легитимны, маршрутизируемы и т.п...

[Foxeevna]

asr#show policy-firewall stats vrf global

Global table statistics

Total Session Count: 0

Total Exceed Count: 0

TCP Half Open Count: 0

TCP Syn Packet Exceed Count: 0

Судя по тому, что везде нули, что-то не так с конфигурацией firewall/SYN cookie.

 

я пытаюсь ковырять примерно в эту сторону. вот статейка. но это к сину походу применения не имеет.

http://techoover.blogspot.com/2007/11/unicast-reverse-path-forwarding.html

хотя это примерно то что надо

 

URPF Вам скорее всего не поможет. URPF это механизм, который оператор включает на СВОИХ линках доступа чтобы его клиенты не могли подделывать IP-адреса и DDOS-ить остальных. Для атакуемого оператора он не очень полезен.

Кроме того, есть вероятность, что долбят Вас с ботнета и все Src-адреса, которые к Вам прилетают легитимны, маршрутизируемы и т.п...

 

нет долбят с одного компа. но ип его фик узнаешь ибо подставляется куча фейков.

и понять это просто ипы чуть ли не по списку идут...

Edited August 20, 2012 by Foxeevna

[Foxeevna]

Вновь поднимаю тему...

Гуру прошу помощи...

Ситуация такая:

 

#sh int

GigabitEthernet0/0/0 is up, line protocol is up

Hardware is 4XGE-BUILT-IN, address is 1cdf.0f55.de00 (bia 1cdf.0f55.de00)

Description: UPLINK

Internet address is x.x.x.x/30

MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,

reliability 255/255, txload 1/255, rxload 51/255

Encapsulation ARPA, loopback not set

Keepalive not supported

Full Duplex, 1000Mbps, link type is auto, media type is SX

output flow-control is off, input flow-control is off

ARP type: ARPA, ARP Timeout 04:00:00

Last input 00:00:00, output 00:09:18, output hang never

Last clearing of "show interface" counters never

Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: fifo

Output queue: 0/40 (size/max)

5 minute input rate 203849000 bits/sec, 424628 packets/sec

5 minute output rate 1923000 bits/sec, 3961 packets/sec

1582935835 packets input, 94983859380 bytes, 0 no buffer

Received 11863 broadcasts (0 IP multicasts)

0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

0 watchdog, 10617 multicast, 0 pause input

17893322 packets output, 1091453665 bytes, 0 underruns

0 output errors, 0 collisions, 4 interface resets

0 unknown protocol drops

0 babbles, 0 late collision, 0 deferred

0 lost carrier, 0 no carrier, 0 pause output

0 output buffer failures, 0 output buffers swapped out

GigabitEthernet0/0/1 is up, line protocol is up

Hardware is 4XGE-BUILT-IN, address is 1cdf.0f55.de01 (bia 1cdf.0f55.de01)

Description: xxx

Internet address is x.x.x.x/28

MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,

reliability 255/255, txload 28/255, rxload 1/255

Encapsulation ARPA, loopback not set

Keepalive not supported

Full Duplex, 1000Mbps, link type is auto, media type is SX

output flow-control is off, input flow-control is off

ARP type: ARPA, ARP Timeout 04:00:00

Last input 00:00:00, output 00:00:22, output hang never

Last clearing of "show interface" counters never

Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: fifo

Output queue: 0/40 (size/max)

5 minute input rate 1980000 bits/sec, 3949 packets/sec

5 minute output rate 111938000 bits/sec, 419035 packets/sec

17889307 packets input, 1127272189 bytes, 0 no buffer

Received 8883 broadcasts (0 IP multicasts)

0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

0 watchdog, 7220 multicast, 0 pause input

1121099379 packets output, 60547894199 bytes, 0 underruns

0 output errors, 0 collisions, 4 interface resets

0 unknown protocol drops

0 babbles, 0 late collision, 0 deferred

0 lost carrier, 0 no carrier, 0 pause output

0 output buffer failures, 0 output buffers swapped out

 

 

железка Cisco ASR-1002 ESP5

 

тип атаки syn spoofed пакеты. не повторяющиеся. доп железка перед этой кошкой это SCE2020 с включеным аномали трафик детектором. атаку пропускает ибо 1 син пакет с одного фейк-адреса. они практически не повторяются.

 

кто возьмется настроить на ASR-1002 синкуки, чтоб кошка сама устанвливала соединение на син пакет и если оно валидное пересылала дальше к серверам.

 

PS предлагать какие то лимиты, файрволы с ограничениями и тд смысла НОЛЬ. Повторяю 1 син пакет с одного фейк адреса. Вот только адресов получается примерно 560000 в секунду.

 

с предложениями и ценником писать на icq 21422415

Edited November 1, 2013 by Foxeevna

[denis_vid]

Включите ip verify unicast source reachable-via any и посмотрите помогло или нет

[applx]

http://www.cisco.com/en/US/docs/ios-xml/ios/sec_data_zbf/configuration/xe-3s/asr1000/conf-fw-tcp-syn-cookie.html

[zhenya`]

мусор летит с вполне нормальных внешних адресов?

[Foxeevna]

ip verify unicast source reachable-via any

 

нет не помогло

 

мусор летит с вполне нормальных внешних адресов?

 

конечно с нормальных и как делается эта атака вполне понятно. только вот адрес источника вычислить нельзя.

вывод банить нечего.

 

http://www.cisco.com/en/US/docs/ios-xml/ios/sec_data_zbf/configuration/xe-3s/asr1000/conf-fw-tcp-syn-cookie.html

 

по вашему тут сидят люди которые не умеют пользоваться гуглем?

на запрос Cisco ASR syn cookie прочитано уже 10 страниц гугля.

толку мало и не от того что руки не в том месте.

[denis_vid]

тип атаки syn spoofed пакеты. не повторяющиеся. доп железка перед этой кошкой это SCE2020 с включеным аномали трафик детектором. атаку пропускает ибо 1 син пакет с одного фейк-адреса. они практически не повторяются.

 

Даже не представляю как с внешних интерфейсов может такое валиться на ваш роутер. Что за аплинки?

И выложите конфиг на всякий, может просто син-таймауты слишком долгие, например нат син таймауты?

Edited November 1, 2013 by denis_vid

[Foxeevna]

тип атаки syn spoofed пакеты. не повторяющиеся. доп железка перед этой кошкой это SCE2020 с включеным аномали трафик детектором. атаку пропускает ибо 1 син пакет с одного фейк-адреса. они практически не повторяются.

 

Даже не представляю как с внешних интерфейсов может такое валиться на ваш роутер. Что за аплинки?

И выложите конфиг на всякий, может просто син-таймауты слишком долгие, например нат син таймауты?

 

аплинков у меня 5 разных

на 3 подсети /24 подверженным ддос атакам через бгп принимаем траф тока от одного аплинка.

линки собственно 10гигабит 2 штуки.

сама атака генерится простой прогой которая есть в каждом линухе hping3

просто под это заюзано ддосерами машины 3-4

прогой хоть с айпи гугля можно досить.

но ключ -S дает генерацию спуфед пакетов.

1 пакет с нового ip адреса.

итого адрес источника среди всего этого мусора хрен вычислишь.

и чем мощнее машина и шире канал у досера тем больше он может влить.

но сетевухе на атакуемом сервере тупо падают.

SCE так как видит пролетающие через себя по 1 syn пакету от 500000 разных ip считает их валидными.

 

дальше изза такого количества пакетов начинают медленно дохнуть но не умирать оптические коммутаторы DGS-3526G работают но уже не оч хорошо.

ната нет вообще. простая маршрутизация.

итого: сеть откуда лупят -> ASR1002 ESP10 на которой счас атакуемый ип засунут тупо в null0 чтоб не нагружать железяки -> SCE2020 с аномали трафик детектором -> коммутатор оптический DGS-3612G -> Cisco ASR-1002 ESP5 за которой и сидит атакуемый сервер. циска по настройкам вообще практически пустая для теста решений от этого долбаного ддоса. делать на ней и тестить можно что угодно.

 

есть еще juniper SRX240Н (падает и при половинной мощности такой атаки) в итоге решение внедрять джуник на зарезку остального хлама когда зарежется сам син сверху.

 

а сама атака на сервере выглядит так:

 

 

TenGigabitEthernet0/3/0 is up, line protocol is up

Hardware is SPA-1X10GE-L-V2, address is 7cad.7410.8b30 (bia 7cad.7410.8b30)

MTU 1500 bytes, BW 10000000 Kbit/sec, DLY 10 usec,

reliability 255/255, txload 2/255, rxload 6/255

Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set

Keepalive not supported

Full Duplex, 10000Mbps, link type is force-up, media type is 10GBase-LR

output flow-control is on, input flow-control is on

ARP type: ARPA, ARP Timeout 04:00:00

Last input 00:00:00, output 00:00:36, output hang never

Last clearing of "show interface" counters never

Input queue: 0/375/1752/384 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: fifo

Output queue: 0/40 (size/max)

5 minute input rate 264521000 bits/sec, 416041 packets/sec

5 minute output rate 97207000 bits/sec, 15143 packets/sec

262063354210 packets input, 216878232072627 bytes, 0 no buffer

Received 32440629 broadcasts (0 IP multicasts)

0 runts, 2 giants, 0 throttles

657 input errors, 626 CRC, 29 frame, 0 overrun, 0 ignored

0 watchdog, 16985629 multicast, 0 pause input

378966304448 packets output, 253076508256889 bytes, 0 underruns

0 output errors, 0 collisions, 2 interface resets

0 unknown protocol drops

0 babbles, 0 late collision, 0 deferred

0 lost carrier, 0 no carrier, 0 pause output

0 output buffer failures, 0 output buffers swapped out

 

 

 

 

 

 

IPTraf

┌ TCP Connections (Source Host:Port) ────────────────────────────────────────── Packets ─────────── Bytes ─── Flags ───── Iface ──────┐

│┌126.173.159.246:33273 = 1 46 S--- eth0 │

│└x.x.x.x:80 = 2 88 S-A- eth0 │

│┌114.177.162.246:5301 = 1 46 S--- eth0 │

│└x.x.x.x:80 = 3 132 S-A- eth0 │

│┌4.47.159.246:34535 = 1 46 S--- eth0 │

│└x.x.x.x:80 = 3 132 S-A- eth0 │

│┌218.214.159.246:62909 = 1 46 S--- eth0 │

│└x.x.x.x:80 = 2 88 S-A- eth0 │

│┌32.144.140.246:64059 = 1 46 S--- eth0 │

│└x.x.x.x:80 = 3 132 S-A- eth0 │

│┌173.237.179.250:47766 = 1 46 S--- eth0 │

│└x.x.x.x:80 = 3 132 S-A- eth0 │

│┌16.25.133.246:33675 = 1 46 S--- eth0 │

│└x.x.x.x:80 = 2 88 S-A- eth0 │

│┌42.245.157.246:14893 = 1 46 S--- eth0 │

│└x.x.x.x:80 = 3 132 S-A- eth0 │

│┌152.63.161.246:24083 = 1 46 S--- eth0 │

│└x.x.x.x:80 = 1 44 S-A- eth0 │

│┌46.11.162.246:15753 = 1 46 S--- eth0 │

│└x.x.x.x:80 = 3 132 S-A- eth0 │

│┌193.255.61.65:3360 = 1 46 S--- eth0 │

│└x.x.x.x:80 = 2 88 S-A- eth0 │

│┌2.22.197.246:26149 = 1 46 S--- eth0 │

│└x.x.x.x:80 = 1 44 S-A- eth0 │

│┌74.8.161.246:54925 = 1 46 S--- eth0 │

│└x.x.x.x:80 = 2 88 S-A- eth0 │

│┌80.95.197.246:24139 = 1 46 S--- eth0 │

│└x.x.x.x:80 = 2 88 S-A- eth0 │

│┌178.246.190.246:61301 = 1 46 S--- eth0 │

│└x.x.x.x:80 = 2 88 S-A- eth0 │

│┌122.233.127.246:35741 = 1 46 S--- eth0 │

└ TCP: 560894 entries ─────────────────────────────────────────────────────────────────────────────────────────────────────── Active ─┘

 

 

вот такое блин развлечение

 

причем все софтверные роутеры фряхи с оттюненным ядром и сетевухами Dell Intel VT PRO 1000 (для многоядерных процов) падают через пару секунд.

 

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

 

вот и прошу помощи)

 

 

 

вот пока пишу и еще немного подросли

5 minute input rate 898686000 bits/sec, 515840 packets/sec

5 minute output rate 608459000 bits/sec, 122698 packets/sec

Edited November 1, 2013 by Foxeevna

[applx]

Ne zametil 4tob vu primer iz syn cookie priveli na svoem asr

[DimaM]

Все очень странно и похоже действительно syn cookie никто не настраивал.

Тот же linux с syn cookie держит такую нагрузку легко.

Поставьте перед защищаемым сайтом (и перед всеми вашими дохлыми железяками) сервак с nginx в режиме reverse proxy

и настройте на этом серваке syn cookie. И все, можете курить бамбук.