iptables NAT logging

iptables NAT logging

[Jonathan Gazeley]

Hello,

I am stuck while trying to log a NAT box to a sufficiently high level.

The NAT box caters for up to several hundred users in a large 
organisation (University of Bristol) so thorough logging of all 
connections is essential, for traceability and our legal requirements. 
Basically I need to know which internal (private) address was talking to 
which external IP address on which ports at which time.

My NAT solution is implemented in iptables and works fine. The logging 
partially works but the problem is this: I am logging pre NAT, and my 
log shows the internal IP and port, and the destination IP and its port. 
But it does not show the port used by the NAT box to talk to the 
external IP. Logging post NAT would never detect any packets. If I was 
able to long pre and post NAT I would be able to log all the information 
I need.

I did some googling and spoke to colleagues but I have been unable to 
log all the required information. Can anyone shed any light on this? 
Does anyone either know how to make this work, or can propose a better 
solution?

Thanks,
Jonathan

----------------------
Jonathan Gazeley
ResNet | Wireless Team
Information Services
University of Bristol
----------------------

Re: iptables NAT logging

[G.W. Haywood]

Hi there,

On Fri, 2 Nov 2007, Jonathan Gazeley wrote:

> ... NAT box caters for up to several hundred users in a large
> organisation (University of Bristol) so thorough logging of all
> connections is essential, for traceability and our legal requirements.
> Basically I need to know which internal (private) address was talking to
> which external IP address on which ports at which time.

tcpdump?

--

73,
Ged.

Re: iptables NAT logging

[Martijn Lievaart]

Jonathan Gazeley wrote:
> Hello,
>
> I am stuck while trying to log a NAT box to a sufficiently high level.
>
> The NAT box caters for up to several hundred users in a large 
> organisation (University of Bristol) so thorough logging of all 
> connections is essential, for traceability and our legal requirements. 
> Basically I need to know which internal (private) address was talking 
> to which external IP address on which ports at which time.
>
> My NAT solution is implemented in iptables and works fine. The logging 
> partially works but the problem is this: I am logging pre NAT, and my 
> log shows the internal IP and port, and the destination IP and its 
> port. But it does not show the port used by the NAT box to talk to the 
> external IP. Logging post NAT would never detect any packets. If I was 
> able to long pre and post NAT I would be able to log all the 
> information I need.
>

Logging in filter/FORWARD should see all packets.

M4

Re: iptables NAT logging

[Grant Taylor]

On 11/02/07 03:47, Jonathan Gazeley wrote:
> My NAT solution is implemented in iptables and works fine. The logging 
> partially works but the problem is this: I am logging pre NAT, and my 
> log shows the internal IP and port, and the destination IP and its port. 
> But it does not show the port used by the NAT box to talk to the 
> external IP. Logging post NAT would never detect any packets. If I was 
> able to long pre and post NAT I would be able to log all the information 
> I need.

Ugh, this could be problematic.  If I understand you correctly, you 
essentially need to log the following information.  I also suspect that 
it needs to be per connection NOT per packet.  Correct?

Internal Source IP
Internal Source Port
External Source IP (post NAT)
External Source Port (post NAT)
External Destination IP
External Destination Port
Protocol

I'm not sure if you will want to log the IP level protocol or not, but 
it may be a good thing to do.

I would suggest that you do this logging in the NAT table so that you 
only log the initial packet and not each and every packet that passes 
through.

I'm presuming that you are already logging when the connection 
initiates.  Do you also want to log when the connection terminates?

I unfortunately don't have access to a Linux box doing NATing at the 
moment to know for sure.  However I suspect that some of the external 
information you are needing can be obtained from the connection tracking 
/ NATing sub system.  You may need to use some sort of user space 
process or write a match extension and / or a target that will grab the 
external post nat information that you need.

I would also suggest that you find an optimal way to store the logged 
information.  I don't think that a TCPDump file, or a libcap output file 
will suffice because normally they only refer to two sets of IP and 
Port, not three like you need.

Another option that may work is to mark each packet in some fashion and 
log it before and after NATing.  However seeing as how dynamic things 
are I think it would be very impractical to ""mark packets in the 
traditional sense.

Thinking about the last idea... If you could somehow augment the LOG 
target to also include the connection tracking information (ID if you 
will) you could probably log pre and post NAT and then just have 
multiple records that you would need to pull to correlate your 
information, say connection tracking ID, source IP, source port, 
destination IP, and destination port both before and after.  This way 
you would have everything that you need.

I still feel like your best solution is going to be the first idea, work 
with the connection tracking sub system.



Grant. . . .

RE: iptables NAT logging

[李伟华]

> Date: Fri, 2 Nov 2007 09:59:47 -0500
> From: gtaylor@riverviewtech.net
> To: netfilter@vger.kernel.org
> Subject: Re: iptables NAT logging
>
> On 11/02/07 03:47, Jonathan Gazeley wrote:
>> My NAT solution is implemented in iptables and works fine. The logging
>> partially works but the problem is this: I am logging pre NAT, and my
>> log shows the internal IP and port, and the destination IP and its port.
>> But it does not show the port used by the NAT box to talk to the
>> external IP. Logging post NAT would never detect any packets. If I was
>> able to long pre and post NAT I would be able to log all the information
>> I need.
>
> Ugh, this could be problematic. If I understand you correctly, you
> essentially need to log the following information. I also suspect that
> it needs to be per connection NOT per packet. Correct?
>
> Internal Source IP
> Internal Source Port
> External Source IP (post NAT)
> External Source Port (post NAT)
> External Destination IP
> External Destination Port
> Protocol
>
> I'm not sure if you will want to log the IP level protocol or not, but
> it may be a good thing to do.
>
> I would suggest that you do this logging in the NAT table so that you
> only log the initial packet and not each and every packet that passes
> through.
>
> I'm presuming that you are already logging when the connection
> initiates. Do you also want to log when the connection terminates?
>
> I unfortunately don't have access to a Linux box doing NATing at the
> moment to know for sure. However I suspect that some of the external
> information you are needing can be obtained from the connection tracking
> / NATing sub system. You may need to use some sort of user space
> process or write a match extension and / or a target that will grab the
> external post nat information that you need.
>
> I would also suggest that you find an optimal way to store the logged
> information. I don't think that a TCPDump file, or a libcap output file
> will suffice because normally they only refer to two sets of IP and
> Port, not three like you need.
>
> Another option that may work is to mark each packet in some fashion and
> log it before and after NATing. However seeing as how dynamic things
> are I think it would be very impractical to ""mark packets in the
> traditional sense.
>
> Thinking about the last idea... If you could somehow augment the LOG
> target to also include the connection tracking information (ID if you
> will) you could probably log pre and post NAT and then just have
> multiple records that you would need to pull to correlate your
> information, say connection tracking ID, source IP, source port,
> destination IP, and destination port both before and after. This way
> you would have everything that you need.
>
> I still feel like your best solution is going to be the first idea, work
> with the connection tracking sub system.
>
>
>
> Grant. . . .
> -
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html


'$IPT -t nat -A POSTROUTING -m state --state NEW -j LOG' can log new connection  include  internal source ip port and external source ip port ......  
And '$IPT -t filter -A FORWARD -m state --state NEW -j LOG' can log new connection include internal source ip port and external dest ip port .......
_________________________________________________________________
用 Live Search 搜尽天下资讯！
http://www.live.com/?searchOnly=true

Re: iptables NAT logging

[Jonathan Gazeley]

Grant Taylor wrote:
> On 11/02/07 03:47, Jonathan Gazeley wrote:
>> My NAT solution is implemented in iptables and works fine. The 
>> logging partially works but the problem is this: I am logging pre 
>> NAT, and my log shows the internal IP and port, and the destination 
>> IP and its port. But it does not show the port used by the NAT box to 
>> talk to the external IP. Logging post NAT would never detect any 
>> packets. If I was able to long pre and post NAT I would be able to 
>> log all the information I need.
>
> Ugh, this could be problematic.  If I understand you correctly, you 
> essentially need to log the following information.  I also suspect 
> that it needs to be per connection NOT per packet.  Correct?
>
> Internal Source IP
> Internal Source Port
> External Source IP (post NAT)
> External Source Port (post NAT)
> External Destination IP
> External Destination Port
> Protocol
Yes that's correct. Per connection is fine; we just need to know which 
users were talking to what, when. Logging every packet simply isn't 
feasible (or useful) on a network that shifts 38TB every single day!
> I'm presuming that you are already logging when the connection 
> initiates.  Do you also want to log when the connection terminates?
Yes, knowing when the connection terminates is also useful, otherwise we 
won't know how long a user is connected to a server for.

I'll let you know how this goes, although this isn't my highest priority 
project at the moment so I may not get a chance to play for a few days.

Thanks a lot for your help,
Jonathan

----------------------
Jonathan Gazeley
ResNet | Wireless Team
Information Services
University of Bristol
----------------------

Re: iptables NAT logging

[Grant Taylor]

On 11/06/07 10:38, Jonathan Gazeley wrote:
> Yes that's correct. Per connection is fine; we just need to know which 
> users were talking to what, when. Logging every packet simply isn't 
> feasible (or useful) on a network that shifts 38TB every single day!

That's a LOT of traffic and will equally be a LOT of logs.

> Yes, knowing when the connection terminates is also useful, otherwise we 
> won't know how long a user is connected to a server for.

That may be more problematic to detect, especially with UDP.  For TCP 
streams that shut down normally, you could watch for the FIN packets and 
log them.  However I'm not sure how to detect the non continuance of a 
UDP stream, much less other protocols.  The only thing that I can think 
of is to watch for the lack of traffic for a specific amount of time and 
presume that the connection is terminated.

I suppose you could augment the connection tracking code to log when it 
expired a tracked connection.  You could at least get the end of a 
connection this way.  However this is probably kernel coding.

> I'll let you know how this goes, although this isn't my highest priority 
> project at the moment so I may not get a chance to play for a few days.

Please do, I'm interested to know fore future projects.

> Thanks a lot for your help.

You are welcome.



Grant. . . .

Re: iptables NAT logging

[Philip Craig]

Grant Taylor wrote:
> I suppose you could augment the connection tracking code to log when it 
> expired a tracked connection.  You could at least get the end of a 
> connection this way.  However this is probably kernel coding.

No kernel coding needed, it already generates netlink events.
You just need to listen for this event in userspace and log it
from there.

Re: iptables NAT logging

[Grant Taylor]

On 11/6/2007 6:53 PM, Philip Craig wrote:
> No kernel coding needed, it already generates netlink events.  You 
> just need to listen for this event in userspace and log it from 
> there.

Ok, it must have been a very long day.  How and where would you listen 
to said netlink events?  Or are you referring to some sort of daemon 
that would behave like a user space filtering application via netlink?



Grant. . . .

Re: iptables NAT logging

[Philip Craig]

Grant Taylor wrote:
> Ok, it must have been a very long day.  How and where would you listen 
> to said netlink events?  Or are you referring to some sort of daemon 
> that would behave like a user space filtering application via netlink?

ulogd2 has support for listening to the events, although I haven't tested it
recently.  Look for the flow logging options.

You could also use the 'conntrack' tool to monitor them, and pipe that
to a log file.

This is purely about connection tracking, not filtering, so you can't match
up these events with the filter rule that accepted it, unless you encode that
in the mark or something.  It will only get events for connections that are
accepted by filtering though.

Re: iptables NAT logging

[Grant Taylor]

On 11/6/2007 9:01 PM, Philip Craig wrote:
> ulogd2 has support for listening to the events, although I haven't 
> tested it recently.  Look for the flow logging options.
> 
> You could also use the 'conntrack' tool to monitor them, and pipe 
> that to a log file.

Interesting.

> This is purely about connection tracking, not filtering, so you can't 
> match up these events with the filter rule that accepted it, unless 
> you encode that in the mark or something.  It will only get events 
> for connections that are accepted by filtering though.

Unless I mis-understand the OP's desires, I don't think the shortcoming 
(if it qualifies as that) of not being able to associate a NetLink event 
with a given IPTables rule is all that big of a deal.  I think the OP 
just needed to log internal and external source and destination IP 
addresses and ports and when the connection started and stopped, thus 
knowing which IPTables rule is (IMHO) a non issue.  I guess depending on 
what someone was trying to do this could be an issue.



Grant. . . .

Re: iptables NAT logging

[Philip Craig]

Jonathan Gazeley wrote:
> My NAT solution is implemented in iptables and works fine. The logging 
> partially works but the problem is this: I am logging pre NAT, and my 
> log shows the internal IP and port, and the destination IP and its port. 
> But it does not show the port used by the NAT box to talk to the 
> external IP. Logging post NAT would never detect any packets. If I was 
> able to long pre and post NAT I would be able to log all the information 
> I need.

conntrack netlink events have the information you want.  Look at either
ulogd2 flow logging, or the conntrack tool with the -E option.