Quarantine your infected users spreading malware

--On Tuesday, February 28, 2006 14:07:36 -0500 Bill Nash 
<billnodyssey.billn.net> wrote:

> The simplest method is to issue a different gateway to
a registry of
> known offenders, forcing their into a restrictive
environment that blocks
> all ports, and uses network translation tricks to
redirect all web
> traffic to a portal.
>
> For cable modems and bridged DSL, you can do this with
DHCP, matching
> their MAC address. PPPOE/DSL or similiar, you match on
user name. Issue
> RFC1918 space with a gateway to your quarantine
network.
>
> The rest is NAT/PAT and w3proxy stunts. You could pull
it off with
> something as simple as iptables and squid, after
dealing with the DHCP or
> authentication servers (ala Radius) to issue to the
correct credentials.
>

We a couple techniques at Carnegie Mellon, depending on the
network 
scenario.

The DHCP based technique outlined above requires no extra
infrastructure, 
just extra configuration, so it is what we use for most of
our campus wired 
networks.  We use the same setup as our registration helper
network, so our 
internal name for the DHCP based quarantine system is called
QuickReg.  An 
unknown or banned client gets an address in 1918 space and
can only access 
our abuse tracking, patch download and network registration
systems.

But on our campus wireless network we use a inline filter
system we call 
AuthBridge, based on ebtables and iptables, to filter &
redirect any 
traffic from unknown/banned clients.  This system provides a
more seamless 
user experience, but requires a layer-2 aggregation point
where you can 
pass the traffic through the filter host.  Because our
wireless is a single 
campus wide layer-2 network this is more feasible for that
network.

Both of these systems are integrated with CMU's DHCP &
DNS Management 
system, NetReg. (not to be confused with Southwestern
University's NetReg. 
Different systems...)  The DHCP helper system is a builtin
feature, while 
the AuthBridge system is an add on.   (AuthBridge just went
through a 
complete rewrite to use the standard ebtables/iptables in
Linux 2.6, and a 
public release should be available soon...)

For information on NetReg, QuickReg or AuthBridge, see:
http://www.net.cmu.edu/
netreg
http://acs-wiki.andrew.cmu.edu/twiki/bin/view/Netreg
/WebHome
http://acs-wiki.andrew.cmu.edu/twiki/
bin/view/Netreg/NetRegManualDesign#Qui
ckReg
http://acs-wiki.andrew.cmu.edu/twiki/bin/view/Net
reg/AuthBridge

(Our abuse tracking system also integrates with NetReg, so
going from an 
external incident report to a machine suspension and email
to the user & 
admins is as simple as dropping an IP and timestamp into a
web form...)

-David Nolan
 Network Software Designer
 Computing Services
 Carnegie Mellon University

--On Tuesday, February 28, 2006 14:39:37 -0500 David Nolan 
<vitroth+cmu.edu> wrote:

> We a couple techniques at Carnegie Mellon, depending on
the network
> scenario.
>
> The DHCP based technique outlined above requires no
extra infrastructure,
> just extra configuration, so it is what we use for most
of our campus
> wired networks.  We use the same setup as our
registration helper
> network, so our internal name for the DHCP based
quarantine system is
> called QuickReg.  An unknown or banned client gets an
address in 1918
> space and can only access our abuse tracking, patch
download and network
> registration systems.

Following up my own post.  I know, its always bad ettiquete,
but I forgot 
to mention something.

We're also using an active suspension mechanism for these
networks to block 
clients with current valid DHCP leases instantly.  We use
Unicast Reverse 
Path Filtering (*) and /32 host routes injected into our
OSPF cloud via 
quagga (ospf routing daemon on a unix server).

This means a suspended host loses all network connectivity
immediately, 
until they re-dhcp, at which point they'll have a rfc1918
address and have 
access to the quarantine network.  This also handles the
occasional 
statically configured host.

We can also use this system to filter external hosts without
having to 
manipulate border router acls frequently.


(*): For anyone who doesn't know, URPF is essentially a way
to do automatic 
acls, comparing the source IP of on an incoming packet to
the routing table 
to verify the packet should have come from this interface. 
With the right 
hardware this is significantly cheaper then acl processing. 
And its 
certainly easier to maintain.  And by injecting a /32 null
route into the 
route table you can cause a host's local router to start
discarding all 
traffic from that IP.


-David Nolan
 Network Software Designer
 Computing Services
 Carnegie Mellon University

David Nolan wrote:
<snip>
> 
> (*): For anyone who doesn't know, URPF is essentially
a way to do 
> automatic acls, comparing the source IP of on an
incoming packet to the 
> routing table to verify the packet should have come
from this 
> interface.  With the right hardware this is
significantly cheaper then 
> acl processing.  And its certainly easier to maintain. 
And by injecting 
> a /32 null route into the route table you can cause a
host's local 
> router to start discarding all traffic from that IP.
> 
<snip sig>

Yeah, but it's not near as fun as dynamic acls updated via
a script 
monitoring flow logs in real-time. It's definitely easier
to implement, 
though.

For people utilizing RBE/dhcp combo on Cisco routers, it is
also 
possible to just remove the /32 route that was dynamically
created which 
will kill traffic until the customer requests dhcp again,
which will by 
that time place them in the quarantine. One advantage to
temp route 
removal is that it requires no cleanup. Just make sure you
don't wipe 
out your permanent static routes.

-Jack

--On Wednesday, March 01, 2006 07:54:17 -0600 Jack Bates 
<jbatesbrightok.net> wrote:

> David Nolan wrote:
> <snip>
>>
>> (*): For anyone who doesn't know, URPF is
essentially a way to do
>> automatic acls, comparing the source IP of on an
incoming packet to the
>> routing table to verify the packet should have come
from this
>> interface.  With the right hardware this is
significantly cheaper then
>> acl processing.  And its certainly easier to
maintain.  And by injecting
>> a /32 null route into the route table you can cause
a host's local
>> router to start discarding all traffic from that
IP.
>>
> <snip sig>
>
> Yeah, but it's not near as fun as dynamic acls updated
via a script
> monitoring flow logs in real-time. It's definitely
easier to implement,
> though.

Interesting...  Thats actually basically what we were doing
before, but 
phased out in favor of the URPF & host routes approach. 
We felt the URPF 
approach was much cleaner, and more efficient.  A routing
table lookup is 
more efficient then a acl processing, particulary if you
have significant 
numbers of rou and solved some problems we were having.  It
also solved 
some issues we had, including keeping dynamic acls
synchronized betwen two 
redundant routers (HSRP pairs and/or redundant border
routers).

-David

On Wed, 1 Mar 2006, David Nolan wrote:

>> Yeah, but it's not near as fun as dynamic acls
updated via a script
>> monitoring flow logs in real-time. It's definitely
easier to implement,
>> though.
>
> Interesting...  Thats actually basically what we were
doing before, but 
> phased out in favor of the URPF & host routes
approach.  We felt the URPF 
> approach was much cleaner, and more efficient.  A
routing table lookup is 
> more efficient then a acl processing, particulary if
you have significant 
> numbers of rou and solved some problems we were having.
 It also solved some 
> issues we had, including keeping dynamic acls
synchronized betwen two 
> redundant routers (HSRP pairs and/or redundant border
routers).

I think when he said fun, he meant 'masochistic and nerve
wracking, in a 
vaguely entertaining because we have scripts issuing and
removing ACLs 
from our routing core kind of way.' I've built reactive
firewalls before, 
but even I'd be leery of a reactive ACL implementation. /32
null route 
injection is far far easier to manage. =)

- billn