--log-uid target?

--log-uid target?

[John Lange]

Way back in the archives from 2002 I see a patch to add support for
logging of the userid.

Searching high and low and can't find any other reference to this
feature and it does not appear to be in the current iptables or
patch-o-matic downloads.

Did this ever get implemented? How do you use it?

I tried -j LOG --log-uid but it gives an error.

I'm blocking out-bound packets to port 25 to prevent local users from
spamming. However, I'd like to who it is that is attempting to spam and
also be able to watch the logs to make sure legitimate processes are
able to send mail.

Thanks for any help.
-- 
John Lange

Re: --log-uid target?

[Patrick McHardy]

John Lange wrote:

>Way back in the archives from 2002 I see a patch to add support for
>logging of the userid.
>
>Searching high and low and can't find any other reference to this
>feature and it does not appear to be in the current iptables or
>patch-o-matic downloads.
>
>Did this ever get implemented? How do you use it?
>
Just Martin's patch from 2002.

>
>I tried -j LOG --log-uid but it gives an error.
>
>I'm blocking out-bound packets to port 25 to prevent local users from
>spamming. However, I'd like to who it is that is attempting to spam and
>also be able to watch the logs to make sure legitimate processes are
>able to send mail.
>
Sounds like a useful addition. Martin, any reason why this patch was
never merged ?

Regards
Patrick

Re: --log-uid target?

[John Lange]

Actually, Martin supplied me with the old patch from 2002 which I
modified to work with 2.6.9 and I sent them back to him for review.

I have been using it on 2 production systems since The weekend and so
far everything seems good.

There is one problem though, though I have this line in my firewall
script:

/usr/local/sbin/iptables -A OUTPUT -p tcp --dport 25 -j LOG --log-prefix
"SMTP " --log-uid

A great deal of packets are being logged with NO UID as follows:

Nov  3 20:16:50 venus kernel: SMTP IN= OUT=eth0 SRC=209.xxx.xxx.xxx
DST=203.xxx.xxx.xxx LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=8368 DF
PROTO=TCP SPT=39737 DPT=25 WINDOW=0 RES=0x00 RST URGP=0

The target does in fact work at least some of the time because there are
also plenty of packets logged like this:

Nov  3 20:25:45 venus kernel: SMTP IN= OUT=eth0 SRC=209.xxx.xxx.xxx
DST=64..xxx.xxx.xxx LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=7784 DF
PROTO=TCP SPT=39780 DPT=25 WINDOW=1460 RES=0x00 ACK URGP=0 UID=500 

UID=500 is what i expect since thats my SMTP server uid.

Under what situations could an outgoing packet be logged without a UID?
Something must own this packet?

The reason I need this patch is because I'm concerned someone might be
operating a spam relay on their account but I have no way of figuring
out who. I was hoping this would help me track it down.

Regards,
-- 
John Lange


On Wed, 2004-11-03 at 20:09, Patrick McHardy wrote:
> John Lange wrote:
> 
> >Way back in the archives from 2002 I see a patch to add support for
> >logging of the userid.
> >
> >Searching high and low and can't find any other reference to this
> >feature and it does not appear to be in the current iptables or
> >patch-o-matic downloads.
> >
> >Did this ever get implemented? How do you use it?
> >
> Just Martin's patch from 2002.
> 
> >
> >I tried -j LOG --log-uid but it gives an error.
> >
> >I'm blocking out-bound packets to port 25 to prevent local users from
> >spamming. However, I'd like to who it is that is attempting to spam and
> >also be able to watch the logs to make sure legitimate processes are
> >able to send mail.
> >
> Sounds like a useful addition. Martin, any reason why this patch was
> never merged ?
> 
> Regards
> Patrick

Re: --log-uid target?

[Patrick McHardy]

John Lange wrote:

>Actually, Martin supplied me with the old patch from 2002 which I
>modified to work with 2.6.9 and I sent them back to him for review.
>
>I have been using it on 2 production systems since The weekend and so
>far everything seems good.
>
>There is one problem though, though I have this line in my firewall
>script:
>
>/usr/local/sbin/iptables -A OUTPUT -p tcp --dport 25 -j LOG --log-prefix
>"SMTP " --log-uid
>
>A great deal of packets are being logged with NO UID as follows:
>
>Nov  3 20:16:50 venus kernel: SMTP IN= OUT=eth0 SRC=209.xxx.xxx.xxx
>DST=203.xxx.xxx.xxx LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=8368 DF
>PROTO=TCP SPT=39737 DPT=25 WINDOW=0 RES=0x00 RST URGP=0
>
>The target does in fact work at least some of the time because there are
>also plenty of packets logged like this:
>
>Nov  3 20:25:45 venus kernel: SMTP IN= OUT=eth0 SRC=209.xxx.xxx.xxx
>DST=64..xxx.xxx.xxx LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=7784 DF
>PROTO=TCP SPT=39780 DPT=25 WINDOW=1460 RES=0x00 ACK URGP=0 UID=500 
>
>UID=500 is what i expect since thats my SMTP server uid.
>
>Under what situations could an outgoing packet be logged without a UID?
>Something must own this packet?
>  
>
When the kernel replies to packets itself there is no UID.
RSTs sent in response to a packet addressed to a non-existant
socket have no (user) socket, that's why the RST is sent :)
Same for ICMP messages generated by the kernel. You should
see the UID for all packets sent from userspace.

Regards
Patrick

Re: --log-uid target?

[John Lange]

Thanks for the information Patrick.

Unfortunately I don't know enough about the underlying TCP layer to
translate your email into english :)

Basically, what I have understood you to have said is that my kernel is
generating a RST packet in response to a host trying to make a
connection to it on a non-existent socket and it is sending this reply
to the host on port 25.

RST packet being something used to "tear down" a TCP connection in a
hurry, for example when the port you are connecting isn't listening.

Here is what I don't understand, why are these hosts trying to connect
to a non-existent port and, why would the RST be destined for port 25?

Obviously I don't understand how this works. I assume incoming
connections are usually from a random high port (for most things) and so
the RST would be sent back to that same port?

What service could be originating connections on port 25 and what would
they be trying to connect to that isn't available?

If you have an theory's about what is going on here I'd be grateful if
you could pass them along to me.

Thanks,
-- 
John Lange



On Wed, 2004-11-03 at 21:30, Patrick McHardy wrote:
> John Lange wrote:
> 
> >Actually, Martin supplied me with the old patch from 2002 which I
> >modified to work with 2.6.9 and I sent them back to him for review.
> >
> >I have been using it on 2 production systems since The weekend and so
> >far everything seems good.
> >
> >There is one problem though, though I have this line in my firewall
> >script:
> >
> >/usr/local/sbin/iptables -A OUTPUT -p tcp --dport 25 -j LOG --log-prefix
> >"SMTP " --log-uid
> >
> >A great deal of packets are being logged with NO UID as follows:
> >
> >Nov  3 20:16:50 venus kernel: SMTP IN= OUT=eth0 SRC=209.xxx.xxx.xxx
> >DST=203.xxx.xxx.xxx LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=8368 DF
> >PROTO=TCP SPT=39737 DPT=25 WINDOW=0 RES=0x00 RST URGP=0
> >
> >The target does in fact work at least some of the time because there are
> >also plenty of packets logged like this:
> >
> >Nov  3 20:25:45 venus kernel: SMTP IN= OUT=eth0 SRC=209.xxx.xxx.xxx
> >DST=64..xxx.xxx.xxx LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=7784 DF
> >PROTO=TCP SPT=39780 DPT=25 WINDOW=1460 RES=0x00 ACK URGP=0 UID=500 
> >
> >UID=500 is what i expect since thats my SMTP server uid.
> >
> >Under what situations could an outgoing packet be logged without a UID?
> >Something must own this packet?
> >  
> >
> When the kernel replies to packets itself there is no UID.
> RSTs sent in response to a packet addressed to a non-existant
> socket have no (user) socket, that's why the RST is sent :)
> Same for ICMP messages generated by the kernel. You should
> see the UID for all packets sent from userspace.
> 
> Regards
> Patrick

Re: --log-uid target?

[Henrik Nordstrom]

On Wed, 3 Nov 2004, John Lange wrote:

> Thanks for the information Patrick.
>
> Unfortunately I don't know enough about the underlying TCP layer to
> translate your email into english :)

TCP RESET is the RST flag. No lines with the RST flag will have a UID as 
these are not sent by applications but the kernel in response to "invalid" 
traffic not beloning to a existing TCP connection.

The same applies to most packets with PROTO=ICMP

> RST packet being something used to "tear down" a TCP connection in a
> hurry, for example when the port you are connecting isn't listening.

Exacly. "TCP Reset"

> Here is what I don't understand, why are these hosts trying to connect
> to a non-existent port and, why would the RST be destined for port 25?

It could be a delayed reply packet to a connection already long gone on 
your side.

Your server made a connection to port 25 on the remote IP. Then aborted 
the connection (timeout or whatever), and then a while later the remote IP 
came back trying to answer your request.

TCP Reset is not only about connection establishement, but any situation 
where a packet is received not matching a valid connection.

Regards
Henrik