Connection intercept

Connection intercept

[DI Roman Fiedler]

Hi all,

I want to create an iptables setup that routes all packets that would be 
dropped to a gateway on a separate interface. I try to do it by marking 
these packets with a INTERCEPT connmark (and ACCEPT them) and use a 
different routing table (std. policy routing) with a default route to 
the separate interface.  The problem: I want to use the filter tables to 
do the filtering, but the packets are already routed when they reach the 
filter tables. So I cannot route the first packet of a connection to 
this special interface, hence no real connection intercept is possible.

Setup:

Inet  - Firewall - Internal Zone
                 |
              Intercept host


The intercept host will answer for all IPs (Honeypot like), so that 
connections that would have been refused are openen and can be analysed. 
Example: Host xxxx from internal zone tries to reach nonstandard mail 
exchange, mail connection is automatically routed to the intercept host 
and mail is captured to see if xxxxx is just malconfigured or if some 
malware tries to send out some data.


Any ideas for workarounds to realise such an fw setup, e.g. exotic 
netfilter targets that can push back a packet to the beginning of the 
filter process so that it runs through the whole filter again, this time 
with the correct connmark so that it uses the alternate interface

greets, Roman

Re: Connection intercept

[Josh Cepek]

[-- Attachment #1: Type: text/plain, Size: 3683 bytes --]

DI Roman Fiedler wrote:
> Hi all,
>
> I want to create an iptables setup that routes all packets that would 
> be dropped to a gateway on a separate interface. I try to do it by 
> marking these packets with a INTERCEPT connmark (and ACCEPT them) and 
> use a different routing table (std. policy routing) with a default 
> route to the separate interface.  The problem: I want to use the 
> filter tables to do the filtering, but the packets are already routed 
> when they reach the filter tables. So I cannot route the first packet 
> of a connection to this special interface, hence no real connection 
> intercept is possible.
>
> Setup:
>
> Inet  - Firewall - Internal Zone
>                 |
>              Intercept host

Rather then fuss with routing, why not DNAT all normally rejected 
packets to your intercept host?  I'll assume for a moment that you have 
a fairly generic setup where you accept return traffic with some rule 
such as `iptables -A FORWARD -i ${WAN} -o ${LAN} -m state --state 
ESTABLISHED,RELATED -j ACCEPT` and possibly services you wish to expose 
(like a web or SSH server.)  Normally all other packets sent through the 
firewall are dropped or rejected as bogus traffic.

DNAT, as with the CONNMARK target, can only be set prior to the routing 
decision (and thus any filtering) but you can work around that.  At the 
end of your PREROUTING chain on the nat table add a reference to a new 
chain (let's call it "intercept" in this example.)  On that chain you 
want to exclude packets you normally want to let through such as traffic 
to your public services; to do this you will need to test for each 
condition and -j RETURN on each one.  The last rule in this intercept 
chain will DNAT anything you don't normally allow and send it instead to 
your intercept host.  Be sure you don't include any other DNAT rules 
after calling the intercept chain since they'll be ignored (and 
redirected instead to your intercept host.)  Here's a sample of this idea:

# add an intercept chain on nat table:
iptables -t nat -N intercept
# call this chain for inbound packets to the public IP's of this network:
iptables -t nat -A DNAT -i ${WAN_IFACE} -d ${YOUR_PUBLIC_NETRANGE} -j 
intercept
# example exceptions for web and SSH services:
iptables -t nat -A intercept -p tcp --dport 80 -j RETURN
iptables -t nat -A intercept -p tcp --dport 22 -j RETURN
# send everything else to intercept host:
iptables -t nat -A intercept -j DNAT --to-destination ${INTERCEPT_HOST}

That ruleset will make exceptions for services you normally accept and 
sent all other NEW connections to your intercept host.

> The intercept host will answer for all IPs (Honeypot like), so that 
> connections that would have been refused are openen and can be 
> analysed. Example: Host xxxx from internal zone tries to reach 
> nonstandard mail exchange, mail connection is automatically routed to 
> the intercept host and mail is captured to see if xxxxx is just 
> malconfigured or if some malware tries to send out some data.

The one remaining issue is how you handle the response to connections on 
your intercept host.  The above rules will just blindly forward any 
traffic normally rejected to the intercept host as if it was actually 
the final destination, but it is still up to the host to establish the 
connection and send out the proper reply.  This means you'll need to set 
up applications for any service you want to receive connections from, 
such as mail, web, SSH, telnet, etc.  You're probably already aware of 
this point, but I just wanted to re-iterate it for completeness.

-- 
Josh



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Connection intercept

[DI Roman Fiedler]

Josh Cepek wrote:
> DI Roman Fiedler wrote:
>> Hi all,
>>
>> I want to create an iptables setup that routes all packets that would 
>> be dropped to a gateway on a separate interface. I try to do it by 
>> marking these packets with a INTERCEPT connmark (and ACCEPT them) and 
>> use a different routing table (std. policy routing) with a default 
>> route to the separate interface.  The problem: I want to use the 
>> filter tables to do the filtering, but the packets are already routed 
>> when they reach the filter tables. So I cannot route the first packet 
>> of a connection to this special interface, hence no real connection 
>> intercept is possible.
>>
>> Setup:
>>
>> Inet  - Firewall - Internal Zone
>>                 |
>>              Intercept host
>
> Rather then fuss with routing, why not DNAT all normally rejected 
> packets to your intercept host?
The idea was that the intercept host(s) can see the original source and 
destination IP for traffic analysis (check if one source host scans all 
destinations or just permanently hits one), but I guess this is not a 
"must have". No matter which of these method is used, both of them split 
the traffic in PREROUTING and before the filter tables, which I want to 
avoid somehow (see below for explanation).

>   I'll assume for a moment that you have a fairly generic setup where 
> you accept return traffic with some rule such as `iptables -A FORWARD 
> -i ${WAN} -o ${LAN} -m state --state ESTABLISHED,RELATED -j ACCEPT` 
> and possibly services you wish to expose (like a web or SSH server.)  
> Normally all other packets sent through the firewall are dropped or 
> rejected as bogus traffic.
That's the problem: Our setup contains 7 networkcards, with vlan tagging 
more than 10 networks plus some vpns. We also need to do policy routing 
since some IPs occur more than once in the complete network setup. Some 
hundred rules are contained in a shorewall config. The problem: 
shorewall adds the filter rules to the filter table, after routing and 
natting, so massive change of setup would be needed to make pre-route 
decisions work.

My goal was to do it with minimal effort, e.g. make an iptables-save 
output patch that will transform the current iptables data to a setup 
that can do the intercepting. I do not think that it would be possible 
to do the thing with shorewall directly and I want to avoid recoding all 
filter rules in the prerouting table (some would be impossible since 
they use output interface for decision, which is not defined at this point).

I thought that perhaps somebody has done experiments with a "strange" 
setups, e.g. use a tricky combination of MIRROR targets or a loop via 
some geek netlink program that can feedback the packet from the ULOG 
target to the interface receive methods so that it can pass PREROUTING 
twice.

> DNAT, as with the CONNMARK target, can only be set prior to the 
> routing decision (and thus any filtering) but you can work around 
> that.  At the end of your PREROUTING chain on the nat table add a 
> reference to a new chain (let's call it "intercept" in this example.)  
> On that chain you want to exclude packets you normally want to let 
> through such as traffic to your public services; to do this you will 
> need to test for each condition and -j RETURN on each one.  The last 
> rule in this intercept chain will DNAT anything you don't normally 
> allow and send it instead to your intercept host.  Be sure you don't 
> include any other DNAT rules after calling the intercept chain since 
> they'll be ignored (and redirected instead to your intercept host.)  
> Here's a sample of this idea:
>
> # add an intercept chain on nat table:
> iptables -t nat -N intercept
> # call this chain for inbound packets to the public IP's of this network:
> iptables -t nat -A DNAT -i ${WAN_IFACE} -d ${YOUR_PUBLIC_NETRANGE} -j 
> intercept
> # example exceptions for web and SSH services:
> iptables -t nat -A intercept -p tcp --dport 80 -j RETURN
> iptables -t nat -A intercept -p tcp --dport 22 -j RETURN
> # send everything else to intercept host:
> iptables -t nat -A intercept -j DNAT --to-destination ${INTERCEPT_HOST}
>
> That ruleset will make exceptions for services you normally accept and 
> sent all other NEW connections to your intercept host.
>
>> The intercept host will answer for all IPs (Honeypot like), so that 
>> connections that would have been refused are openen and can be 
>> analysed. Example: Host xxxx from internal zone tries to reach 
>> nonstandard mail exchange, mail connection is automatically routed to 
>> the intercept host and mail is captured to see if xxxxx is just 
>> malconfigured or if some malware tries to send out some data.
>
> The one remaining issue is how you handle the response to connections 
> on your intercept host.  The above rules will just blindly forward any 
> traffic normally rejected to the intercept host as if it was actually 
> the final destination, but it is still up to the host to establish the 
> connection and send out the proper reply.  This means you'll need to 
> set up applications for any service you want to receive connections 
> from, such as mail, web, SSH, telnet, etc.  You're probably already 
> aware of this point, but I just wanted to re-iterate it for completeness.

The intercept host will have some honey-pot like setup, so it will 
answer quite a few protocols.

lg roman

Re: Connection intercept

[Grant Taylor]

On 01/16/08 03:37, DI Roman Fiedler wrote:
> The idea was that the intercept host(s) can see the original source and 
> destination IP for traffic analysis (check if one source host scans all 
> destinations or just permanently hits one), but I guess this is not a 
> "must have". No matter which of these method is used, both of them split 
> the traffic in PREROUTING and before the filter tables, which I want to 
> avoid somehow (see below for explanation).

I'm not sure what your Layer 2 and Layer 3 setup looks like so I can't 
say for sure, but I think I would be tempted to look at doing some sort 
of Layer 2 filtering / bridging to accomplish what you are after.  More 
specifically, if I was not happy with the traffic, I would alter its 
Layer 2 destination MAC address to that of the honey pot.  This way, the 
traffic would still have the appropriate Layer 3 source and destination 
IP addresses.

> That's the problem: Our setup contains 7 networkcards, with vlan tagging 
> more than 10 networks plus some vpns. We also need to do policy routing 
> since some IPs occur more than once in the complete network setup. Some 
> hundred rules are contained in a shorewall config. The problem: 
> shorewall adds the filter rules to the filter table, after routing and 
> natting, so massive change of setup would be needed to make pre-route 
> decisions work.

It sounds like things are fairly complex with lots of interfaces and 
further more is likely to change with time as business needs change too. 
  As such, with out knowing more about your filtering rules, I can't say 
for sure if a Layer 2 approach would work for you or not.  I'm betting 
that you would need a mixture of EBTables and IPTables to do all the 
filtering that you want on the bridged traffic.  That is to say you 
could do the simple filtering via EBTables and only use IPTables (seeing 
the bridged traffic) for the things that EBTables can not do (i.e. 
connection state and other advanced match extensions).

> My goal was to do it with minimal effort, e.g. make an iptables-save 
> output patch that will transform the current iptables data to a setup 
> that can do the intercepting. I do not think that it would be possible 
> to do the thing with shorewall directly and I want to avoid recoding all 
> filter rules in the prerouting table (some would be impossible since 
> they use output interface for decision, which is not defined at this 
> point).

It may be possible to allow Shorewall manage the IPTables rules and you 
personally (possibly via scripts) manage EBTables rules before IPTables 
sees the packets.  If you did not need to use IPTables to filter the 
bridged traffic (that is to say you are comfortable with stateless 
filtering on source / destination protocol and / or port) you could 
bridge the traffic with out IPTables being any the wiser.  If you can 
use EBTables to do your filtering, I'd hope that you could put EBTables 
and bridging in as a shim between the NICs and where IPTables picks up. 
  You could possibly even bypass IPTables for some traffic entirely.

Of course with bridging you will have to manage your IP ranges 
appropriately.

> I thought that perhaps somebody has done experiments with a "strange" 
> setups, e.g. use a tricky combination of MIRROR targets or a loop via 
> some geek netlink program that can feedback the packet from the ULOG 
> target to the interface receive methods so that it can pass PREROUTING 
> twice.

Such is probably possible, though I'm not sure of any thing like that. 
You may want to look in to how various IDS / IPS systems work.



Grant. . . .