North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Quarantine your infected users spreading malware

  • From: Christopher L. Morrow
  • Date: Wed Mar 01 11:38:31 2006

On Wed, 1 Mar 2006, JP Velders wrote:

> > Date: Tue, 28 Feb 2006 18:50:29 +0000 (GMT)
> > From: Christopher L. Morrow <[email protected]>
> > To: [email protected]
> > Subject: Re: Quarantine your infected users spreading malware
> > On Tue, 28 Feb 2006, Jim Segrave wrote:
> > >
> > > It puts them in a protected environment where they can get cleaned up
> > > on-line without serious risk of re-infection. They can pop their
> > > e-mail, reply via webmail, but they can't connect to anywhere except a
> > > list of update sites.
> > there was little in the way of 'how' in the link above though :(
> Well, it's very much dependant on your own network.
> >From what I know (from presentations of the folk behind Qnet, and
> talks with people actually using it) is that they have a sort of
> "export" module, which allows you to either output the IP's, or parse
> them such that you get a crafted DHCP entry, or special MAC address
> based "alternate VLAN" statement for on a switch etc.

which is fabulous for those of you with ethernet... without ethernet most
of these solutions fall on their faces and die the horrid death of an
enterprise product :( Now, they say: "Works great on carrier networks"...
my question was "how" and "perhaps with a little less hand-waviness

> They have templates for a bunch of things, but whether or not one of
> those templates is applicable or even useful in your own network
> remains te be seen each and every time.

and none of these so called templates is available or described on their
public documentation :( There are a few ways to skin this cat, depending
upon architecture one might even work. Without knowing the possible
methodologies available it's not helpful :(

> The main strength of Qnet is the detection, and even better, the way
> of allowing people to clean themselves, and then get back on the net.
> Having a helpdesk tell (different) people the same line over and over
> again gets tedious. Putting the effort into making a nice explanatory
> webpage get so much more "return on investment"... ;)

agreed, punting this problem to the helpdesk makes the helpdesk manager
grab his gun(s) and find the security wonk that put a hurtin' on his
numbers :) Also, it costs lots of money, which isn't generally a good