active firewall

active firewall

[Nik Trevallyn-Jones]

Hi All,

   As a result of experiences deploying PortSentry behind an ipchains 
firewall recently, I started considering how iptables could be used to deploy 
a dynamic firewall which would be able to modify itself in response to 
predefined events. As far as I can see, such features would require extension 
modules.

Q: Has anyone considered or suggested this before?

Below are some further details of the features as I currently envisage them:

1  two new targets: ENLIST, DELIST
These targets effectively cause one or more new rules to be automatically 
added/removed to/from the firewall in response to matching the associated 
rule. This allows the firewall to respond to certain events by 
adding/deleting rules within itself.

1.1 ENLIST (eg: BLACKLISTING)
This causes one or more new rules to be added to the firewall, often to block 
some host, port, interface, etc, but could also be used to dynamically route 
packets through/around transparent proxies, etc. By default, all rules added 
by ENLIST are temporary, and are automatically removed once they have expired.
Eg an ENLIST rule could effectively assert: "ENLIST a DROP rule for two hours 
for all succeeding packets from any host that tries to connect to post 137".

1.2 DELIST (eg: WHITELISTING)
This causes the specified match criteria to have their ENLIST "credit" 
increased. Since many ENLIST rules will typically cause some types of  
traffic to be blocked, the DELIST target must be able to be used *in advance* 
- essentially forewarning the firewall that an otherwise enlistable event is 
about to occur which should *not* trigger enlisting this time. However, since 
DELIST rules simply change a state (or counter) in the opposite direction to 
that in which an ENLIST rule does, DELISTING a currently ENLISTED host, port, 
interface, etc will remove the ENLISTED rules. A timeout option would ensure 
that an advance DELIST does not last forever, or that a DELIST target can 
*only* DELIST an existing ENLISTED rule.
Eg. a DELIST rule could assert: "skip the next ENLIST match on port 137 if it 
arrives within the next 20 seconds".

2. a new target: DEFER (eg: GREYLISTING)
This causes the decision regarding matching packets to be "delayed" until 
further information has been gathered to determine their fate. In this way, a 
packet received on a "suspicious" port may be ultimately blocked if further 
associated suspicious activity is detected within some time period, otherwise 
the packet would continue traversing the chains. For example, the decision 
regarding a SYN packet to port 21 could be deferred to see if the same 
machine tries other ports in the near future. If it looks like the machine is 
scanning, then that machine could be blacklisted, causing all packets 
including the DEFERRED packet to be DROPPED. If however, no other suspicious 
activity is observed, the packet would continue to the next rule in the 
chain.

I am not particularly experienced in this area of networking to know how this 
delay might be implemented, but I see some possibilities:

* the packet is simply held in limbo, and the eventual response is returned 
once the decision has been made (risks timeout at the originating end)

*  some form of "busy, try again soon" packet is sent, causing the originator 
to try again (increasing network usage for this one time, and complicating 
the DEFER implementation)

*  other??

2. a new match type: SELECT
A match type that maintains historical information on specified aspects of 
recently matching packets and uses this information to apply the target 
selectively. Hence, a single rule could be created that records (say) the 
source IP address of all recently matching packets, and triggers its target 
only for those source IP addresses that exceed some criteria (matches per 
second, etc). SELECT matches would also have options to control the 
criteria:

* count: matches if the recorded count exceeds some number

* rate: matches if the recorded count exceeds some averaged number/sec

* burst: matches if the recorded count exceeds the limit. The recorded count 
is decremented for each time period that passes without any matches.

Eg A SELECT rule could assert: "SELECT the source IP address of all ICMP 
packets, and ENLIST a blacklist rule for all source IP addresses that exceed 
3/sec".

3. a new target: THROTTLE or CHOKE (eg tarpit)
This target implements a simple packet-level tarpit, inserting (possibly 
ever-increasing) delays before each response. There should be multiple 
benefits:

3.1 Actual scanning/hacking processes are slowed down, significantly reducing 
the number of attempts in a given time period.

3.2 Freeing of resources on both originating and receiving machines, and 
since both of these are usually innocent bystanders, this would release CPU 
and network resources for "real" processing.

Again, my network knowledge is insufficient to work out the details, but 
a "<delay> - <I'm sorry, could you repeat what you just said>" 
loop would probably be a good place to start.

4. I would also like to be able to determine if there is a process listening 
to the target port of a packet. Does the difference between the NEW and 
INVALID states tell me this? Ie, if a SYN packet arrives for some port, then 
will the state be NEW if there is a process listening on the port, and 
INVALID if not?
I would like to write a rule which asserts: "BLACKLIST any host that sends a 
SYN packet to any ports between 1025-50000 unless there is a socket listening 
to the port at the time the packet arrives".

Sorry this email is so long. Hopefully it is of interest - all thoughts and 
comments gratefull received.

Cheers!
Nik.

Re: active firewall

[Chris Brenton]

Nik Trevallyn-Jones wrote:
> 
>    As a result of experiences deploying PortSentry behind an ipchains 
> firewall recently, I started considering how iptables could be used to deploy 
> a dynamic firewall which would be able to modify itself in response to 
> predefined events.

Be very careful with this. I've seen savvy attackers spoof attacks from 
the root name servers in order to make the firewall DoS the local 
environment. :(

> Q: Has anyone considered or suggested this before?

Yup, and the feature is built into many commercial firewalls (FW-1, PIX, 
etc.). I know Bill Stearns was working on this at one point. You might 
be able to find more info at:
http://www.stearns.org

> 1  two new targets: ENLIST, DELIST
> These targets effectively cause one or more new rules to be automatically 
> added/removed to/from the firewall in response to matching the associated 
> rule.

Depending on your IDS, you can script this as well. I seem to remember a 
paper floating around at one point that shows how to set this up with 
Snort and iptables.

> I would like to write a rule which asserts: "BLACKLIST any host that sends a 
> SYN packet to any ports between 1025-50000 unless there is a socket listening 
> to the port at the time the packet arrives".

Hummm, so if I back door your system the firewall will happily update 
the ruleset to permit me access to that port. That's very polite of it. ;-)

HTH,
C

Re: active firewall

[Nik Trevallyn-Jones]

On Tue, 23 Sep 2003 23:32, you wrote:
> Nik Trevallyn-Jones wrote:
> >    As a result of experiences deploying PortSentry behind an ipchains
> > firewall recently, I started considering how iptables could be used to
> > deploy a dynamic firewall which would be able to modify itself in
> > response to predefined events.
>
> Be very careful with this. I've seen savvy attackers spoof attacks from
> the root name servers in order to make the firewall DoS the local
> environment. :(

Obviously any firewall rules, whether manually or automatically implemented 
are susceptible to address spoofing. That's one of the reasons I've tried to 
make my idea as general possible.

> > Q: Has anyone considered or suggested this before?
>
> Yup, and the feature is built into many commercial firewalls (FW-1, PIX,
> etc.). I know Bill Stearns was working on this at one point. You might
> be able to find more info at:
> http://www.stearns.org

coowell!  Thanks for the pointer!

> > 1  two new targets: ENLIST, DELIST
> > These targets effectively cause one or more new rules to be automatically
> > added/removed to/from the firewall in response to matching the associated
> > rule.
>
> Depending on your IDS, you can script this as well. I seem to remember a
> paper floating around at one point that shows how to set this up with
> Snort and iptables.

I haven't looked at snort, but PortSentry can (and does on my machine) do 
quite a bit of this. However, as I considered what improvements I would like 
in PortSentry, it became obvious I was trying to put rule-matching chain 
logic into it - hence my idea to extend iptables.

> > I would like to write a rule which asserts: "BLACKLIST any host that
> > sends a SYN packet to any ports between 1025-50000 unless there is a
> > socket listening to the port at the time the packet arrives".
>
> Hummm, so if I back door your system the firewall will happily update
> the ruleset to permit me access to that port. That's very polite of it. ;-)

Well, if I'm polite to hackers, maybe they'll be nice to me??

- Actually my logic (possibly flawed) was that if they had back doored my 
system, they probably had enough control to rewrite/disable my firewall 
anyway.

This kind of ability seems to be much more useful on my internal LAN than on 
my internet interface. I've found in general that PortSentry does basically 
nothing on my internet interface, because the firewall is stopping any 
traffic that would normally trip PortSentry. However, on my internal LAN, 
PortSentry flipped up the shutters pronto when someone recently connected a 
laptop that was infected with the Blaster worm.

Sadly, there was no firewall between that laptop and my other (relatively 
few) PCs, but PortSentry's response alerted me pretty quickly. So what I am 
planning now is a separate "quarantine" subnet where I will corral all 
laptops that could be carrying disease. In that case, PortSentry on the 
firewall/router between the quarantine and regular LAN would probably stop an 
infection spreading out of the quarantine subnet.

Cheers!
Nik.

Re: active firewall

[Mark Vevers]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 23 Sep 2003 2:26 pm, Nik Trevallyn-Jones wrote:

> 1  two new targets: ENLIST, DELIST
> These targets effectively cause one or more new rules to be automatically
> added/removed to/from the firewall in response to matching the associated
> rule. This allows the firewall to respond to certain events by
> adding/deleting rules within itself.
You can do most of what you are after with the 'RECENT' match and target ...

I.e. if 'X' seen from 'Y' within n seconds - block Y 
You can create some quite interesting rulesets with recent and a few logic
chains .....

Mark
- -- 
Mark Vevers.    mark@ifl.net / mvevers@rm.com
Principal Internet Engineer, Internet for Learning,
Research Machines Plc  AS 5503
Tel: +44 1235 854314,   Fax: +44 1235 854693
- --
GPG Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB08F3CA3
Fingerprint: 85BA 30C4 9EC8 1792 4C8C   C31E 58B5 3D1C B08F 3CA3
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/cGKVWLU9HLCPPKMRAs7pAJ94G/Tra46YJhANHjxcax+xFFeYHACfbpf5
ETRkADtzBYezwEUZq/qNzHg=
=mNJy
-----END PGP SIGNATURE-----

Re: active firewall

[Nik Trevallyn-Jones]

On Wed, 24 Sep 2003 01:11, Mark Vevers wrote:

> You can do most of what you are after with the 'RECENT' match and target
> ...
>
> I.e. if 'X' seen from 'Y' within n seconds - block Y
> You can create some quite interesting rulesets with recent and a few logic
> chains .....

Awesome! This sounds to be exactly what I was looking for!

Many thanks - I'm off to find out about RECENT...

Cheers!

Re: active firewall

[Jim Carter]

On Tue, 23 Sep 2003, Nik Trevallyn-Jones wrote:
>    As a result of experiences deploying PortSentry behind an ipchains
> firewall recently, I started considering how iptables could be used to deploy
> a dynamic firewall which would be able to modify itself in response to
> predefined events. As far as I can see, such features would require extension
> modules.

Take a look at the ULOG target which will send a copy of the packet to a
netlink socket.  A listening daemon can then do wierd and wonderful
modifications to the tables.  There's the issue that the table changes
wouldn't happen until the daemon got the CPU, so a few :-) milliseconds
delay could be expected, but in the scenario you described, that would be
tolerable.

The less brains are in the kernel, the less things can go wrong and
splatter.  Hope this helps.

James F. Carter          Voice 310 825 2897    FAX 310 206 6673
UCLA-Mathnet;  6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555
Email: jimc@math.ucla.edu  http://www.math.ucla.edu/~jimc (q.v. for PGP key)