spoofed ICMP packets

spoofed ICMP packets

Post by berdz » Mon, 11 Nov 2002 05:58:31



Hi all

Two days ago I found strange entries in my logs.

Nov  9 00:20:28 netserver kernel: Packet log: input ACCEPT ppp0 PROTO=1
207.96.162.42:3 80.49.148.154:3 L=56 S=0x00 I=47665 F=0x0000 T=237 (#25)
Nov  9 00:21:01 netserver kernel: Packet log: input ACCEPT ppp0 PROTO=1
10.167.200.1:3 80.49.148.154:1 L=56 S=0x00 I=16313 F=0x0000 T=240 (#25)
Nov  9 00:21:01 netserver kernel: Packet log: input ACCEPT ppp0 PROTO=1
10.167.200.1:3 80.49.148.154:1 L=56 S=0x00 I=43763 F=0x0000 T=240 (#25)

I started tcpdump and caught some of these strange packets.

10:47:53.375433 10.167.200.1 > 80.49.148.154: icmp: host 12.248.110.219
unreachable
0x0000   4500 0038 5e53 0000 f001 b4fd 0aa7 c801        E..8^S..........
0x0010   5031 949a 0301 1e55 0000 0000 4500 0030        P1.....U....E..0

0x0030   f6fc 0684 003e e0ea                            .....>..

The strange thing is that they send with source 10.167.200.1 which
belongs to range of IPs reserved for LANs and I receive them on
interface ppp0 which is my internet interface.
The second strange thing is that the replies are sent to 12.248.110.219,
which , I checked, belongs to AT&T WorldNet Services:

OrgName:    AT&T WorldNet Services
OrgID:      ATTW

NetRange:   12.0.0.0 - 12.255.255.255
CIDR:       12.0.0.0/8

It looks like somebody is using my server to perform some kind of icmp
flooding against AT&T by spoofing ICMP packets.

Any ideas?

 
 
 

spoofed ICMP packets

Post by ynotsso » Mon, 11 Nov 2002 08:44:23



> Hi all
> Two days ago I found strange entries in my logs.
> Nov  9 00:20:28 netserver kernel: Packet log: input ACCEPT ppp0 PROTO=1
> 207.96.162.42:3 80.49.148.154:3 L=56 S=0x00 I=47665 F=0x0000 T=237 (#25)
> Nov  9 00:21:01 netserver kernel: Packet log: input ACCEPT ppp0 PROTO=1
> 10.167.200.1:3 80.49.148.154:1 L=56 S=0x00 I=16313 F=0x0000 T=240 (#25)
> Nov  9 00:21:01 netserver kernel: Packet log: input ACCEPT ppp0 PROTO=1
> 10.167.200.1:3 80.49.148.154:1 L=56 S=0x00 I=43763 F=0x0000 T=240 (#25)

> I started tcpdump and caught some of these strange packets.
> 10:47:53.375433 10.167.200.1 > 80.49.148.154: icmp: host 12.248.110.219
> unreachable
> 0x0000   4500 0038 5e53 0000 f001 b4fd 0aa7 c801        E..8^S..........
> 0x0010   5031 949a 0301 1e55 0000 0000 4500 0030        P1.....U....E..0

> 0x0030   f6fc 0684 003e e0ea                            .....>..

> The strange thing is that they send with source 10.167.200.1 which
> belongs to range of IPs reserved for LANs and I receive them on
> interface ppp0 which is my internet interface.
> The second strange thing is that the replies are sent to 12.248.110.219,
> which , I checked, belongs to AT&T WorldNet Services:
[...]
> It looks like somebody is using my server to perform some kind of icmp
> flooding against AT&T by spoofing ICMP packets.

> Any ideas?

Certainly these are but brief sampling of the logged entries, judging by the
timestamps? We'll get back to this point.

There are 2 addresses of concern, one a source the other a destination; the
10.167.200.1 can be effectively ignored for now. Let's see what they are:

$ echo -e "207.96.162.42\n12.248.110.219" | jdresolve -r -n -
ce042-ia-cduc-bb01-se2-0-0-20.vtl.net
12-248-110-219.client.attbi.com

The source address is registered in the vicinity of Montreal QU Canada, the
destination address near Parsippany NJ USA.

Most probably a residential user, possibly DHCP. The source ports were all
"3" in your posted entries, the destination ports "1" and "3" on your interface.
Were there other entries for other ports on your machine?

Now the point I would like to make is that many port scanning utilities allow
the use of "decoy" addresses (in addition to the real one) to make it appear
that your machine is being scanned by several IPs, and one usually doesn't
know which one is the real culprit. One can use the private non-routable
addresses or even 127.0.0.1 as a decoy, but using many such non-routable
decoys with just the one valid IP makes it somewhat easier to spot in the
logs.

12.248.110.219 may be a culprit or a decoy, and just be blocking ICMP
packets or not even "up" at all.

So to sum up, I wouldn't worry too much about the results you've recorded.
The analytics you have performed have given a lot of detail that can make
a little more sense if one considers other things in the context of your entire
body of evidence, rather than just what you posted here.

         tony

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----

 
 
 

spoofed ICMP packets

Post by ynotsso » Mon, 11 Nov 2002 08:55:25


[...]
Quote:> So to sum up, I wouldn't worry too much about the results you've recorded.

[...]

Except that rather than ACCEPTing spoofed packets as your iptables(?) has
done, you drop them, vis vis:

 ## SPOOFING
# Most of this anti-spoofing stuff is theoretically not really necessary with the flags we
# have set in the kernel above ........... but you never know there isn't a bug somewhere in
# your IP stack.
#
# Refuse spoofed packets pretending to be from your IP address.
iptables -A INPUT  -i $IFACE -s $IPADDR -j DROP
# Refuse packets claiming to be from a Class A private network.
iptables -A INPUT  -i $IFACE -s $CLASS_A -j DROP
# Refuse packets claiming to be from a Class B private network.
iptables -A INPUT  -i $IFACE -s $CLASS_B -j DROP
# Refuse packets claiming to be from a Class C private network.
iptables -A INPUT  -i $IFACE -s $CLASS_C -j DROP
# Refuse Class D multicast addresses. Multicast is illegal as a source address.
iptables -A INPUT -i $IFACE -s $CLASS_D_MULTICAST -j DROP
# Refuse Class E reserved IP addresses.
iptables -A INPUT -i $IFACE -s $CLASS_E_RESERVED_NET -j DROP
# Refuse packets claiming to be to the loopback interface.
# Refusing packets claiming to be to the loopback interface protects against
# source quench, whereby a machine can be told to slow itself down by an icmp source
# quench to the loopback.
iptables -A INPUT  -i $IFACE -d $LOOPBACK -j DROP
# Refuse broadcast address packets.
iptables -A INPUT -i $IFACE -d $BROADCAST -j DROP

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----

 
 
 

spoofed ICMP packets

Post by berdz » Mon, 11 Nov 2002 19:57:38




>>Hi all
>>Two days ago I found strange entries in my logs.
>>Nov  9 00:20:28 netserver kernel: Packet log: input ACCEPT ppp0 PROTO=1
>>207.96.162.42:3 80.49.148.154:3 L=56 S=0x00 I=47665 F=0x0000 T=237 (#25)
>>Nov  9 00:21:01 netserver kernel: Packet log: input ACCEPT ppp0 PROTO=1
>>10.167.200.1:3 80.49.148.154:1 L=56 S=0x00 I=16313 F=0x0000 T=240 (#25)
>>Nov  9 00:21:01 netserver kernel: Packet log: input ACCEPT ppp0 PROTO=1
>>10.167.200.1:3 80.49.148.154:1 L=56 S=0x00 I=43763 F=0x0000 T=240 (#25)

>>I started tcpdump and caught some of these strange packets.
>>10:47:53.375433 10.167.200.1 > 80.49.148.154: icmp: host 12.248.110.219
>>unreachable
>>0x0000   4500 0038 5e53 0000 f001 b4fd 0aa7 c801        E..8^S..........
>>0x0010   5031 949a 0301 1e55 0000 0000 4500 0030        P1.....U....E..0

>>0x0030   f6fc 0684 003e e0ea                            .....>..

>>The strange thing is that they send with source 10.167.200.1 which
>>belongs to range of IPs reserved for LANs and I receive them on
>>interface ppp0 which is my internet interface.
>>The second strange thing is that the replies are sent to 12.248.110.219,
>>which , I checked, belongs to AT&T WorldNet Services:

> [...]

>>It looks like somebody is using my server to perform some kind of icmp
>>flooding against AT&T by spoofing ICMP packets.

>>Any ideas?

> Certainly these are but brief sampling of the logged entries, judging by the
> timestamps? We'll get back to this point.

I haven't captured much of them and most of them are identical except
ports which are 1 or 3.

Quote:> There are 2 addresses of concern, one a source the other a destination; the
> 10.167.200.1 can be effectively ignored for now. Let's see what they are:

> $ echo -e "207.96.162.42\n12.248.110.219" | jdresolve -r -n -
> ce042-ia-cduc-bb01-se2-0-0-20.vtl.net
> 12-248-110-219.client.attbi.com

> The source address is registered in the vicinity of Montreal QU Canada, the
> destination address near Parsippany NJ USA.

How did you discover that? AFAIK 10.0.0.0/8 class is reverved for local
area networks, invisible outside unless spoofed.

- Show quoted text -

Quote:> Most probably a residential user, possibly DHCP. The source ports were all
> "3" in your posted entries, the destination ports "1" and "3" on your interface.
> Were there other entries for other ports on your machine?

> Now the point I would like to make is that many port scanning utilities allow
> the use of "decoy" addresses (in addition to the real one) to make it appear
> that your machine is being scanned by several IPs, and one usually doesn't
> know which one is the real culprit. One can use the private non-routable
> addresses or even 127.0.0.1 as a decoy, but using many such non-routable
> decoys with just the one valid IP makes it somewhat easier to spot in the
> logs.

> 12.248.110.219 may be a culprit or a decoy, and just be blocking ICMP
> packets or not even "up" at all.

> So to sum up, I wouldn't worry too much about the results you've recorded.
> The analytics you have performed have given a lot of detail that can make
> a little more sense if one considers other things in the context of your entire
> body of evidence, rather than just what you posted here.

>          tony

> -----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
> http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
> -----==  Over 80,000 Newsgroups - 16 Different Servers! =-----

 
 
 

spoofed ICMP packets

Post by Michael Fu » Tue, 12 Nov 2002 00:19:31



> Two days ago I found strange entries in my logs.

> Nov  9 00:20:28 netserver kernel: Packet log: input ACCEPT ppp0 PROTO=1
> 207.96.162.42:3 80.49.148.154:3 L=56 S=0x00 I=47665 F=0x0000 T=237 (#25)
> Nov  9 00:21:01 netserver kernel: Packet log: input ACCEPT ppp0 PROTO=1
> 10.167.200.1:3 80.49.148.154:1 L=56 S=0x00 I=16313 F=0x0000 T=240 (#25)
> Nov  9 00:21:01 netserver kernel: Packet log: input ACCEPT ppp0 PROTO=1
> 10.167.200.1:3 80.49.148.154:1 L=56 S=0x00 I=43763 F=0x0000 T=240 (#25)

> I started tcpdump and caught some of these strange packets.

> 10:47:53.375433 10.167.200.1 > 80.49.148.154: icmp: host 12.248.110.219
> unreachable
> 0x0000   4500 0038 5e53 0000 f001 b4fd 0aa7 c801        E..8^S..........
> 0x0010   5031 949a 0301 1e55 0000 0000 4500 0030        P1.....U....E..0

> 0x0030   f6fc 0684 003e e0ea                            .....>..
> The strange thing is that they send with source 10.167.200.1 which
> belongs to range of IPs reserved for LANs and I receive them on
> interface ppp0 which is my internet interface.

RFC 1918 reserves 10.0.0.0/8 for private networks, but that doesn't
prevent people from using this address space on systems with Internet
connectivity.  For example, some companies use private addresses
on router interfaces, since the non-routability of these addresses
on the Internet is irrelevant for their purposes.

The packet above appears to be a network device at 10.167.200.1 telling
a machine at 80.49.148.154 (presumably you) that the host 12.248.110.219
is unreachable.  Do a traceroute to 12.248.110.219 and you should see
something like this at the last few hops:

13  12.244.72.229 (12.244.72.229)  57.249 ms  57.309 ms  57.374 ms
14  10.167.200.1 (10.167.200.1)  58.278 ms  58.199 ms  58.112 ms
15  10.167.200.1 (10.167.200.1)  863.295 ms !H *  613.300 ms !H

It looks like one of the routers at AT&T is using 10.167.200.1 as
one of its interface addresses.

Quote:> The second strange thing is that the replies are sent to 12.248.110.219,

No they aren't: the replies are being sent to 80.49.148.154 and are
saying that 12.248.110.219 is unreachable.

Quote:> which , I checked, belongs to AT&T WorldNet Services:

> OrgName:    AT&T WorldNet Services
> OrgID:      ATTW

> NetRange:   12.0.0.0 - 12.255.255.255
> CIDR:       12.0.0.0/8

> It looks like somebody is using my server to perform some kind of icmp
> flooding against AT&T by spoofing ICMP packets.

That could be what's happening, but the information you've provided
isn't sufficient to arrive at that conclusion.  The packet shown
in your tcpdump implies that you're trying to communicate with
12.248.110.219 but you're being informed by the router at 10.167.200.1
that that host is unreachable.  Although the router's address is
in private space, the traceroute I did shows that there is indeed
a router on AT&T's network with that address, and that it sends out
ICMP Host Unreachable packets when you try to communicate with
12.248.110.219.

Have you sniffed your interface to see if you're sending anything
to 12.248.110.219?  If you have and if you saw nothing, then somebody
might be spoofing your IP address on packets sent to 12.248.110.219.
Since that host is unreachable, you're receiving the ICMP Host
Unreachable messages.  You might be able to see what kind of
connection is being attempted by adding "-s0 -vv" to your tcpdump
flags -- the "-s0" flag tells tcpdump to capture entire packets
instead of just the first part of packets, and the "-vv" flag tells
tcpdump to be more verbose in what it prints.  These two flags may
give you something like this:

10:47:53.375433 10.167.200.1 > 80.49.148.154: icmp: host 12.248.110.219
unreachable for 80.49.148.154.9999 > 12.248.110.219.80: [|tcp]

If you perform a tcpdump with these flags and get any more info,
post it here and we'll take a look.

Hope this helps.

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

 
 
 

spoofed ICMP packets

Post by ynotsso » Tue, 12 Nov 2002 02:29:35



>> $ echo -e "207.96.162.42\n12.248.110.219" | jdresolve -r -n -
>> ce042-ia-cduc-bb01-se2-0-0-20.vtl.net
>> 12-248-110-219.client.attbi.com

>> The source address is registered in the vicinity of Montreal QU Canada, the
>> destination address near Parsippany NJ USA.

> How did you discover that? AFAIK 10.0.0.0/8 class is reverved for local
> area networks, invisible outside unless spoofed.

I believe I explained later how they were probably spoofed.

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----

 
 
 

1. spoofed ICMP packets

Hi all

Two days ago I found strange entries in my logs.

Nov  9 00:20:28 netserver kernel: Packet log: input ACCEPT ppp0 PROTO=1
207.96.162.42:3 80.49.148.154:3 L=56 S=0x00 I=47665 F=0x0000 T=237 (#25)
Nov  9 00:21:01 netserver kernel: Packet log: input ACCEPT ppp0 PROTO=1
10.167.200.1:3 80.49.148.154:1 L=56 S=0x00 I=16313 F=0x0000 T=240 (#25)
Nov  9 00:21:01 netserver kernel: Packet log: input ACCEPT ppp0 PROTO=1
10.167.200.1:3 80.49.148.154:1 L=56 S=0x00 I=43763 F=0x0000 T=240 (#25)

I started tcpdump and caught some of these strange packets.

10:47:53.375433 10.167.200.1 > 80.49.148.154: icmp: host 12.248.110.219
unreachable
0x0000   4500 0038 5e53 0000 f001 b4fd 0aa7 c801        E..8^S..........
0x0010   5031 949a 0301 1e55 0000 0000 4500 0030        P1.....U....E..0

0x0030   f6fc 0684 003e e0ea                            .....>..

The strange thing is that they send with source 10.167.200.1 which
belongs to range of IPs reserved for LANs and I receive them on
interface ppp0 which is my internet interface.
The second strange thing is that the replies are sent to 12.248.110.219,
which , I checked, belongs to AT&T World:

OrgName:    AT&T WorldNet Services
OrgID:      ATTW

NetRange:   12.0.0.0 - 12.255.255.255
CIDR:       12.0.0.0/8

It looks like somebody is using my server to perform some kind of icmp
flooding against AT&T by spoofing ICMP packets.

Any ideas?

2. probe nic

3. ICMP Spoofing?

4. Linux Stability Questioned - Refuted

5. Tracing spoofed packets

6. Newbie Questions about AIX and WindowsNT

7. why do spoofed packets cause arp entries

8. Filters ??

9. "Reverse routing" - a solution for spoofed packets

10. Spoofed broadcast packets to port 53?

11. Any way to trace spoofed packets???

12. spoofed packets and portsentry...

13. spoofed http packets