Identifying NAT'ed machines

Hi,

As admin of a server with a NAT'ed network behind it, I find that it
would be very usefull if a NAT'ed machine could later be identified by
analyzing the packets that were sent out from the NAT server. For
example if a NAT'ed machine is attacking other servers or sending our
spam etc.
So if there is no provision in the tcp/udp protocols for this then I
see two possibillities that could maybe be implemented:

1) The outgoing packets could be marked using iptables. If the 'mark'
can only be one byte (I am not sure if its limited) then 4 packets
could be marked in succession each with a different section of the
NAT'ed machines private IP. For example if the NAT'ed machine has
private IP of 192.168.0.11 then packet #1 is marked '192', packet #2
is marked '168', packet #3='0' and packet # 4 is marked '11' and
packet #5 is '192' and so on in a round robin manner. Later analysis
of the packets would then easilly reveal the NAT'ed IP. However, there
is one problem with this, for example if another gateway overwrites
that mark, AFAIK. So it wouldn't allways work. It might still be
usefull though for later forensic analysis of some offensive traffic.
Also, other information could be encoded in this manner if desired
(I'm not sure what would be interresting). Or is there another,
non-used field in the tcp/udp packets that we can hijack for this
purpose?
Would this be possible with iptables?

2) The other possibillity could be that a special-purpose
'identification' package could be sent, by the NAT server, when a
NAT'ed machine connects to somewhere. This could simply be a package
that includes the private IP (e.g. 192.168.0.11) of the sending
machine as well as maybe a keyword. The 'id' package is discarded by
the receiving server (maybe we just send it to a non-listening port?),
but if the receiving machines' gateway is capturing the packets
because it thinks something suspicious is going on, then it will also
catch the 'id' package. If the captured packets are then sent to the
admin of the NAT server he can easilly identify the sending machine by
noticing the 'id' packet included in the traffic. In order to reduce
network load, we could send one (1) 'id' packet at the initial
connection attempt, and then one (1) after every say 50 packets. Or it
could for example, be sent after 2 packets and after 4 packets and
after 8, 16, 32, 64, 128 packets and from then on at every 128
packets.
So is it possible to get iptables to do this? or in some other way?.

I would like to hear opinions on these two schemes, even if it's not
possible to implement with the current iptables. Or maybe somebody has
got even better schemes in mind?

Regards,
Tobias Skytte

On 2004-10-26, Tobias Skytte <(E-Mail Removed)> wrote:
> would be very usefull if a NAT'ed machine could later be identified by
> analyzing the packets that were sent out from the NAT server

You can do that checking the firewall log (if you have the log and
the time/will to analyze it), since packet are logged with their
true source and destination isn't very difficult to match them.

Davide

--
I mean, we all self-LART to varying degrees on occasion. What sets us
apart from the lusers is that we can pull ourselves out of the nosedive.
-- Mike Sphar on alt.sysadmin.recovery

Tobias Skytte wrote:

> Hi,
>
> As admin of a server with a NAT'ed network behind it, I find that it
> would be very usefull if a NAT'ed machine could later be identified by
> analyzing the packets that were sent out from the NAT server. For
> example if a NAT'ed machine is attacking other servers or sending our
> spam etc.
> So if there is no provision in the tcp/udp protocols for this then I
> see two possibillities that could maybe be implemented:
>
> 1) The outgoing packets could be marked using iptables. If the 'mark'
> can only be one byte (I am not sure if its limited) then 4 packets
> could be marked in succession each with a different section of the
> NAT'ed machines private IP. For example if the NAT'ed machine has
> private IP of 192.168.0.11 then packet #1 is marked '192', packet #2
> is marked '168', packet #3='0' and packet # 4 is marked '11' and
> packet #5 is '192' and so on in a round robin manner. Later analysis
> of the packets would then easilly reveal the NAT'ed IP. However, there
> is one problem with this, for example if another gateway overwrites
> that mark, AFAIK. So it wouldn't allways work. It might still be
> usefull though for later forensic analysis of some offensive traffic.
> Also, other information could be encoded in this manner if desired
> (I'm not sure what would be interresting). Or is there another,
> non-used field in the tcp/udp packets that we can hijack for this
> purpose?
> Would this be possible with iptables?

You'd have to modify the IP header, in a manner that would violate the spec.
>
> 2) The other possibillity could be that a special-purpose
> 'identification' package could be sent, by the NAT server, when a
> NAT'ed machine connects to somewhere. This could simply be a package
> that includes the private IP (e.g. 192.168.0.11) of the sending
> machine as well as maybe a keyword. The 'id' package is discarded by
> the receiving server (maybe we just send it to a non-listening port?),
> but if the receiving machines' gateway is capturing the packets
> because it thinks something suspicious is going on, then it will also
> catch the 'id' package. If the captured packets are then sent to the
> admin of the NAT server he can easilly identify the sending machine by
> noticing the 'id' packet included in the traffic. In order to reduce
> network load, we could send one (1) 'id' packet at the initial
> connection attempt, and then one (1) after every say 50 packets. Or it
> could for example, be sent after 2 packets and after 4 packets and
> after 8, 16, 32, 64, 128 packets and from then on at every 128
> packets.
> So is it possible to get iptables to do this? or in some other way?.
>
> I would like to hear opinions on these two schemes, even if it's not
> possible to implement with the current iptables. Or maybe somebody has
> got even better schemes in mind?

You could certainly monitor all traffic on your lan, with an analyzer, such
as ethereal or tcpdump, and filter based on source and destination
addresses. What happens next, is up to you. You might also be able to use
the IPTables logging, to discover who's going outside.


I don't think much of your idea of the ID packet, as it doesn't conform,
with the way IP works.



--

(This space intentionally left blank)

Tobias Skytte wrote:
> Or maybe somebody has got even better schemes in mind?

Other than logging, I'm not being clear what you are trying achieve. If
it's just logging, how about using proxy software such as Squid or
Delegate and only allowing the proxy machine to connected (i.e. turn off
forwarding and NAT)?

Paul

In article <(E-Mail Removed) >,
Tobias Skytte wrote:

>As admin of a server with a NAT'ed network behind it, I find that it
>would be very usefull if a NAT'ed machine could later be identified by
>analyzing the packets that were sent out from the NAT server. For
>example if a NAT'ed machine is attacking other servers or sending our
>spam etc.

In theory - that's what your firewall logs should show. This does assume
that the time information from the complainer and from your firewall are
not to grossly out. On the other hand, most people are paranoid enough
to want to block indications of what their network looks like behind the
firewall.

Originally, the RFC1413 Identification Protocol was hoped to be usable
for this. In theory, it does more than what you want - as it may
identify the _user_ who is doing stuff. In fact, it's next to useless,
as evidenced by such programs as "Fake Identd" (do a google search for
that as one word). Of course, a lot depends on who has admin rights or
root on your computers.

>So if there is no provision in the tcp/udp protocols for this then I
>see two possibillities that could maybe be implemented:

No sir! You can't go hijacking bytes out of TCP (or UDP, or ICMP or IGMP)
packets any more than you can get away with grabbing an IP address out of
mid-air because you don't want to use an RFC1918 address.

If you want to do something about this, wander over to the IETF and
propose adding an IPv4 option to do this. There are 20 bytes allowed
for options AFTER the 32 bit destination IP address and before the
"data" (which could be a TCP packet, UDP packet, ICMP packets, IGMP
packet, etc.), or do you feel it only needs to be in TCP (which also
allows 20 bytes for options).

Old guy

(E-Mail Removed) (Moe Trin) wrote in message news:<(E-Mail Removed)> ...

> In theory - that's what your firewall logs should show. This does assume
> that the time information from the complainer and from your firewall are
> not to grossly out. On the other hand, most people are paranoid enough
> to want to block indications of what their network looks like behind the
> firewall.

Yes, but firewall logs tend to get really large so they have to be
deleted once in a while. I suppose it's better than nothing, but I
think it would be more elegant if the info was in the packets. I know
that NAT is an adhock add-on to the internet but why a means to track
the NAT'ed machines wasn't included at the same time is imho strange.
Maybe because of politics?

> Originally, the RFC1413 Identification Protocol was hoped to be usable
> for this. In theory, it does more than what you want - as it may
> identify the _user_ who is doing stuff. In fact, it's next to useless,
> as evidenced by such programs as "Fake Identd" (do a google search for
> that as one word). Of course, a lot depends on who has admin rights or
> root on your computers.

Mm, yeah, if it's useless anyway then there's no point. Also I was
hoping for something simple and starightforward.

> >So if there is no provision in the tcp/udp protocols for this then I
> >see two possibillities that could maybe be implemented:
>
> No sir! You can't go hijacking bytes out of TCP (or UDP, or ICMP or IGMP)
> packets any more than you can get away with grabbing an IP address out of
> mid-air because you don't want to use an RFC1918 address.

heh. No I guess not. Btw, do you know where the 'mark' is set in the
ip/tcp/udp/other protocols when 'marking' packets ?
What about the #2 possibillity of sending an 'id' packet that will be
dropped by the receiver but which is still captured along with the
other normal packets (if the receiver's gateway is capturing). That
doesn't violate any protocols IMHO. Not sure how to implement it
though.

> If you want to do something about this, wander over to the IETF and
> propose adding an IPv4 option to do this. There are 20 bytes allowed
> for options AFTER the 32 bit destination IP address and before the
> "data" (which could be a TCP packet, UDP packet, ICMP packets, IGMP
> packet, etc.), or do you feel it only needs to be in TCP (which also
> allows 20 bytes for options).
>
> Old guy

That's interresting. When I wrote tcp/udp I actually meant IP. It
would be better if it's included in all the packet types. I checked
rfc791 and the options section i perfect for something like that, but
what are the chances of the ietf agreeing to this?


regards,
Tobias Skytte

In article <(E-Mail Removed) >,
Tobias Skytte wrote:

>I know that NAT is an adhock add-on to the internet but why a means
>to track the NAT'ed machines wasn't included at the same time is imho
>strange. Maybe because of politics?

More likely, because no one thought about it. Remember that NAT is not
a specific standard. There wasn't a place to put the information
anyway.

>Mm, yeah, if it's useless anyway then there's no point. Also I was
>hoping for something simple and starightforward.

Do look at RFC1413. If no one can install network software (we don't
do windoze here, so I don't know how practical it is on windoze - on
*nix it means not giving root to users AND monitoring the systems on
an irregular but "frequent" basis, then it can be made to work.
It does put a burden on the masquerading box, and you may need to
hack the ident server because of differences in port numbers. By
that I mean that the _normal_ ident packet asks who on your computer
and port number X is trying to connect to my port Y - but X isn't the
real source port on the NATed box..

>heh. No I guess not. Btw, do you know where the 'mark' is set in the
>ip/tcp/udp/other protocols when 'marking' packets ?

I don't understand what you are asking. "Marking" how?

>What about the #2 possibillity of sending an 'id' packet that will be
>dropped by the receiver but which is still captured along with the
>other normal packets (if the receiver's gateway is capturing). That
>doesn't violate any protocols IMHO. Not sure how to implement it
>though.

Well... what you might consider doing is scanning RFC1413, and note
what information is permitted (also look at the man page for identd
and see what information is can be made to present). You might fudge
the ident server running on the NAT box to respond with a packet that
includes the internal address and a _locally_ authoritative timestamp.
Note that right now, identd can be configured to return an encrypted
answer that only you can decrypt. The remote admin has no way of
determining information that Security wouldn't want let out, but the
admin has a token that may allow _you_ to figure out whose head rolls.

RFC1413 servers were originally intended to run on hosts where there
were multiple users at the same time. However I don't see why you
couldn't run it on the masquerading box, and use it to tell which
_host_ was the source of the packets. That should likely be enough
to identify your bad guy, as the current trend is one user per host.

>That's interresting. When I wrote tcp/udp I actually meant IP. It
>would be better if it's included in all the packet types. I checked
>rfc791 and the options section i perfect for something like that, but
>what are the chances of the ietf agreeing to this?

Well, here - no way in heck. Elsewhere? Hard to say.

Old guy

(E-Mail Removed) (Moe Trin) wrote in message news:<(E-Mail Removed)> ...
> In article <(E-Mail Removed) >,

> More likely, because no one thought about it. Remember that NAT is not
> a specific standard. There wasn't a place to put the information
> anyway.

Yup, that's why we need to do something about it IMHO. For example we
are serving dial-up on NAT (bec we can't get enough ip's at the
moment!) so anybody dialing in can do mischief without me being able
to trace it back to them. It would be nice if something could be
'built-in' to the protocols or something put on top of them.

> Do look at RFC1413. If no one can install network software (we don't
> do windoze here, so I don't know how practical it is on windoze - on
> *nix it means not giving root to users AND monitoring the systems on
> an irregular but "frequent" basis, then it can be made to work.
> It does put a burden on the masquerading box, and you may need to
> hack the ident server because of differences in port numbers. By
> that I mean that the _normal_ ident packet asks who on your computer
> and port number X is trying to connect to my port Y - but X isn't the
> real source port on the NATed box..

ok I'll look at it later, but my server is NAT'ing commercial clients
and they can install whatever software they want on their machines so
it can be circumvented if I understand you correctly?. Also I dont
have access to the nat'ed LAN machines so can't install stuff. Only
have access to the server.

> I don't understand what you are asking. "Marking" how?

Ok, I should have been more clear. I meant the mark that can be set
via iptables for example like this:

A PREROUTING -m tos --tos Minimize-Delay -j MARK --set-mark 0x1

So that later I can use tc to shape the traffic that has that mark set
on it. I don't know how many bits that field is, and it's probably
useless to use that field anyway because it may get overwritten by
another router somewhere along the route. But I thought that maybe
that field could be 'hijacked' and used to transmit the nat'ed ip one
byte at a time.

> Well... what you might consider doing is scanning RFC1413, and note
> what information is permitted (also look at the man page for identd
> and see what information is can be made to present). You might fudge
> the ident server running on the NAT box to respond with a packet that
> includes the internal address and a _locally_ authoritative timestamp.
> Note that right now, identd can be configured to return an encrypted
> answer that only you can decrypt. The remote admin has no way of
> determining information that Security wouldn't want let out, but the
> admin has a token that may allow _you_ to figure out whose head rolls.

ok , that sounds interresting, but would that require the nat'ed
machines to run an 'ident' client? I havent had time to read the rfc
yet, but will do.

> Well, here - no way in heck. Elsewhere? Hard to say.

:-)

Tobias Skytte

In article <(E-Mail Removed) >,
Tobias Skytte wrote:

>Yup, that's why we need to do something about it IMHO. For example we
>are serving dial-up on NAT (bec we can't get enough ip's at the
>moment!) so anybody dialing in can do mischief without me being able
>to trace it back to them. It would be nice if something could be
>'built-in' to the protocols or something put on top of them.

OK, now I understand where you are coming from. No, there really isn't
anything that would be perfect. Logging everything would work, but the
amount of logs would be a drawback.

>ok I'll look at it later, but my server is NAT'ing commercial clients
>and they can install whatever software they want on their machines so
>it can be circumvented if I understand you correctly?.

Yes - that's the real problem with RFC1413. You have to trust the ident
server, and if it's not under trustworthy control, all bets are off. As
mentioned, it was originally meant for a situation where the users were
on terminals, and didn't have root on the actual computer.

>Ok, I should have been more clear. I meant the mark that can be set
>via iptables for example like this:
>
>A PREROUTING -m tos --tos Minimize-Delay -j MARK --set-mark 0x1

Ah, OK - that doesn't actually get put into the packet - that's a variable
within your firewall.

>ok , that sounds interresting, but would that require the nat'ed
>machines to run an 'ident' client? I havent had time to read the rfc
>yet, but will do.

No, but it would require the person who is complaining to have run the
ident client (the app that queries your server), and return that info
as part of their complaint to you. What I'm suggesting is that when they
run an ident query, the server on your NAT box replies with the encrypted
local IP and the timestamp. I'm assuming you have the normal logs of
who dialed in when, and what IP they were assigned and for how long. Now
the remote site can't make heads/tails out of the encrypted data, any more
than they can do now. From the man page for identd:

The -C[<keyfile>] option tells identd to return encrypted
tokens instead of user names. The local and remote IP
addresses and TCP port numbers, the local user's uid num-
ber, a timestamp, a random number, and a checksum, are all
encrypted using DES with a secret key derived from the
first line of the keyfile (using des_string_to_key(3)).
The encrypted binary information is then encoded in a
base64 string (32 characters in length) and enclosed in
square brackets to produce a token that is transmitted to
the remote client. The encrypted token can later be
decrypted by idecrypt(8).

This is already sending the _type_ of data you want, except it's getting
it from the processes running on the server running identd (and not from
your bad customer's host). You'd have to hack the identd program so that
it gets the data that you actually want - which is the address that is
being NATed - maybe even the user name who dialed in to your server.

This may not be enough - as the complaining party would have to know to
have run an ident query. But then, your idea of hijacking bits in a
header would require them to include those bits, and as the headers are
normally discarded by the network stack, they likely wouldn't have them
either. You'd probably still have to have some logging in place, to take
care of the case where the complainer can't spell TCP or ident, but it
opening the missile launch codes because he was attacked by your server,
and that's all he knows.

Old guy

Paul Black <(E-Mail Removed)> wrote in message news:<clm03j$pm$(E-Mail Removed)>...
> Tobias Skytte wrote:
> > Or maybe somebody has got even better schemes in mind?
>
> Other than logging, I'm not being clear what you are trying achieve. If
> it's just logging, how about using proxy software such as Squid or
> Delegate and only allowing the proxy machine to connected (i.e. turn off
> forwarding and NAT)?
>
> Paul


Ok, what I specifically want is that if I get a complaint from some
admin somewhere in the internet that he is being attacked from my
nat-server then I want him to be able to send me a packetdump and then
I want to be able to see in the packets (or in that traffic) precisely
which machine on the natted network is sending the packets. Perhaps
that admin is only sending me that dump, say, 4 days later, so
realtime traffic analysing on my part wouldn't help.
Also my firewall may not be logging *everything* so it would be nice
if there was some 'evidence' (i.e. the nat ip) in the offencive
packets.

Regards,
Tobias