Re: [nf-failover] conntrack questions

Re: [nf-failover] conntrack questions

[Pablo Neira Ayuso]

Roman Fiedler wrote:
> Hello Everyone,
> 
> I have some problems using the conntrack application, it could be that I'm just 
> conntrack options the wrong way or that my assumptions about conntracking itself 
> are wrong.
> 
> Testcase:
> 
> * Two networks 10.0.0.0/24 and 10.0.1.0/24 separated by firewall
> * iptables firewall drops all tcp-SYN net A to B and writes log file entry
> * some DROPS are interesting, so I grep info about them from logfile 
> (src,dest,ports)
> * with conntrack tool I want to create an conntrack table entry so that the 
> connection is accepted and the following SYN is SNATed/DNATed to a given IP 
> (currently also in net A but that could be changed)
> 
> Is this possible? My iptables setup should accept all RELATED,ESTABLISHED 
> packets by default and the conntrack entry should set the natting for this 
> single connection and make it ACCEPTED.
> 
> Currently when I use to add the connection (for testing src port is fixed to 
> 1234 and dest 25, test host is 138, forbidden target 1.10, reroute host 0.77)
> 
> conntrack -I conntrack -p tcp --orig-src 10.0.0.138 --orig-dst 10.0.1.10 
> --reply-src 10.0.0.77 --reply-dst 10.0.0.1 --orig-port-src 1234 --orig-port-dst 
> 25 --reply-port-src 25 --reply-port-dst 1234 --state SYN_SENT -u ASSURED -t 10 
> --src-nat 10.0.0.1 --dst-nat 10.0.0.77
> 
> With this rule the rule hit counter is incremented when sending a SYN, but ulogd 
> still reports a DROP
> 
> tcp      6 117 SYN_SENT src=10.0.0.138 dst=10.0.1.10 sport=1234 dport=25 
> packets=1 bytes=60 [UNREPLIED] src=10.0.0.77 dst=10.0.0.1 sport=25 dport=1234 
> packets=0 bytes=0 [ASSURED] mark=0 use=1
> 
> ulog output:
> Feb 22 12:39:17 firewall-grz-0 Shorewall:FORWARD:DROP: IN=eth0 OUT=eth1 MAC=00 
> SRC=10.0.0.138 DST=10.0.1.10 LEN=60 TOS=00 PREC=0x00 TTL=63 ID=61556 CE DF 
> PROTO=TCP SPT=1234 DPT=25 SEQ=2694492256 ACK=0 WINDOW=5840 SYN URGP=0
> 
> When using LISTEN instead of SYN_SENT, the packets/bytes counter does not go up, 
> but also no drop is reported and packet does not leave via any interface.
> 
> Can someone give me a hint where I am wrong?

Sorry, to be honest, I don't understand what you're doing. Please,
elaborate a bit more.

-- 
"Los honestos son inadaptados sociales" -- Les Luthiers

Re: [nf-failover] conntrack questions

[Roman Fiedler]

Pablo Neira Ayuso wrote:
> Roman Fiedler wrote:
>> Hello Everyone,
>>
>> I have some problems using the conntrack application, it could be that I'm just
>> conntrack options the wrong way or that my assumptions about conntracking itself
>> are wrong.
>>
>> Testcase:
>>
>> * Two networks 10.0.0.0/24 and 10.0.1.0/24 separated by firewall
>> * iptables firewall drops all tcp-SYN net A to B and writes log file entry
>> * some DROPS are interesting, so I grep info about them from logfile
>> (src,dest,ports)
>> * with conntrack tool I want to create an conntrack table entry so that the
>> connection is accepted and the following SYN is SNATed/DNATed to a given IP
>> (currently also in net A but that could be changed)
>>
>> Is this possible? My iptables setup should accept all RELATED,ESTABLISHED
>> packets by default and the conntrack entry should set the natting for this
>> single connection and make it ACCEPTED.
>>
>> Currently when I use to add the connection (for testing src port is fixed to
>> 1234 and dest 25, test host is 138, forbidden target 1.10, reroute host 0.77)
>>
>> conntrack -I conntrack -p tcp --orig-src 10.0.0.138 --orig-dst 10.0.1.10
>> --reply-src 10.0.0.77 --reply-dst 10.0.0.1 --orig-port-src 1234 --orig-port-dst
>> 25 --reply-port-src 25 --reply-port-dst 1234 --state SYN_SENT -u ASSURED -t 10
>> --src-nat 10.0.0.1 --dst-nat 10.0.0.77
>>
>> With this rule the rule hit counter is incremented when sending a SYN, but ulogd
>> still reports a DROP
>>
>> tcp      6 117 SYN_SENT src=10.0.0.138 dst=10.0.1.10 sport=1234 dport=25
>> packets=1 bytes=60 [UNREPLIED] src=10.0.0.77 dst=10.0.0.1 sport=25 dport=1234
>> packets=0 bytes=0 [ASSURED] mark=0 use=1
>>
>> ulog output:
>> Feb 22 12:39:17 firewall-grz-0 Shorewall:FORWARD:DROP: IN=eth0 OUT=eth1 MAC=00
>> SRC=10.0.0.138 DST=10.0.1.10 LEN=60 TOS=00 PREC=0x00 TTL=63 ID=61556 CE DF
>> PROTO=TCP SPT=1234 DPT=25 SEQ=2694492256 ACK=0 WINDOW=5840 SYN URGP=0
>>
>> When using LISTEN instead of SYN_SENT, the packets/bytes counter does not go up,
>> but also no drop is reported and packet does not leave via any interface.
>>
>> Can someone give me a hint where I am wrong?
>
> Sorry, to be honest, I don't understand what you're doing. Please,
> elaborate a bit more.

I think that I have found some bits of the answer already by myself and guess 
that my misunderstandings of the relationship between natting and conntrack 
causes your confusion.

I thought that natting and conntrack are linked in a way, so that a entry in the 
conntrack table could influence the natting process. I assume that this is 
wrong, only natting influences the conntrack table content but not vice versa.
[ Part of the reasoning: DNAT is done in PREROUTING, the conntrack table 
checks/modification in the filter table. So changing the conntrack table entry 
dnat ip addr for an existing connection will not change the natting behavior]

If the assumption would have been true, then modification of conntrack table 
entries could be used to reroute an existing (or expected connection) to another 
IP address without changing the iptable rules (especially the DNAT rules in 
PREROUTING).

The conntrack tool would have been the link between userspace, where the 
decision to intercept an reroute a connection is made, and kernel space where 
the iptables and conntrackrecords cause rerouting.

The big idea behind all of that is that one could use an configured and running 
iptables firewall and intercept single connections opened by malicious software 
for analysis without changing (restarting) the firewall. A primitive analysis 
program in userspace would decide which connections are "malicious" and trigger 
the rerouting. Example

Standard http request (allowed in standard firewall config):

any host --> external IP on firewall, natted to http server --->  http server


If analysis program says host X is bad, only connections from that server are 
rerouted, so that they cannot damage real system and analysis can begin.

only host X --> ext IP natted to fake server --> fake server



As I understand it now, such kind of connection intercept cannot be done using 
iptables, so I have to look out for some other solution. Perhaps someone can 
tell me if my assumption of conntrack - natting interactions are correct, just 
for curiosity.