Re: Connection intercept

[Josh Cepek <josh.cepek@usa.net>]

[-- 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 --]