На ASA есть технология защиты от SYN Flood. Конфигурируется порог, после которого ASA начинает перехватывать сессии и считать хэш сессий.

Если сессия приходит от нормально пользователя, а не хакера, то далее АСА сама открывает сессию на сервер (three-way handshake). При этом возникает разность initial sequence number, высчитанный АСой и сгенерированный сервером. АСА эту дельту высчитывает и при работе сервера с клиентом вычитает эту дельту из ACK.

Это присказка. А теперь сказка: как будет работать АСА при такой настройке

static (i,o) tcp 1.1.1.1 80 10.1.1.10 80 tcp 0 25 norandomseq

естественно говорим про случай с 26ым embryonicом ? ( ибо макс сейчас у вас 25, а intercept начинает работать только после перешагивания за данный парог ) ?

Ясен перец

nikita@nikitaDeb:~$ cat asa
10.1.1.2 инициатор, 10.1.1.3 - нат на pixe, 10.0.37.15 - сервер.

NUMERO UNO
2ый коннект ( те уже зашли за предел max embryonic )
PIX(config)# sh run | grep static
static (TRUSTED_LAN,UNTRUSTED_LAN) tcp 10.1.1.3 telnet 10.0.37.15 telnet netmask 255.255.255.255 tcp 0 1 norandomseq

Получаем что random seq ставиться только от респондера к инициатору ( несмотря на то, что стоит norandomseq )

capture со стороны инициатора на pix

58 packets captured
1: 13:04:44.726021 10.1.1.2.40297 > 10.1.1.3.23: S 3718448162:3718448162(0) win 4128 <mss 1460>
2: 13:04:44.726219 10.1.1.3.23 > 10.1.1.2.40297: S 1687709656:1687709656(0) ack 3718448163 win 0 <mss 536>
3: 13:04:44.736793 10.1.1.2.40297 > 10.1.1.3.23: . ack 1687709657 win 4128
4: 13:04:44.747703 10.1.1.3.23 > 10.1.1.2.40297: . ack 3718448163 win 4128
5: 13:04:44.756491 10.1.1.3.23 > 10.1.1.2.40297: P 1687709657:1687709669(12) ack 3718448163 win 4128
6: 13:04:44.766134 10.1.1.3.23 > 10.1.1.2.40297: P 1687709669:1687709711(42) ack 3718448163 win 4128
7: 13:04:44.776784 10.1.1.2.40297 > 10.1.1.3.23: . 3718448163:3718448164(1) ack 1687709669 win 4116
8: 13:04:44.786565 10.1.1.2.40297 > 10.1.1.3.23: . ack 1687709711 win 4074
9: 13:04:44.796299 10.1.1.2.40297 > 10.1.1.3.23: P 3718448164:3718448172(8) ack 1687709711 win 4074
10: 13:04:44.806064 10.1.1.2.40297 > 10.1.1.3.23: . ack 1687709711 win 4128
11: 13:04:44.806247 10.1.1.3.23 > 10.1.1.2.40297: P 1687709711:1687709714(3) ack 3718448172 win 4119


capture от pixa на сервер-респондер
57 packets captured
1: 13:04:44.737876 10.1.1.2.40297 > 10.0.37.15.23: S 3718448162:3718448162(0) win 4128 <mss 1380>
2: 13:04:44.746665 10.0.37.15.23 > 10.1.1.2.40297: S 1863805981:1863805981(0) ack 3718448163 win 4128 <mss 536>
3: 13:04:44.747260 10.1.1.2.40297 > 10.0.37.15.23: . ack 1863805982 win 4128
4: 13:04:44.756339 10.0.37.15.23 > 10.1.1.2.40297: P 1863805982:1863805994(12) ack 3718448163 win 4128
5: 13:04:44.766073 10.0.37.15.23 > 10.1.1.2.40297: P 1863805994:1863806036(42) ack 3718448163 win 4128
6: 13:04:44.776891 10.1.1.2.40297 > 10.0.37.15.23: . 3718448163:3718448164(1) ack 1863805994 win 4116
7: 13:04:44.786610 10.1.1.2.40297 > 10.0.37.15.23: . ack 1863806036 win 4074
8: 13:04:44.796360 10.1.1.2.40297 > 10.0.37.15.23: P 3718448164:3718448172(8) ack 1863806036 win 4074
9: 13:04:44.806125 10.1.1.2.40297 > 10.0.37.15.23: . ack 1863806036 win 4128
10: 13:04:44.806186 10.0.37.15.23 > 10.1.1.2.40297: P 1863806036:1863806039(3) ack 3718448172 win 4119
11: 13:04:44.815997 10.1.1.2.40297 > 10.0.37.15.23: P 3718448172:3718448175(3) ack 1863806036 win 4128
12: 13:04:44.816074 10.0.37.15.23 > 10.1.1.2.40297: P 1863806039:1863806045(6) ack 3718448172 win 4119
13: 13:04:44.826647 10.1.1.2.40297 > 10.0.37.15.23: P 3718448175:3718448178(3) ack 1863806036 win 4128
14: 13:04:44.836428 10.1.1.2.40297 > 10.0.37.15.23: P 3718448178:3718448187(9) ack 1863806036 win 4128
15: 13:04:44.836489 10.0.37.15.23 > 10.1.1.2.40297: P 1863806045:1863806048(3) ack 3718448178 win 4113



NUMERO DUOS:
нат все еще с norandomseq, но это только первый коннект ( соот intercept не работает )
видем что нигде seq не меняются ( те работает, как ожидаемо )
=================================================
capture от инициатора на пикс
30 packets captured
1: 13:11:50.962535 10.1.1.2.58320 > 10.1.1.3.23: S 2644409861:2644409861(0) win 4128 <mss 1460>
2: 13:11:50.972346 10.1.1.3.23 > 10.1.1.2.58320: S 1978310467:1978310467(0) ack 2644409862 win 4128 <mss 536>
3: 13:11:50.982981 10.1.1.2.58320 > 10.1.1.3.23: . ack 1978310468 win 4128
4: 13:11:50.992746 10.1.1.2.58320 > 10.1.1.3.23: P 2644409862:2644409871(9) ack 1978310468 win 4128
5: 13:11:51.002624 10.1.1.2.58320 > 10.1.1.3.23: . ack 1978310468 win 4128
6: 13:11:51.002776 10.1.1.3.23 > 10.1.1.2.58320: P 1978310468:1978310480(12) ack 2644409862 win 4128
7: 13:11:51.012420 10.1.1.3.23 > 10.1.1.2.58320: P 1978310480:1978310522(42) ack 2644409862 win 4128
8: 13:11:51.023054 10.1.1.2.58320 > 10.1.1.3.23: P 2644409871:2644409874(3) ack 1978310522 win 4074
9: 13:11:51.023207 10.1.1.3.23 > 10.1.1.2.58320: P 1978310522:1978310525(3) ack 2644409871 win 4119
10: 13:11:51.032835 10.1.1.2.58320 > 10.1.1.3.23: P 2644409874:2644409877(3) ack 1978310522 win 4074
11: 13:11:51.032972 10.1.1.3.23 > 10.1.1.2.58320: P 1978310525:1978310531(6) ack 2644409871 win 4119
12: 13:11:51.042600 10.1.1.2.58320 > 10.1.1.3.23: P 2644409877:2644409886(9) ack 1978310522 win 4074
13: 13:11:51.042752 10.1.1.3.23 > 10.1.1.2.58320: P 1978310531:1978310534(3) ack 2644409877 win 4113
14: 13:11:51.233065 10.1.1.2.58320 > 10.1.1.3.23: . ack 1978310534 win 4062
15: 13:11:51.252641 10.1.1.3.23 > 10.1.1.2.58320: . ack 2644409886 win 4104

capture от пикс к серверу-респондеру
PIX# show capture TEST1
30 packets captured
1: 13:11:50.963023 10.1.1.2.58320 > 10.0.37.15.23: S 2644409861:2644409861(0) win 4128 <mss 1380>
2: 13:11:50.972270 10.0.37.15.23 > 10.1.1.2.58320: S 1978310467:1978310467(0) ack 2644409862 win 4128 <mss 536>
3: 13:11:50.983042 10.1.1.2.58320 > 10.0.37.15.23: . ack 1978310468 win 4128
4: 13:11:50.992792 10.1.1.2.58320 > 10.0.37.15.23: P 2644409862:2644409871(9) ack 1978310468 win 4128
5: 13:11:51.002670 10.1.1.2.58320 > 10.0.37.15.23: . ack 1978310468 win 4128
6: 13:11:51.002731 10.0.37.15.23 > 10.1.1.2.58320: P 1978310468:1978310480(12) ack 2644409862 win 4128
7: 13:11:51.012374 10.0.37.15.23 > 10.1.1.2.58320: P 1978310480:1978310522(42) ack 2644409862 win 4128
8: 13:11:51.023100 10.1.1.2.58320 > 10.0.37.15.23: P 2644409871:2644409874(3) ack 1978310522 win 4074
9: 13:11:51.023161 10.0.37.15.23 > 10.1.1.2.58320: P 1978310522:1978310525(3) ack 2644409871 win 4119
10: 13:11:51.032880 10.1.1.2.58320 > 10.0.37.15.23: P 2644409874:2644409877(3) ack 1978310522 win 4074
11: 13:11:51.032942 10.0.37.15.23 > 10.1.1.2.58320: P 1978310525:1978310531(6) ack 2644409871 win 4119
12: 13:11:51.042646 10.1.1.2.58320 > 10.0.37.15.23: P 2644409877:2644409886(9) ack 1978310522 win 4074
13: 13:11:51.042707 10.0.37.15.23 > 10.1.1.2.58320: P 1978310531:1978310534(3) ack 2644409877 win 4113
14: 13:11:51.233111 10.1.1.2.58320 > 10.0.37.15.23: . ack 1978310534 win 4062
15: 13:11:51.252580 10.0.37.15.23 > 10.1.1.2.58320: . ack 2644409886 win 4104
16: 13:11:53.563203 10.1.1.2.58320 > 10.0.37.15.23: P 2644409886:2644409887(1) ack 1978310534 win 4062




NUMERO TRES: убираем norandomseq
===========================================

получаем, что pix ставить random seq и инициатору, и респондеру.

capture от инициатору к пиксу
PIX# show capture TEST
19 packets captured
1: 13:13:30.444984 10.1.1.2.50078 > 10.1.1.3.23: S 1841617742:1841617742(0) win 4128 <mss 1460>
2: 13:13:30.454306 10.1.1.3.23 > 10.1.1.2.50078: S 2934285019:2934285019(0) ack 1841617743 win 4128 <mss 536>
3: 13:13:30.463995 10.1.1.2.50078 > 10.1.1.3.23: . ack 2934285020 win 4128
4: 13:13:30.473730 10.1.1.2.50078 > 10.1.1.3.23: P 1841617743:1841617752(9) ack 2934285020 win 4128
5: 13:13:30.473882 10.1.1.3.23 > 10.1.1.2.50078: P 2934285020:2934285032(12) ack 1841617743 win 4128
6: 13:13:30.484502 10.1.1.2.50078 > 10.1.1.3.23: . ack 2934285020 win 4128
7: 13:13:30.484639 10.1.1.3.23 > 10.1.1.2.50078: P 2934285032:2934285074(42) ack 1841617743 win 4128
8: 13:13:30.494237 10.1.1.2.50078 > 10.1.1.3.23: P 1841617752:1841617755(3) ack 2934285032 win 4116
9: 13:13:30.494389 10.1.1.3.23 > 10.1.1.2.50078: P 2934285074:2934285077(3) ack 1841617752 win 4119
10: 13:13:30.504139 10.1.1.2.50078 > 10.1.1.3.23: P 1841617755:1841617758(3) ack 2934285032 win 4116
11: 13:13:30.504292 10.1.1.3.23 > 10.1.1.2.50078: P 2934285077:2934285083(6) ack 1841617752 win 4119
12: 13:13:30.513797 10.1.1.2.50078 > 10.1.1.3.23: P 1841617758:1841617767(9) ack 2934285032 win 4116
13: 13:13:30.513950 10.1.1.3.23 > 10.1.1.2.50078: P 2934285083:2934285086(3) ack 1841617758 win 4113
14: 13:13:30.684672 10.1.1.2.50078 > 10.1.1.3.23: . ack 2934285086 win 4062
15: 13:13:30.744285 10.1.1.3.23 > 10.1.1.2.50078: . ack 1841617767 win 4104
16: 13:13:33.724709 10.1.1.2.50078 > 10.1.1.3.23: P 1841617767:1841617768(1) ack 2934285086 win 4062
17: 13:13:33.734504 10.1.1.3.23 > 10.1.1.2.50078: P 2934285086:2934285087(1) ack 1841617768 win 4103
18: 13:13:33.868393 10.1.1.2.50078 > 10.1.1.3.23: . ack 2934285087 win 4061
19: 13:13:34.234866 10.1.1.2.50078 > 10.1.1.3.23: . ack 2934285087 win 4128
19 packets shown

capture от pixa к серверу-респондеру
PIX# show capture TEST1
19 packets captured
1: 13:13:30.445548 10.1.1.2.50078 > 10.0.37.15.23: S 2514007823:2514007823(0) win 4128 <mss 1380>
2: 13:13:30.454230 10.0.37.15.23 > 10.1.1.2.50078: S 2570457973:2570457973(0) ack 2514007824 win 4128 <mss 536>
3: 13:13:30.464072 10.1.1.2.50078 > 10.0.37.15.23: . ack 2570457974 win 4128
4: 13:13:30.473776 10.1.1.2.50078 > 10.0.37.15.23: P 2514007824:2514007833(9) ack 2570457974 win 4128
5: 13:13:30.473837 10.0.37.15.23 > 10.1.1.2.50078: P 2570457974:2570457986(12) ack 2514007824 win 4128
6: 13:13:30.484533 10.1.1.2.50078 > 10.0.37.15.23: . ack 2570457974 win 4128
7: 13:13:30.484594 10.0.37.15.23 > 10.1.1.2.50078: P 2570457986:2570458028(42) ack 2514007824 win 4128
8: 13:13:30.494282 10.1.1.2.50078 > 10.0.37.15.23: P 2514007833:2514007836(3) ack 2570457986 win 4116
9: 13:13:30.494343 10.0.37.15.23 > 10.1.1.2.50078: P 2570458028:2570458031(3) ack 2514007833 win 4119
10: 13:13:30.504185 10.1.1.2.50078 > 10.0.37.15.23: P 2514007836:2514007839(3) ack 2570457986 win 4116
11: 13:13:30.504246 10.0.37.15.23 > 10.1.1.2.50078: P 2570458031:2570458037(6) ack 2514007833 win 4119
12: 13:13:30.513843 10.1.1.2.50078 > 10.0.37.15.23: P 2514007839:2514007848(9) ack 2570457986 win 4116
13: 13:13:30.513904 10.0.37.15.23 > 10.1.1.2.50078: P 2570458037:2570458040(3) ack 2514007839 win 4113
14: 13:13:30.684733 10.1.1.2.50078 > 10.0.37.15.23: . ack 2570458040 win 4062
15: 13:13:30.744239 10.0.37.15.23 > 10.1.1.2.50078: . ack 2514007848 win 4104
16: 13:13:33.724816 10.1.1.2.50078 > 10.0.37.15.23: P 2514007848:2514007849(1) ack 2570458040 win 4062
17: 13:13:33.734443 10.0.37.15.23 > 10.1.1.2.50078: P 2570458040:2570458041(1) ack 2514007849 win 4103
18: 13:13:33.868515 10.1.1.2.50078 > 10.0.37.15.23: . ack 2570458041 win 4061
19: 13:13:34.234973 10.1.1.2.50078 > 10.0.37.15.23: . ack 2570458041 win 4128
19 packets shown
PIX#




Вопрос: где нить описанно поведение PIX/ASA в первом случае ( когда embryonic > max ) и мы получаем односторонний random seq ?

Вооот. Нигде не написано! Вообще про односторонний randomseq ни звука!

В такой конфигурации могут смешные штуки получаться для тех протоколов, где рандомайзить нельзя никак (BGP и другие tcp приложения с аутентификацией)...

когда искал про norandomseq наткнулся на
http://www.cisco.com/web/about/ac123/ac ... tacks.html
мне то, что под figure 7 понравилось.
spoofed ack можно сделать ( так как мы видели уже syn от инициатора; аутентификация tcp сессии на этапе 3-w handshake еще нет ) с нормальными syn ( те такими же , какие приходят в реальном ack ), а чтоб не было рассинхронизации после этого, если приходит настоящий ack -> мы его не пересылаем респондеру.

Вроде данный вариант должен решить проблемы c syn flood в случаях когда нельзя random seq делать. Хотя мож я чего не учел :)

Да, забавная картинка.

Вот только не понятно, чем принципиально она будет отличаться от вообще отсутствия СИНКуки? Ведь на сервере появится куча полуоткрытых сессий, правда заспуфленных от фаервола.

Я думаю в таком случае все равно ж остается возможность явно ограничивать максимальное кол-во embryonic на файрвалле. Так же явно задаем таймаут на АСК от инициатора вне зависимости от настроек сервера ( за счет RST ) + может убивать рандомно ( или самые старые ) embryonic коннекты, если появились новые а лимит исчерпан.