[Dshield] DShield vs. Symantec: new features?
areust at comcast.net
Fri Jan 9 03:30:07 GMT 2004
If I were to look at this pragmatically, you are responding to the data
that has been presented for evaluation. Latency in the data feed would
place you in a vulnerable position. If everyone uploads log at 2:00am then
latency is Large.. if they upload every two days latency is larger. If
everyone automatically uploaded data every two hours your latency would be
"two hours +" The Plus would be "your" checking the within the cycle and
the information that you are checking to respond to.
Johannes could set a semaphore (green, yellow, red or Hell is out for
Lunch) file for the appropriate condition which included the "ports" you
could then setup a GET to get Green, Yellow, Red etc.. and then grep the
port information of which specific ports to close. If it comes from a HTTPS
then reliability is "fairly" assured. So unless Johannes wants to play a
little April Fools Joke, everyone is happy with shared developed scripts.
The big key is getting everyone to send smaller logs more frequently, this
would be to reduce the latency. Then the systems approaches "real time"
activity. This goes along with training Sysadmins that schedule things for
2:00am because nothing else is happening and the backups are done..
Learning to schedule small things for after the morning Login Rush.. it
only takes 5 minutes, and if it really failed you wanted to know before in
the morning. The "Servers" tend to do more work from 10:0pm to 5:00am (any
time zone) than they do all day after the Login rush.
At 04:33 PM 1/8/2004 +0100, you wrote:
>On Thursday 08 January 2004 15:49, Johannes B. Ullrich wrote:
> > > Assume a large scale attack is launched (new virus like blaster or
> > > slammer), wouldn't it be great if the local security system could be
> > > automatically warned?
> > We do have an RSS feed, that may be useful:
> > http://isc.sans.org/rssfeed.xml
> > it does include the infocon.
>Yes, but again as an image... <url>http://isc.sans.org/images/status.gif</url>
>This is not very useful to a parsing program, which can not look at the
>picture, unless of course it is programmed to compare images, but that's not
>a very handy way to do it.
>There should be a tag for the severe cases too, as only those should cause
>measures to be taken, and thus one should be able to automatically distinct
>them from the 'usual' alerts.
> > I would be careful with automating a response based on this.
> > Maybe the response should be to wake the sysadmin? Not to
> > shut down any port?
>That's just what I have to look at, but for the moment, I think it is not so
>bad to close ports when a new virus is hitting thousands of machines in its
>first hour. That's why I would like to have the infoCon in easyly readable
>format. Only under severe conditions, automatically shutting down ports
>should be allowed.
>The services on that port aren't much of use if they are infected anyway, and
>hiding till it passes, or till patches are available can be a viable
>solution, certainly if there is danger of data getting deleted by the virus.
> > Even if we would offer a https or signed version of this feed,
> > the response will still depend on your local network. It is
> > hard to predict what any change will do ("close port 80", "shut down
> > mail server" ?).
>Most publicly available services run on default ports, and the most dangerous
>viruses try to attack them there.... So, again, closing port 80 for a new
>attack on webservers can be a good protection measure.
>Following cases are possible:
>- You have no webserver running on port 80 and no other services too: closing
>the port is just the way to go, it should not be open if there is no service
>(or if the service is only for local access) anyway.
>-You have a webserver running of the type that is being attacked: closing the
>port protects you, till you have taken appropriate measures
>-You have a webserver running of another type: the sysadmin can open the port
>again as quickly as possible, only short interruption of service has occurred
>-You are running another service than a webserver on this port.... This is in
>my opinion never going to do you any good, if you want to use non-standard
>ports, ports > 1024 should be used.
>So, only when the sysadmin is rather lazy or absent, a long interruption
>(without good reason) can happen. But in that case, closing the port is good,
>in the sense that, if the attack targets your webserver too, the lazy or
>absent sysadmin does not cause your webserver to be infected (the system
>takes care of itself). A good sysadmin can be late for stopping an attack
>(viruses can get in quickly), but can open ports quickly enough to ensure
>that service isn't interrupted for to long.
>There are pro's and cons, but I think the pro's on this matter outweigh the
>Erwin Van de Velde
>Student of University of Antwerp
>list mailing list
>list at dshield.org
>To change your subscription options (or unsubscribe), see:
More information about the list