active firewall

[Nik Trevallyn-Jones <nik@designer.com.au>]

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.