Strange package logged
Anders Peter Fugmann
Fri, 17 Aug 2001 15:02:34 +0200
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.
Nigel Morse wrote:
> Well lets look at it....
>>Aug 17 00:18:31 fugmann kernel: Packet missed:IN=eth0 OUT=
>>:00:20:6f:08:f4:52:08:00 SRC=126.96.36.199 DST=10.0.1.1
> the MAC bit is boring.... src and dst? well its coming in from outside
> 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=188.8.131.52 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
> 184.108.40.206: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.