Re: Identifying NAT'ed machines
From: Moe Trin (ibuprofin_at_painkiller.example.tld)
Date: Sat, 30 Oct 2004 18:14:33 -0500
In article <email@example.com>,
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.