Most certainly. Unfortunately, that approach is not always possible. Many of the subnets here on campus use that exact method, and we (campus wide network services) work closely with them to help tailor filters and security to their exact needs, but two issues prevent us from using this sort of policy on a campus wide scale. Firstly, we are an academic institution, and the academic community is noted for its openness and free flow of information. That just doesn't fit too well with this type of access plan. However, in most corporations, it's entirely appropriate, and definitely preferred to use that sort of model. The second reason this is less feasible is the sheer size of our network. I would suspect that any corporation of equivalent size to our campus would have a hard time using such a networking policy unless it was implemented very early on in their network usage. Otherwise things get fractioned into each department, group, or division, and everyone develops their own networks, policies, all of which make one giant jumble too complicated to reduce easily with company wide restriction. (re current US tax laws -- thankfully our networks are nothing like that!) Having said that, I agree with you that filtering first and allowing second is the best policy available. In fact, we recommended to a department on campus yesterday that exact method as they were concerned with a recent security issue with one of their machines. I'll have to dig up my 2600; I read that article a few weeks ago on a plane ride (it was a 10 hour flight; the back pages of 2600 provide the perfect sort of distraction to keep me entertained) but I'll have to glance back over it. One caveat with this is that while this is the best general policy around, it is by no means a 'safe' system. Servers will always be vulnerable. As long as there are services available to the world, machines will be open. No amount of firewalling, filtering, or restrictions will stop the latest poorly written perl calendar script from making an entire machine (and subsequently, entire network) vulernable. Which is why reading of the logs is mentioned in the article, and this is very important, but again, not a catch-all, just another step in the long process that is security. A very wise man once noted that "security is process, not a product." -- Jordan Wiens UF Network Incident Response Team (352)392-2061 "Give me an intelligent sysadmin over an intelligent IDS any day..." On Thu, 14 Jun 2001, Cloppert, Michael wrote: > Jose et al, > > The most recent 2600 has a great article on IDS's and Anomaly detection. I > would recommend you read it. The one I'm thinking of is second in a series, > so if you want to go back and read the first feel free. The applicable > information that I'm referring to (and completely agree with) is in this > second part, however. > > The article discusses how even intelligent IDS's can't cover everything > specifically because the signatures aren't made available until [in some > cases] it's too late - or the delay is significant enough to leave your > network unacceptably vulnerable. The author goes on to say that your best > bet would be to not filter traffic which is unacceptable, but to filter ALL > traffic EXCEPT that which is specifically acceptable. Throw in monitoring > of log files and you have "Anomaly Detection." This does require that you > analyze and know your network's traffic in and out, and it is no simple task > to set up, however it's the closest (in my opinion) to a fool-proof system > you can get. With this sort of a system, you are protected from MANY of the > unforseen new-fangled mechanisms all the crackers out there come up with > which would be otherwise ignored by sig.-based IDS's. > > I of course welcome any comments on/criticisms of this view, and I'm sure > you know enough to make a proper judgement based on your network. Just my > thoughts. > > Mike Cloppert > > > -----Original Message----- > > From: Jordan K Wiens [mailto:jwiensat_private] > > Sent: Wednesday, June 13, 2001 5:05 PM > > To: Jose Nazario > > Cc: incidentsat_private > > Subject: Re: new iis worm: seeking signature > > > > > > Best signature we've found for catching any variety of these worms is > > keying on system32/cmd.exe to any web port. No matter what > > variation of > > the directory traversal bug the script or hacker uses, they invariably > > access cmd.exe for their first access. > > > > There are just too many variations of unicode for / and other > > characters > > and ways to combine them to try to catch them all with a simple IDS > > signature. An extremely intelligent IDS would have to either > > translate the > > unicode (even ones technically out of spec-which is the whole > > problem in > > the first place) to determine if a directory traversal is > > being attempted, > > and that's just not practical in an environment with as much > > data as many > > networks see. Generic unicode signatures work miserably for obvious > > reasons; false-positives until the sun comes up. > > > > In other words, a simple cmd.exe signature has been our most > > effective tool > > in catching these worms. > > > > -- > > Jordan Wiens > > UF Network Incident Response Team > > (352)392-2061 > > > > On Wed, 13 Jun 2001, Jose Nazario wrote: > > > > > > > > hi all, > > > > > > i found these in my apache logs after a quick check: > > > > > > 209.250.131.60 - - [10/Jun/2001:17:50:29 -0400] "GET > > > /scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir+c: > > HTTP/1.0" 404 231 > > > 209.250.131.60 - - [10/Jun/2001:17:50:30 -0400] "GET > > > > > /msadc/..%e0%80%af../..%e0%80%af../..%e0%80%af../winnt/system3 > > 2/cmd.exe?/c+dir+c: HTTP/1.0" 404 246 > > > > > > in a nutshell, plain old unicode directory traversal > > attempts. (failed, > > > obviously.) > > > > > > normally i would have dismissed these as 'kids', but these > > reports on a > > > new IIS worm have me wondering if anyone has a signature > > for the scans it > > > does: > > > > > > http://www.symantec.com/avcenter/venc/data/dos.storm.worm.html > > > http://www.security-informer.com/ic_620113_3494_1-3283.html > > > > > > thanks. > > > > > > ____________________________ > > > jose nazario > > joseat_private > > > PGP: 89 B0 81 DA 5B FD 7E 00 99 C3 B2 CD > > 48 A0 07 80 > > > PGP key ID 0xFD37F4E5 > > (pgp.mit.edu) > > > > > > > > >
This archive was generated by hypermail 2b30 : Thu Jun 14 2001 - 10:46:50 PDT