Blocking nimda probes with a content-layer switch
Lincoln Dale
ltd at interlink.com.au
Wed Sep 19 06:59:14 UTC 2001
At 12:32 AM 19/09/2001 -0400, Joe Abley wrote:
>Has anybody tried to block nimda HTTP GET probes using URL
>pattern matches in a "layer-4-7"[1] switch?
note that this worm uses multiple methods for spreading - email and
HTTP. these methods are only addressing the HTTP side of things:
NBAR (Network Based Application Recognition) in IOS:
existing CodeRed NBAR settings will block the HTTP probes.
see http://www.cisco.com/warp/public/63/nbar_acl_codered.shtml
Cisco Content Engine:
rule enable
rule block url-regex http://.*/cmd\.exe
rule block url-regex http://.*/root\.exe
Cisco CSS11K (Content Services switch):
service dummy
ip address 10.1.1.1
keepalive type none
active
!
header-field-group cmd.exe
header-field cmd.exe request-line contain "cmd.exe"
header-field-group root.exe
header-field root.exe request-line contain "root.exe"
!
content block_cmd.exe
protocol tcp
port 80
url "/*"
header-field-rule cmd.exe
add service dummy
active
content block_root.exe
protocol tcp
port 80
url "/*"
header-field-rule root.exe
add service dummy
active
>The ideal result is to prevent nimda GET probes from ever
>reaching the destination address, but causing the session
>to be reset towards the server after the open handshake but
>before the GET can be sent to the server would be acceptably
>useful.
note that only the CSS and the CE in the above will actually prevent the
'tcp syn' from propogating, and they'll establish the tcp 3-way handshake,
receive the HTTP headers and then match the request to be an "attack".
NBAR will only match the headers on connections that successfully establish
a 3-way handshake. (NBAR won't cause the router to spoof the TCP setup -
so-called delayed-binding).
cheers,
lincoln.
More information about the NANOG
mailing list