Strange package logged

[Anders Peter Fugmann]

Thanks for your answer.

Is seems that you have the same opinion as Brad, when he suggested a 
Trojan on my system.?.

As to allowing ICMP packages, I have the rule:

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

As one of the first rules in the INPUT queue.
(The logging occured as the last entry in the input queue).

I've setup watching for all packages comming to/from the offending 
server, so I hope that I will gather something, under the assuption that 
it is not possible to write a program (trojan) that bypasses iptables.

My guess is that the packet occured from the LAN, but the NAT has 
already closed down the socket (due to timeout). Then after awhile a 
packet returns from the server (the ICMP packet), hits the INPUT rule, 
and is regarded as NEW.

But could this in anyway explain that the packet has SRC=DST?

Next what wonders me is, that When a packet hist the INPUT queue, and it 
regarded as NEW, it is forwarded to a new chain, that drops all 
packages. Therefore it should never have droppped through the INPUT QUEUE.

Regards
Anders Fugmann

Nigel Morse wrote:
> Well lets look at it....
> 
> 
>>Aug 17 00:18:31 fugmann kernel: Packet missed:IN=eth0 OUT= 
>>MAC=00:20:18:52:65:0b
>>:00:20:6f:08:f4:52:08:00 SRC=212.181.78.28 DST=10.0.1.1 
>>
> 
> the MAC bit is boring.... src and dst? well its coming in from outside
> 
> 
>>LEN=56 TOS=0x00 
>>PREC=0x0
>>
> 
> other boring bits..
> 
> 
>>0 TTL=109 ID=1828 PROTO=ICMP TYPE=3 CODE=3 
>>
> 
> some boring bits - then AHA!!! it's an ICMP packet - type 3 code 3 is
> Destination Unreachable - Port Unreachable
> 
> 
>>[SRC=10.0.1.1  DST=212.181.78.28 LEN=4
>>3 TOS=0x00 PREC=0x00 TTL=43 ID=0 DF PROTO=UDP SPT=27960 
>>DPT=27960 LEN=23 ]
>>
> 
> Now I'm going to guess here, but it looks like this is a reference to the
> original packet that was sent out - i.e. your machine sent a UDP packet to
> 212.181.78.38:27960 (no idea what this is...) which then responded saying
> that the port was unreachable.
> 
> Now I belive that connection tracking in iptables means that if you allowed
> ICMP packets that are RELATED then this would get through - something like
> 
> iptables -p icmp -m state --state ESTABLISHED,RELATED -j ACCEPT 
> would do it - but it depends on your ICMP filtering policy.  [Note that you
> should NOT be blocking all ICMP types]
> 
> As to what caused the original packet to be sent out, or what it was doing i
> don't know. You may want to check that machine for badness.
> 
> Cheers
> Nigel
> 
>