mystery martian source from 127.0.0.1 - Security

This is a discussion on mystery martian source from 127.0.0.1 - Security ; Hello everyone, this matter has been discussed not only once, i found a lot of hits at google. After reading almost all of them, i still do not know what the cause is and actually i am very confused. Some ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 26

Thread: mystery martian source from 127.0.0.1

  1. mystery martian source from 127.0.0.1

    Hello everyone,

    this matter has been discussed not only once, i found a lot of hits at
    google. After reading almost all of them, i still do not know what the
    cause is and actually i am very confused.

    Some say the traffic is misrouted by the ISP, others think it is a
    problem of the firewall NAT rules.

    A syslog example:
    Dec 06 21:50:58 localhost kernel: martian source 80.219.238.182 from
    127.0.0.1, on dev eth0
    Dec 06 21:50:58 localhost kernel: ll header:
    xx:xx:xx:xx:xx:xx:00:09:7b:8d:98:70:08:00

    xx:xx:xx:xx:xx:xx is the HWAddr of eth0, the rest of the header
    (00:09:7b:8d:98:70:08:00) is absolutly unknown to me.

    the traffic is coming from 127.0.0.1:80 (referring to tcpdump).
    Unfortunatly, i cannot post any output of tcpdump, since these messages
    (packets) occur arbitrary.

    Do you know, what is it all about?

    Thanks and greetz,
    Eric

  2. Re: mystery martian source from 127.0.0.1

    EricT wrote:
    > Hello everyone,
    >
    > this matter has been discussed not only once, i found a lot of hits at
    > google. After reading almost all of them, i still do not know what the
    > cause is and actually i am very confused.
    >
    > Some say the traffic is misrouted by the ISP, others think it is a
    > problem of the firewall NAT rules.
    >
    > A syslog example:
    > Dec 06 21:50:58 localhost kernel: martian source 80.219.238.182 from
    > 127.0.0.1, on dev eth0
    > Dec 06 21:50:58 localhost kernel: ll header:
    > xx:xx:xx:xx:xx:xx:00:09:7b:8d:98:70:08:00
    >
    > xx:xx:xx:xx:xx:xx is the HWAddr of eth0, the rest of the header
    > (00:09:7b:8d:98:70:08:00) is absolutly unknown to me.


    The reported address contains both the Ethernet source address
    (00:09:7b:8d:98:70) and the IP protocol identifier (08:00).

    Try to find the hardware with the Ethernet address above.

    --

    Tauno Voipio
    tauno voipio (at) iki fi

  3. Re: mystery martian source from 127.0.0.1

    Tauno Voipio wrote:
    > The reported address contains both the Ethernet source address
    > (00:09:7b:8d:98:70) and the IP protocol identifier (08:00).
    >
    > Try to find the hardware with the Ethernet address above.
    >


    Thanks a lot Tauno,

    this HWAddr does not belong to my LAN.
    Is it the receiver or the sender address of the packet? If it is the
    receiver address, how comes localhost is knowing about it?

  4. Re: mystery martian source from 127.0.0.1

    EricT wrote:
    > Tauno Voipio wrote:
    >
    >>The reported address contains both the Ethernet source address
    >>(00:09:7b:8d:98:70) and the IP protocol identifier (08:00).
    >>
    >>Try to find the hardware with the Ethernet address above.
    >>

    >
    >
    > Thanks a lot Tauno,
    >
    > this HWAddr does not belong to my LAN.
    > Is it the receiver or the sender address of the packet? If it is the
    > receiver address, how comes localhost is knowing about it?


    Fairly probably the sender address - cannot say for sure.
    To be of any use, it should be in the same LAN with you.

    Are you in the hispeed.ch DSL network? If yes, it's probably
    a misconfigured / infected host in the same network. The reported
    source address is 80-219-238-182.dclient.hispeed.ch.

    You could set up iptables to trap and log all packets with
    the IP address 80.219.238.182.

    HTH

    --

    Tauno Voipio
    tauno voipio (at) iki fi

  5. Re: mystery martian source from 127.0.0.1

    Tauno Voipio wrote:
    > Fairly probably the sender address - cannot say for sure.
    > To be of any use, it should be in the same LAN with you.
    >
    > Are you in the hispeed.ch DSL network? If yes, it's probably
    > a misconfigured / infected host in the same network. The reported
    > source address is 80-219-238-182.dclient.hispeed.ch.
    >
    > You could set up iptables to trap and log all packets with
    > the IP address 80.219.238.182.
    >
    > HTH
    >



    80-219-238-182.dclient.hispeed.ch is my external ip assigned by the ISP.
    But still i don't know this strange HWAddr (00:09:7b:8d:98:70).

    All the clients (including my firewall) within the highspeed network
    have the same netmask. The IP's are received by DHCP broadcasts.

    I have setup iptables, that's why i am wondering about these packets.

    These packets are not logged by tcpdump from
    80-219-238-182.dclient.hispeed.ch but from 127.0.0.1.

    It is confusing as i already said.

  6. Re: mystery martian source from 127.0.0.1

    On Wed, 07 Dec 2005, in the Usenet newsgroup comp.os.linux.security, in article
    , EricT wrote:

    >xx:xx:xx:xx:xx:xx is the HWAddr of eth0, the rest of the header
    >(00:09:7b:8d:98:70:08:00) is absolutly unknown to me.


    [compton ~]$ etherwhois 00:09:7b
    00-09-7B (hex) Cisco Systems
    00097B (base 16) Cisco Systems
    80 West Tasman Dr.
    SJ-M/1
    San Jose CA 95134
    UNITED STATES
    [compton ~]$

    Probably your cable modem or DSL router. You'd have to look at the TTLa
    to see if that's the source, or the crap is really coming from "outside".

    >the traffic is coming from 127.0.0.1:80 (referring to tcpdump).
    >Unfortunatly, i cannot post any output of tcpdump, since these messages
    >(packets) occur arbitrary.


    man tcpdump and look at the filtering algorithms. Something like

    tcpdump -i eth0 src host 127.0.0.1 -s 1500 -vv

    Old guy


  7. Re: mystery martian source from 127.0.0.1 - more details

    EricT wrote:
    > 80-219-238-182.dclient.hispeed.ch is my external ip assigned by the ISP.
    > But still i don't know this strange HWAddr (00:09:7b:8d:98:70).
    >
    > All the clients (including my firewall) within the highspeed network
    > have the same netmask. The IP's are received by DHCP broadcasts.
    >
    > I have setup iptables, that's why i am wondering about these packets.
    >
    > These packets are not logged by tcpdump from
    > 80-219-238-182.dclient.hispeed.ch but from 127.0.0.1.
    >
    > It is confusing as i already said.



    Todays log and ouput information:


    /var/log/messages

    Dec 8 20:42:25 localhost kernel: martian source 80.219.238.182 from
    127.0.0.1, on dev ext0
    Dec 8 20:42:25 localhost kernel: ll header:
    xx:xx:xx:xx:xx:xx:00:09:7b:8d:98:70:08:00


    the iptables did not log any traffic, the following rules are active:

    # Block packets from private networks
    $IPTABLES -A INPUT -i $EXTIF -s 127.0.0.1 -j LDROP
    $IPTABLES -A INPUT -i $EXTIF -s 192.168.0.0/16 -j LDROP
    $IPTABLES -A INPUT -i $EXTIF -s 172.16.0.0/12 -j LDROP
    $IPTABLES -A INPUT -i $EXTIF -s 10.0.0.0/8 -j LDROP

    The LDROP target will first log and then drop the packets.

    The output of the iptables status:

    Chain INPUT (policy DROP 0 packets, 0 bytes)
    pkts bytes target prot opt in out source
    destination
    0 0 LDROP all -- ext0 * 127.0.0.1
    0.0.0.0/0
    0 0 LDROP all -- ext0 * 192.168.0.0/16
    0.0.0.0/0
    0 0 LDROP all -- ext0 * 172.16.0.0/12
    0.0.0.0/0
    0 0 LDROP all -- ext0 * 10.0.0.0/8
    0.0.0.0/0


    tcpdump -vv

    20:42:25.782992 IP (tos 0x0, ttl 126, id 10724, offset 0, flags [none],
    length: 40) localhost.http > 80-219-238-182.dclient.hispeed.ch.stun-p3:
    R [tcp sum ok] 0:0(0) ack 1704591361 win 0


    the martian source log can be activated by
    echo "1" > /proc/sys/net/ipv4/conf/all/log_martians


    I really would like konw, which circumstances are responsible to get
    these martian messages.


    Thanks and greetz,
    Eric

  8. Re: mystery martian source from 127.0.0.1 - more details

    EricT wrote:
    > EricT wrote:
    >
    >>80-219-238-182.dclient.hispeed.ch is my external ip assigned by the ISP.
    >>But still i don't know this strange HWAddr (00:09:7b:8d:98:70).
    >>
    >>All the clients (including my firewall) within the highspeed network
    >>have the same netmask. The IP's are received by DHCP broadcasts.
    >>
    >>I have setup iptables, that's why i am wondering about these packets.
    >>
    >>These packets are not logged by tcpdump from
    >>80-219-238-182.dclient.hispeed.ch but from 127.0.0.1.
    >>
    >>It is confusing as i already said.

    >
    >
    >
    > Todays log and ouput information:
    >
    >
    > /var/log/messages
    >
    > Dec 8 20:42:25 localhost kernel: martian source 80.219.238.182 from
    > 127.0.0.1, on dev ext0
    > Dec 8 20:42:25 localhost kernel: ll header:
    > xx:xx:xx:xx:xx:xx:00:09:7b:8d:98:70:08:00


    It does not add any to your security to obfuscate the
    MAC address in the data link header.

    > the iptables did not log any traffic, the following rules are active:
    >
    > # Block packets from private networks
    > $IPTABLES -A INPUT -i $EXTIF -s 127.0.0.1 -j LDROP


    If you prefer to LDROP the local loop sources, change the
    source IP to 127.0.0.0/8.

    > $IPTABLES -A INPUT -i $EXTIF -s 192.168.0.0/16 -j LDROP
    > $IPTABLES -A INPUT -i $EXTIF -s 172.16.0.0/12 -j LDROP
    > $IPTABLES -A INPUT -i $EXTIF -s 10.0.0.0/8 -j LDROP


    Here you drop the RFC 1918 packets coming from the outside.

    (clip clip)

    > tcpdump -vv
    >
    > 20:42:25.782992 IP (tos 0x0, ttl 126, id 10724, offset 0, flags [none],
    > length: 40) localhost.http > 80-219-238-182.dclient.hispeed.ch.stun-p3:
    > R [tcp sum ok] 0:0(0) ack 1704591361 win 0


    This is a TCP reset packet from the WWW server port. For a
    better view, save the tcpdump data with tcpdump -w, and look
    at it with Ethereal. Also, the -n switch can make the situation
    clearer by preventing the translation of numeric addresses and
    port numbers.

    Do you have a Web server running? Check for any open ports
    with:

    netstat -tupan

    (You may need a wide screen for responses, there's plenty).

    > the martian source log can be activated by
    > echo "1" > /proc/sys/net/ipv4/conf/all/log_martians
    >
    >
    > I really would like konw, which circumstances are responsible to get
    > these martian messages.


    Google for 'linux martian source'. It gives plenty of information.

    In principle, the kernel considers a packet martian if its
    source address is obviously incorrect for the interface it's
    coming in.

    HTH

    --

    Tauno Voipio
    tauno voipio (at) iki fi

  9. Re: mystery martian source from 127.0.0.1 - more details

    Tauno Voipio wrote:
    > It does not add any to your security to obfuscate the
    > MAC address in the data link header.


    got it.

    > If you prefer to LDROP the local loop sources, change the
    > source IP to 127.0.0.0/8.


    did it for the external iface.

    >> tcpdump -vv
    >>
    >> 20:42:25.782992 IP (tos 0x0, ttl 126, id 10724, offset 0, flags [none],
    >> length: 40) localhost.http > 80-219-238-182.dclient.hispeed.ch.stun-p3:
    >> R [tcp sum ok] 0:0(0) ack 1704591361 win 0

    >
    >
    > This is a TCP reset packet from the WWW server port. For a
    > better view, save the tcpdump data with tcpdump -w, and look
    > at it with Ethereal. Also, the -n switch can make the situation
    > clearer by preventing the translation of numeric addresses and
    > port numbers.


    Frame 1 (60 bytes on wire, 60 bytes captured)
    Arrival Time: Dec 8, 2005 22:33:57.-11226009
    Time delta from previous packet: 0.000000000 seconds
    Time since reference or first frame: 0.000000000 seconds
    Frame Number: 1
    Packet Length: 60 bytes
    Capture Length: 60 bytes
    Protocols in frame: eth:ip:tcp
    Ethernet II, Src: Cisco_8d:98:70 (00:09:7b:8d:98:70), Dst: 3com_48:2c:65
    (00:01:03:48:2c:65)
    Destination: 3com_48:2c:65 (00:01:03:48:2c:65)
    Source: Cisco_8d:98:70 (00:09:7b:8d:98:70)
    Type: IP (0x0800)
    Trailer: 000000000000
    Internet Protocol, Src: 127.0.0.1 (127.0.0.1), Dst: 80.219.238.182
    (80.219.238.182)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    0000 00.. = Differentiated Services Codepoint: Default (0x00)
    .... ..0. = ECN-Capable Transport (ECT): 0
    .... ...0 = ECN-CE: 0
    Total Length: 40
    Identification: 0x25b1 (9649)
    Flags: 0x00
    0... = Reserved bit: Not set
    .0.. = Don't fragment: Not set
    ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 126
    Protocol: TCP (0x06)
    Header checksum: 0x5d81 [correct]
    Good: True
    Bad : False
    Source: 127.0.0.1 (127.0.0.1)
    Destination: 80.219.238.182 (80.219.238.182)
    Transmission Control Protocol, Src Port: http (80), Dst Port:
    eicon-server (1438), Seq: 0, Ack: 0, Len: 0
    Source port: http (80)
    Destination port: eicon-server (1438)
    Sequence number: 0 (relative sequence number)
    Acknowledgement number: 0 (relative ack number)
    Header length: 20 bytes
    Flags: 0x0014 (RST, ACK)
    0... .... = Congestion Window Reduced (CWR): Not set
    .0.. .... = ECN-Echo: Not set
    ..0. .... = Urgent: Not set
    ...1 .... = Acknowledgment: Set
    .... 0... = Push: Not set
    .... .1.. = Reset: Set
    .... ..0. = Syn: Not set
    .... ...0 = Fin: Not set
    Window size: 0
    Checksum: 0x796e [correct]

    > Do you have a Web server running?


    no

    > Check for any open ports
    > with:
    >
    > netstat -tupan


    Active Internet connections (servers and established)
    Proto Recv-Q Send-Q Local Address Foreign Address
    State PID/Program name
    tcp 0 0 0.0.0.0:32769 0.0.0.0:*
    LISTEN -
    tcp 0 0 0.0.0.0:111 0.0.0.0:*
    LISTEN 6436/portmap
    tcp 0 0 127.0.0.1:948 0.0.0.0:*
    LISTEN 7556/fam
    tcp 0 0 :::22 :::*
    LISTEN 7074/sshd
    udp 0 0 0.0.0.0:1042 0.0.0.0:*
    -
    udp 0 0 0.0.0.0:68 0.0.0.0:*
    6211/dhcpcd
    udp 0 0 0.0.0.0:111 0.0.0.0:*
    6436/portmap
    udp 0 0 192.168.200.1:123 0.0.0.0:*
    7004/ntpd
    udp 0 0 80.219.238.182:123 0.0.0.0:*
    7004/ntpd
    udp 0 0 192.168.100.10:123 0.0.0.0:*
    7004/ntpd
    udp 0 0 127.0.0.1:123 0.0.0.0:*
    7004/ntpd
    udp 0 0 0.0.0.0:123 0.0.0.0:*
    7004/ntpd
    udp 0 0 :::123 :::*
    7004/ntpd

    However, all NEW connections of any protocol to the firewall from
    outside are dropped.

    > Google for 'linux martian source'. It gives plenty of information.


    I know, but as i said in the initial post (please refer to it), these
    informations do not lead to a satisfied conclusion. Most of the hits
    (threads) did not get to an end or the solution has been disabling
    logging of martians, which do not explain the cause.

    > In principle, the kernel considers a packet martian if its
    > source address is obviously incorrect for the interface it's
    > coming in.


    I thought so, that is why i want to know what is going on in this case.

    Thanks and greetz,
    Eric

  10. Re: mystery martian source from 127.0.0.1

    Thanks a lot Moe,

    please refer to the former thraed tree.

    greetz,
    Eric

  11. Re: mystery martian source from 127.0.0.1 - more details

    EricT wrote:
    >
    > Frame 1 (60 bytes on wire, 60 bytes captured)
    > Arrival Time: Dec 8, 2005 22:33:57.-11226009
    > Time delta from previous packet: 0.000000000 seconds
    > Time since reference or first frame: 0.000000000 seconds
    > Frame Number: 1
    > Packet Length: 60 bytes
    > Capture Length: 60 bytes
    > Protocols in frame: eth:ip:tcp


    This is OK.

    > Ethernet II, Src: Cisco_8d:98:70 (00:09:7b:8d:98:70), Dst: 3com_48:2c:65
    > (00:01:03:48:2c:65)
    > Destination: 3com_48:2c:65 (00:01:03:48:2c:65)
    > Source: Cisco_8d:98:70 (00:09:7b:8d:98:70)
    > Type: IP (0x0800)
    > Trailer: 000000000000


    The packet comes from your DSL box to the computer,
    but claims to be from local host. The Ethernet
    addresses can be trusted here, everything else
    seems to be fake.

    > Internet Protocol, Src: 127.0.0.1 (127.0.0.1), Dst: 80.219.238.182
    > (80.219.238.182)
    > Version: 4
    > Header length: 20 bytes
    > Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    > 0000 00.. = Differentiated Services Codepoint: Default (0x00)
    > .... ..0. = ECN-Capable Transport (ECT): 0
    > .... ...0 = ECN-CE: 0
    > Total Length: 40
    > Identification: 0x25b1 (9649)
    > Flags: 0x00
    > 0... = Reserved bit: Not set
    > .0.. = Don't fragment: Not set
    > ..0. = More fragments: Not set
    > Fragment offset: 0
    > Time to live: 126
    > Protocol: TCP (0x06)
    > Header checksum: 0x5d81 [correct]
    > Good: True
    > Bad : False
    > Source: 127.0.0.1 (127.0.0.1)
    > Destination: 80.219.238.182 (80.219.238.182)
    > Transmission Control Protocol, Src Port: http (80), Dst Port:
    > eicon-server (1438), Seq: 0, Ack: 0, Len: 0
    > Source port: http (80)
    > Destination port: eicon-server (1438)
    > Sequence number: 0 (relative sequence number)
    > Acknowledgement number: 0 (relative ack number)
    > Header length: 20 bytes
    > Flags: 0x0014 (RST, ACK)
    > 0... .... = Congestion Window Reduced (CWR): Not set
    > .0.. .... = ECN-Echo: Not set
    > ..0. .... = Urgent: Not set
    > ...1 .... = Acknowledgment: Set
    > .... 0... = Push: Not set
    > .... .1.. = Reset: Set
    > .... ..0. = Syn: Not set
    > .... ...0 = Fin: Not set
    > Window size: 0
    > Checksum: 0x796e [correct]


    This claims to be a reset packet for a non-existing connection.

    IIRC, there is a port scanning tool in circulation which
    probes the targets with non-existent resets, but AFAIK, it
    works only in the local network due to the fake sender IP.

    It may be looking for a Web server to crack or maybe for
    p2p traffic piggy-backed on a Web request.


    >>Check for any open ports
    >>with:
    >>
    >> netstat -tupan

    >
    >
    > Active Internet connections (servers and established)
    > Proto Recv-Q Send-Q Local Address Foreign Address
    > State PID/Program name
    > tcp 0 0 0.0.0.0:32769 0.0.0.0:*
    > LISTEN -
    > tcp 0 0 0.0.0.0:111 0.0.0.0:*
    > LISTEN 6436/portmap
    > tcp 0 0 127.0.0.1:948 0.0.0.0:*
    > LISTEN 7556/fam
    > tcp 0 0 :::22 :::*
    > LISTEN 7074/sshd
    > udp 0 0 0.0.0.0:1042 0.0.0.0:*
    > -
    > udp 0 0 0.0.0.0:68 0.0.0.0:*
    > 6211/dhcpcd
    > udp 0 0 0.0.0.0:111 0.0.0.0:*
    > 6436/portmap
    > udp 0 0 192.168.200.1:123 0.0.0.0:*
    > 7004/ntpd
    > udp 0 0 80.219.238.182:123 0.0.0.0:*
    > 7004/ntpd
    > udp 0 0 192.168.100.10:123 0.0.0.0:*
    > 7004/ntpd
    > udp 0 0 127.0.0.1:123 0.0.0.0:*
    > 7004/ntpd
    > udp 0 0 0.0.0.0:123 0.0.0.0:*
    > 7004/ntpd
    > udp 0 0 :::123 :::*
    > 7004/ntpd
    >
    > However, all NEW connections of any protocol to the firewall from
    > outside are dropped.


    This is OK - seems clean.

    >>In principle, the kernel considers a packet martian if its
    >>source address is obviously incorrect for the interface it's
    >>coming in.

    >
    >
    > I thought so, that is why i want to know what is going on in this case.


    See above.

    ----

    It seems to me that your firewall and the martian trap
    have done their job and the attackers are failing.

    HTH

    Best regards from Helsinki, the home city of Linux!

    --

    Tauno Voipio
    tauno voipio (at) iki fi

  12. Re: mystery martian source from 127.0.0.1 - more details

    Tauno Voipio wrote:
    >
    > It seems to me that your firewall and the martian trap
    > have done their job and the attackers are failing.


    Thanks so much Tauno!

    Still, something is not clear to me, why is iptables not logging these
    packets? If they come from the router (outside for my firewall),
    iptables should catch'em, since tcpdump recognizes them.

    greetz,
    Eric

  13. Re: mystery martian source from 127.0.0.1

    Moe Trin wrote:
    > [compton ~]$ etherwhois 00:09:7b
    > 00-09-7B (hex) Cisco Systems
    > 00097B (base 16) Cisco Systems
    > 80 West Tasman Dr.
    > SJ-M/1
    > San Jose CA 95134
    > UNITED STATES
    > [compton ~]$
    >
    > Probably your cable modem or DSL router. You'd have to look at the TTLa
    > to see if that's the source, or the crap is really coming from "outside".


    seems logical. but sorry, what do you mean by looking at the TTLa, it's
    martian to me ;-).

    Eric

  14. Re: mystery martian source from 127.0.0.1

    On Fri, 09 Dec 2005, in the Usenet newsgroup comp.os.linux.security, in article
    , EricT wrote:

    >Moe Trin wrote:


    >> Probably your cable modem or DSL router. You'd have to look at the TTLa
    >> to see if that's the source, or the crap is really coming from "outside".


    >seems logical. but sorry, what do you mean by looking at the TTLa, it's
    >martian to me ;-).


    The TTL field in the IP header (9th byte) gives clues how far away the
    packet came from. It is NORMALLY decremented at each hop - and the
    starting values tend to be nice round numbers. For example,

    0045 Version 4, Header Length 5, TOS 0
    ec01 IP length 0x01ec = 492
    0000 ID
    0040 flags = DF, frag offset 0
    1130 ttl 0x30 = 48, proto 11 = UDP
    5982 hdr chksum
    42da ce68 source addr 218.66.104.206
    00c0 a702 dest.addr 192.0.2.167
    4fbd source port 48463
    0604 dest port 1030
    d801 UDP length 0x01d8 = 472
    1ef8 UDP check sum

    NOTE: WATCH THE BYTE ORDER!!! This is printed odd-even (1,0 3,2, 5,4 etc.)
    in this raw tcpdump output. This happens to be a windoze messenger spam.

    In this example, the TTL is 0x30 which is 48 decimal. As the world is
    generally smaller than 40 hops (traceroute usually is set for 30 max),
    this packet PROBABLY started life with a TTL of 64 decimal, allowing a
    guess that the source is 16 hops away. Given my network layout (number
    of hops between perimeter and this host), this is not an unrealistic
    number.

    As mentioned above, TTLs tend to start as nice round numbers - like
    1, 30, 32, 60, 64, 128, and 255 (which would be the max). A TTL of 1
    is a local-only packet, like ZeroConf (169.254.0.0/16, also known as
    'LinkLocal', or 'APIPA' - Automatic Private IP Addressing) or a lot
    of the Multicast stuff (224.0.0.0/4). A network fingerprinting tool I
    often use lists only 32, 60, 64, 128, and 255 as being in common use
    by systems today. Note, however, that nothing specifically REQUIRES an
    O/S to use a specific ttl - indeed 'traceroute' works by seeing what
    host reports 'ttl=0', and incrementing the starting value until the
    packets reach the destination.

    In another posting, you included a snippet of a tcpdump

    >20:42:25.782992 IP (tos 0x0, ttl 126, id 10724, offset 0, flags [none],
    >length: 40) localhost.http > 80-219-238-182.dclient.hispeed.ch.stun-p3:
    >R [tcp sum ok] 0:0(0) ack 1704591361 win 0


    First line - 'ttl 126;'. This _suggests_ that the packet started out with
    a ttl of 128. What do you see when you try to connect to your Cisco - use
    anything, such as 'telnet IP.ADDR.OF.CISCO 70' which will try to connect
    to the (hopefully non-existent) 'gopher' server on the Cisco. What ttls do
    you see in the packets directly from it?

    Old guy

  15. Re: mystery martian source from 127.0.0.1

    Moe Trin wrote:
    > The TTL field in the IP header (9th byte) gives clues how far away the
    > packet came from. It is NORMALLY decremented at each hop - and the
    > starting values tend to be nice round numbers. For example,
    >
    > 0045 Version 4, Header Length 5, TOS 0
    > ec01 IP length 0x01ec = 492
    > 0000 ID
    > 0040 flags = DF, frag offset 0
    > 1130 ttl 0x30 = 48, proto 11 = UDP
    > 5982 hdr chksum
    > 42da ce68 source addr 218.66.104.206
    > 00c0 a702 dest.addr 192.0.2.167
    > 4fbd source port 48463
    > 0604 dest port 1030
    > d801 UDP length 0x01d8 = 472
    > 1ef8 UDP check sum
    >
    > NOTE: WATCH THE BYTE ORDER!!! This is printed odd-even (1,0 3,2, 5,4 etc.)
    > in this raw tcpdump output. This happens to be a windoze messenger spam.
    >
    > In this example, the TTL is 0x30 which is 48 decimal. As the world is
    > generally smaller than 40 hops (traceroute usually is set for 30 max),
    > this packet PROBABLY started life with a TTL of 64 decimal, allowing a
    > guess that the source is 16 hops away. Given my network layout (number
    > of hops between perimeter and this host), this is not an unrealistic
    > number.
    >
    > As mentioned above, TTLs tend to start as nice round numbers - like
    > 1, 30, 32, 60, 64, 128, and 255 (which would be the max). A TTL of 1
    > is a local-only packet, like ZeroConf (169.254.0.0/16, also known as
    > 'LinkLocal', or 'APIPA' - Automatic Private IP Addressing) or a lot
    > of the Multicast stuff (224.0.0.0/4). A network fingerprinting tool I
    > often use lists only 32, 60, 64, 128, and 255 as being in common use
    > by systems today. Note, however, that nothing specifically REQUIRES an
    > O/S to use a specific ttl - indeed 'traceroute' works by seeing what
    > host reports 'ttl=0', and incrementing the starting value until the
    > packets reach the destination.


    Ahh, i see, thanks a lot for the detailed explanation.

    >
    > In another posting, you included a snippet of a tcpdump
    >
    >
    >>20:42:25.782992 IP (tos 0x0, ttl 126, id 10724, offset 0, flags [none],
    >>length: 40) localhost.http > 80-219-238-182.dclient.hispeed.ch.stun-p3:
    >>R [tcp sum ok] 0:0(0) ack 1704591361 win 0

    >
    >
    > First line - 'ttl 126;'. This _suggests_ that the packet started out with
    > a ttl of 128. What do you see when you try to connect to your Cisco - use
    > anything, such as 'telnet IP.ADDR.OF.CISCO 70' which will try to connect
    > to the (hopefully non-existent) 'gopher' server on the Cisco. What ttls do
    > you see in the packets directly from it?


    I am using a cable modem which actually is a black box. There's no way
    to connect to it by telnet, http, ssh or whatever. Well, probably there
    is a way, but i do not know how.
    The first hop while tracerouting any ip will always show up as (* * *):

    traceroute to www.highspeed.ch (62.2.16.81), 30 hops max, 40 byte packets
    1 * * *
    2 tengig-11-0.blxZHZ002.gw.cablecom.net (62.2.33.1) 15.923 ms
    14.075 ms 16.747 ms
    ....


    A ping to the cablecom gateway will show:

    PING tengig-11-0.blxZHZ002.gw.cablecom.net (62.2.33.1) 56(84) bytes of data.
    64 bytes from tengig-11-0.blxZHZ002.gw.cablecom.net (62.2.33.1):
    icmp_seq=1 ttl=252 time=8.48 ms


    The MAC of the modem (shown on a label in the back of it) is far
    different than the one shown in the martian packets.

    greetz,
    Eric

  16. Re: mystery martian source from 127.0.0.1 - more details

    EricT wrote:
    >
    > Frame 1 (60 bytes on wire, 60 bytes captured)
    > Arrival Time: Dec 8, 2005 22:33:57.-11226009
    > Time delta from previous packet: 0.000000000 seconds
    > Time since reference or first frame: 0.000000000 seconds
    > Frame Number: 1
    > Packet Length: 60 bytes
    > Capture Length: 60 bytes
    > Protocols in frame: eth:ip:tcp
    > Ethernet II, Src: Cisco_8d:98:70 (00:09:7b:8d:98:70), Dst: 3com_48:2c:65
    > (00:01:03:48:2c:65)
    > Destination: 3com_48:2c:65 (00:01:03:48:2c:65)
    > Source: Cisco_8d:98:70 (00:09:7b:8d:98:70)
    > Type: IP (0x0800)
    > Trailer: 000000000000
    > Internet Protocol, Src: 127.0.0.1 (127.0.0.1), Dst: 80.219.238.182
    > (80.219.238.182)
    > Version: 4
    > Header length: 20 bytes
    > Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    > 0000 00.. = Differentiated Services Codepoint: Default (0x00)
    > .... ..0. = ECN-Capable Transport (ECT): 0
    > .... ...0 = ECN-CE: 0
    > Total Length: 40
    > Identification: 0x25b1 (9649)
    > Flags: 0x00
    > 0... = Reserved bit: Not set
    > .0.. = Don't fragment: Not set
    > ..0. = More fragments: Not set
    > Fragment offset: 0
    > Time to live: 126
    > Protocol: TCP (0x06)
    > Header checksum: 0x5d81 [correct]
    > Good: True
    > Bad : False
    > Source: 127.0.0.1 (127.0.0.1)
    > Destination: 80.219.238.182 (80.219.238.182)
    > Transmission Control Protocol, Src Port: http (80), Dst Port:
    > eicon-server (1438), Seq: 0, Ack: 0, Len: 0
    > Source port: http (80)
    > Destination port: eicon-server (1438)
    > Sequence number: 0 (relative sequence number)
    > Acknowledgement number: 0 (relative ack number)
    > Header length: 20 bytes
    > Flags: 0x0014 (RST, ACK)
    > 0... .... = Congestion Window Reduced (CWR): Not set
    > .0.. .... = ECN-Echo: Not set
    > ..0. .... = Urgent: Not set
    > ...1 .... = Acknowledgment: Set
    > .... 0... = Push: Not set
    > .... .1.. = Reset: Set
    > .... ..0. = Syn: Not set
    > .... ...0 = Fin: Not set
    > Window size: 0
    > Checksum: 0x796e [correct]
    >
    > ...


    I've seen lots of poorly-configured BMC Patrol agents send crap with
    source addresses 127.0.0.1 out non-lo interfaces. Since the R flag is
    set here and since there's no data, I doubt it's an attack. Somebody
    close to you (i.e., in your neighborhood and on the same cable system)
    probably just has a stupidly-configured web server on their host or a
    stupidly-configured NAT behind their cable modem.

    The more interesting question is HOW they got YOUR address. Have you
    been sweeping the neighborhood looking for web servers (maybe without
    knowing it)?

  17. Reply to all posters: mystery martian source from 127.0.0.1

    I figured out, which system is responsible for these martian packets.

    The MAC belongs to the gateway of my ISP. I listened to the traffic of
    the cablecom net and this particular gateway is routing or forwarding or
    sending broadcasts (67 -> 68), which my firewall dropped without
    logging. Now after monitoring all the traffic, i have seen the MAC (and
    ip) in any packet of this type.

    a traceroute to that ip will show this:
    traceroute to 80.219.88.1 (80.219.88.1), 30 hops max, 40 byte packets
    1 * * *
    2 * * *
    3 * * *
    ....
    28 * * *
    29 * * *
    30 * * *

    After calling the ISP, they do not seem to be very interested in this
    matter.
    I still do not know what (in detail) causes the martian packets, but i
    know where they come from and actually it is not my business anymore ;-).

    Thanks a lot to all of you!

    greetz,
    Eric

  18. Re: Reply to all posters: mystery martian source from 127.0.0.1

    EricT wrote:
    > I figured out, which system is responsible for these martian packets.
    >
    > The MAC belongs to the gateway of my ISP. I listened to the traffic of
    > the cablecom net and this particular gateway is routing or forwarding or
    > sending broadcasts (67 -> 68), which my firewall dropped without
    > logging. Now after monitoring all the traffic, i have seen the MAC (and
    > ip) in any packet of this type.
    >


    If the packets are UDP ports 67 and 68, they are DHCP
    and / or BOOTP, probably autoconfiguration by the ISP.

    A DHCP client starts by broadcasting a request for
    any DHCP server to announce itself. If the cable modems
    are arranged into a LAN subnet, you'll see the DHCP
    packets for the whole subnet.

    --

    Tauno Voipio
    tauno voipio (at) iki fi

  19. Re: Reply to all posters: mystery martian source from 127.0.0.1

    Tauno Voipio wrote:
    > A DHCP client starts by broadcasting a request for
    > any DHCP server to announce itself. If the cable modems
    > are arranged into a LAN subnet, you'll see the DHCP
    > packets for the whole subnet.
    >


    That's exactly how it is set up. I see all the broadcasts and block
    them, still the 127.0.0.1 packets are a mystery.

    Thanks Tauno

  20. Re: mystery martian source from 127.0.0.1

    On Sat, 10 Dec 2005, in the Usenet newsgroup comp.os.linux.security, in article
    , EricT wrote:

    >Moe Trin wrote:


    >> What do you see when you try to connect to your Cisco - use anything,
    >> such as 'telnet IP.ADDR.OF.CISCO 70' which will try to connect to the
    >> (hopefully non-existent) 'gopher' server on the Cisco. What ttls do
    >> you see in the packets directly from it?

    >
    >I am using a cable modem which actually is a black box. There's no way
    >to connect to it by telnet, http, ssh or whatever. Well, probably there
    >is a way, but i do not know how.


    Find some command lines - in one, run 'tcpdump -ni eth0' to watch the
    traffic on your eth0 interface. In another, run the command '/sbin/arp -a'
    and (assuming you have been using the network recently), there should be
    a line looking something like

    - at 00:09:7b:8d:98:70 on eth0

    If there is nothing there, ping anything - which will generate traffic
    over the link through the modem, and then look again.

    That IP address is your modem. Now, telnet to that address as above,
    and look at where you are running the tcpdump - you should see some
    activity - look for a 'ttl' in the line where your router tells you to
    go away and not bother it.

    >The first hop while tracerouting any ip will always show up as (* * *):


    You'd have to look at the tcpdump while doing this. Some of these POS
    are configured to not sent ICMP errors, and that is what traceroute
    depends on. Note - I'm assuming a UNIX style traceroute which uses UDP
    to ports > 33434, and not the b0rken microsoft imitation which uses ICMP
    type 8 (ping).

    >A ping to the cablecom gateway will show:
    >
    >PING tengig-11-0.blxZHZ002.gw.cablecom.net (62.2.33.1) 56(84) bytes of data.
    >64 bytes from tengig-11-0.blxZHZ002.gw.cablecom.net (62.2.33.1):
    >icmp_seq=1 ttl=252 time=8.48 ms


    Again - ttl=252. The gateway is probably three hops away, starting value
    was 255.

    >The MAC of the modem (shown on a label in the back of it) is far
    >different than the one shown in the martian packets.


    The martian was showing 00:09:7b:8d:98:70 which is a Cisco - what does the
    label say? Cisco has (as of early October) 271 different blocks of MAC
    addresses from 00:00:0c to 00:e0:fe

    Old guy

+ Reply to Thread
Page 1 of 2 1 2 LastLast