Strony

Juniper SRX Screen Test

Przeprowadziłem drobne testy funkcjonalności "screen" na firewallach SRX. Wykorzystałem do tego celu dobrze znane narzędzie hping (udp flood) oraz mniej znane t50 (tcp syn flood). Oczywiście hping potrafi wykonać syn flood jednak warto zapoznać się z t50, które oferuje nam sporo więcej gotowych metod "stress testów".
# hping00 --udp -p 1000000 --destport 10000 --flood 10.10.10.1

# ./t50 10.10.10.1 --flood -S --turbo
entering in flood mode...
activating turbo...
hit CTRL+C to break.
T50 5.4.0 successfully launched on Apr 10th 2012 16:09:08
W przypadku następujących ustawień opcji screen:
root@test>show security screen ids-option test 

Name                                         Value
  UDP flood threshold                        10000      
  TCP port scan threshold                    1000000    
  TCP SYN flood attack threshold             1500       
  TCP SYN flood alarm threshold              512        
  TCP SYN flood source threshold             200        
  TCP SYN flood destination threshold        10000      
  TCP SYN flood timeout    
Tak wygląda przykładowa reakcja SRXa (w przypadku SYN flood źródłowy adres IP jest przypadkowo wygenerowany). T50 domyślnie używa losowo generowanych źródeł ataku.
Apr 10 14:06:16   RT_IDS: RT_SCREEN_TCP_DST_IP: SYN flood! destination: 10.10.10.1, zone name: untrust, interface name: ge-0/0/0.0, action: drop
Apr 10 14:06:16   RT_IDS: RT_SCREEN_TCP: SYN flood! source: 240.221.180.239:17054, destination: 10.10.10.1:30601, zone name: untrust, interface name: ge-0/0/0.0, acti
on: drop
Poniżej efekt działania widoczny w statystykach:
root@test>show security screen statistics zone untrust

IDS attack type                              Statistics
  UDP flood                                  1932197
  TCP port scan                              1957
  TCP SYN flood                              1968            
Warto wspomnieć, że większość mechanizmów screen na SRXach klasy data center (SRX3k,5k) wykonywana jest na kartach NPC. Wczesne wykrywanie prób skanowania, floodu itp. odciąża karty SPC jeszcze przed etapem tworzenie sesji. Warto więc korzystać ze wszystkich mechanizmów typu screen, filtry (stateless) nie tylko w celu zwiększenia bezpieczeństwa, ale też do poprawy wydajności całego rozwiązania.

Brak komentarzy:

Prześlij komentarz