INCOMPLETE [ 8bytes] with two src addresses!

INCOMPLETE [ 8bytes] with two src addresses!

[Graham Swallow]

I've never seen this log before (split lines).
Is it simply someones modem noise
How can it have two SRC addresses?

Feb 27 17:50:37 sky1 kernel: fw-drop IN=eth1
OUT= MAC=....
SRC=216.200.115.66
DST=80.5.144.39
LEN=56
TOS=0x00
PREC=0x00
TTL=247
ID=0
PROTO=ICMP
TYPE=11
CODE=0
[SRC=80.5.144.39 DST=200.179.192.14 LEN=40 TOS=0x00 PREC=0x00 TTL=1 ID=12701 PROTO=TCP INCOMPLETE [8 bytes] ] 


-- 
   regards
--
   Graham
   Information-Cascade (at) ntlworld.com

Re: INCOMPLETE [ 8bytes] with two src addresses!

[Alexis]

at first sight its the first step of a traceroute



On Fri, 2004-02-27 at 14:56, Graham Swallow wrote:
> I've never seen this log before (split lines).
> Is it simply someones modem noise
> How can it have two SRC addresses?
> 
> Feb 27 17:50:37 sky1 kernel: fw-drop IN=eth1
> OUT= MAC=....
> SRC=216.200.115.66
> DST=80.5.144.39
> LEN=56
> TOS=0x00
> PREC=0x00
> TTL=247
> ID=0
> PROTO=ICMP
> TYPE=11
> CODE=0
> [SRC=80.5.144.39 DST=200.179.192.14 LEN=40 TOS=0x00 PREC=0x00 TTL=1 ID=12701 PROTO=TCP INCOMPLETE [8 bytes] ] 
-- 
Tus problemas no se pueden resolver en el mismo
nivel mental que tenías cuando los creaste. 
		Albert Einstein

Re: INCOMPLETE [ 8bytes] with two src addresses!

[Cedric Blancher]

Le ven 27/02/2004 à 18:56, Graham Swallow a écrit :
> I've never seen this log before (split lines).
> Is it simply someones modem noise
> How can it have two SRC addresses?

This log is an ICMP error. And, as such, it contains a citation from the
IP packet that have raised it.

> Feb 27 17:50:37 sky1 kernel: fw-drop IN=eth1
> OUT= MAC=....
> SRC=216.200.115.66

ICMP error source : level3-mfn.fra1.de.mfnx.net

> DST=80.5.144.39

Destination : probably you  :)

> LEN=56
> TOS=0x00
> PREC=0x00
> TTL=247
> ID=0
> PROTO=ICMP
> TYPE=11
> CODE=0

Type 11, code 0 is TTL exceeded in transit.

> [SRC=80.5.144.39 DST=200.179.192.14 LEN=40 TOS=0x00 PREC=0x00 TTL=1
> ID=12701 PROTO=TCP INCOMPLETE [8 bytes] ]

This is original packet citation so your kernel can associate the error
to the right sent IP packet.

The source is 80.5.144.39 (normal) and the destination 200.179.192.14
(dns1.rjo.virtua.com.br). As you can see, packet was received with
TTL=1. That's why the error was raised. Then we know the payload was TCP
but the citation was truncated at 8 bytes although we need 20 to analyse
TCP header (RFC says at least IP header + 8 bytes). By the way, it could
have been cool if theses 8 bytes were shown ;)

For more information on Netfilter logging, you can see :

	http://logi.cc/linux/netfilter-log-format.php3

You can also paste your trace in the online analyser :

	http://logi.cc/linux/NetfilterLogAnalyzer.php3

-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread!

Re: INCOMPLETE [ 8bytes] with two src addresses!

[Cedric Blancher]

Le ven 27/02/2004 à 19:10, Alexis a écrit :
> at first sight its the first step of a traceroute

I don't think so.
When you traceroute, your first step is your default gateway that sends
you ICMP TTL exceeded back with an IP within your network. We can see :

> SRC=216.200.115.66
> DST=80.5.144.39

As they do not belong to the same network, it's not the first step, but
can be a further one.

Moreover, usual traceroute tools uses ICMP echo (Windows) or UDP (Unix)
probes. We have TCP here. BTW, TCP is damn cool to traceroute when you
target a host with a known opened port (e.g. www.microsoft.com) :)))

-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread!

Re: INCOMPLETE [ 8bytes] with two src addresses!

[Alexis]

ok, its my mistake when i said first step, but we have 2 confrontations
here.


in traceroute ttl=1 is only for the first packet (thats what i said
about the first step)

icmp info throws code 11 , thats why i assumed this was an traceroute.

but like you said, traceroutes uses icmp or icmp and udp like unix does.

ICMP src and dst addresses are the ones that change at each hop, but the
addresses (at ip) involved in the udp packets are always the same.
(apparently this not happen here)

Ive been reading about magic number, but its not related at all.

so , i dont know what it is.





On Fri, 2004-02-27 at 15:22, Cedric Blancher wrote:
> Le ven 27/02/2004 à 19:10, Alexis a écrit :
> > at first sight its the first step of a traceroute
> 
> I don't think so.
> When you traceroute, your first step is your default gateway that sends
> you ICMP TTL exceeded back with an IP within your network. We can see :
> 
> > SRC=216.200.115.66
> > DST=80.5.144.39
> 
> As they do not belong to the same network, it's not the first step, but
> can be a further one.
> 
> Moreover, usual traceroute tools uses ICMP echo (Windows) or UDP (Unix)
> probes. We have TCP here. BTW, TCP is damn cool to traceroute when you
> target a host with a known opened port (e.g. www.microsoft.com) :)))
-- 
Tus problemas no se pueden resolver en el mismo
nivel mental que tenías cuando los creaste. 
		Albert Einstein

Re: INCOMPLETE [ 8bytes] with two src addresses! Faked Packet?

[Graham Swallow]

Hello Cedric, salut, thanks for your reply, digestified list too,

> > [SRC=80.5.144.39 DST=200.179.192.14 LEN=40 TOS=0x00 PREC=0x00 TTL=1
> > ID=12701 PROTO=TCP INCOMPLETE [8 bytes] ]
> 
> This is original packet citation so your kernel can associate the error
> to the right sent IP packet.

	thanks, its ICMP repeat quoting, that explains the second SRC,

> > DST=80.5.144.39
> Destination : probably you  :)

	yes, but probably not! ... I didnt do a traceroute (until after!)

	I am a workstation, on NTL cable modem, with mediocre security,
	and reasonable iptables. I drop most un-established incoming
	things (a reply is too easy), allow all out (for now), and
	limit messages (so possibly miss some details). I have a test
	192.168. NAT laptop, but I didnt initiate this message. Hacked?

	If someone else injected the original packet, or the reply, why?
		Maybe it goes through their router? (unlikely)
		Maybe they want to create junk noise (wastes our time)
		Maybe they are debugging their code (whatever)
		Maybe I have an alien/virus (how would I know)

	Anyhow, I just wanted to let you know,
	in-case such things interest you ;-)
	I dont think there's much I can do,
	other than tighten up out-bound.

> > TTL=247
> Type 11, code 0 is TTL exceeded in transit.
> 	http://logi.cc/linux/NetfilterLogAnalyzer.php3


   regards
--
   Graham

Re: INCOMPLETE [ 8bytes] with two src addresses!

[Cedric Blancher]

Le ven 27/02/2004 à 19:41, Alexis a écrit :
> in traceroute ttl=1 is only for the first packet (thats what i said
> about the first step)

Yep, but...
The router which has raised the TTL exceeded error always receive the
packet with TTL=1. So, when you get an ICMP TTL exceeded, the TTL in the
citation is always 1 (well, should be).

-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread!

Re: INCOMPLETE [ 8bytes] with two src addresses!

[David Cannings]

On Friday 27 February 2004 19:17, Cedric Blancher wrote:
> Le ven 27/02/2004 à 19:41, Alexis a écrit :
> > in traceroute ttl=1 is only for the first packet (thats what i said
> > about the first step)
>
> Yep, but...
> The router which has raised the TTL exceeded error always receive the
> packet with TTL=1. So, when you get an ICMP TTL exceeded, the TTL in
> the citation is always 1 (well, should be).

Unless the router is decrementing the TTL field by more than 1 for each 
packet.  For example, if it decrements by 5 and it receives any packet 
with a TTL <= 4, it will raise TTL exceeded.

I believe this is possible, but most likely not common.

David

Strange log info from iptables ?

[Bo Jacobsen]

What is the following log info. It looks like some kind of combined ICMP and DNS ?

Feb 29 10:02:03 WFx-SH kernel: 
DROP-OUT:IN= OUT=eth0 SRC=192.168.1.2 DST=212.54.64.171 
LEN=198 TOS=0x00 PREC=0xC0 TTL=64 ID=30626 
PROTO=ICMP TYPE=3 CODE=3 [SRC=212.54.64.171 DST=192.168.1.2 LEN=170 
TOS=0x00 PREC=0x40 TTL=59 ID=53582 
PROTO=UDP SPT=53 DPT=59554 
LEN=150 ] 



-------------------------------------------------
Bo Jacobsen
 

Re: Strange log info from iptables ?

[Antony Stone]

On Sunday 29 February 2004 9:17 am, Bo Jacobsen wrote:

> What is the following log info. It looks like some kind of combined ICMP
> and DNS ?

Log entries for ICMP packets include the data in the body of the ICMP packet, 
which is the header of the packet the ICMP is about.

Remember that ICMP provides the error messages on the Internet, about other 
(usually UDP) packets, so they contain information about the packet which 
caused the error.

> Feb 29 10:02:03 WFx-SH kernel:
> DROP-OUT:IN= OUT=eth0 SRC=192.168.1.2 DST=212.54.64.171
> LEN=198 TOS=0x00 PREC=0xC0 TTL=64 ID=30626
> PROTO=ICMP TYPE=3 CODE=3 [SRC=212.54.64.171 DST=192.168.1.2 LEN=170
> TOS=0x00 PREC=0x40 TTL=59 ID=53582
> PROTO=UDP SPT=53 DPT=59554
> LEN=150 ]

Everything up to the [ is info about the ICMP packet.

Everything between [ and ] is info about the UDP packet which the ICMP is in 
response to.

Regards,

Antony.

-- 
Anything that improbable is effectively impossible.

 - Murray Gell-Mann, Novel Prizewinner in Physics

                                                     Please reply to the list;
                                                           please don't CC me.

Re: Strange log info from iptables ?

[Cedric Blancher]

Le dim 29/02/2004 à 10:17, Bo Jacobsen a écrit :
> What is the following log info. It looks like some kind of combined
> ICMP and DNS ?
> Feb 29 10:02:03 WFx-SH kernel: 
> DROP-OUT:IN= OUT=eth0 SRC=192.168.1.2 DST=212.54.64.171 
> LEN=198 TOS=0x00 PREC=0xC0 TTL=64 ID=30626 
> PROTO=ICMP TYPE=3 CODE=3 [SRC=212.54.64.171 DST=192.168.1.2 LEN=170 
> TOS=0x00 PREC=0x40 TTL=59 ID=53582 
> PROTO=UDP SPT=53 DPT=59554 
> LEN=150 ] 

To complete Antony's answer...

This is an ICMP port unreachable sent by 192.168.1.2 to 212.54.64.171
about what looks like a DNS answer (sport=UDP/53). This usually happen
on loaded links. Answer is delayed to the point client has already
closed its socket when it arrives. So the client sends back an ICMP port
unreachable.

-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread!