Re: strange packets from 192.168.1.126
- From: ibuprofin@xxxxxxxxxxxxxxxxxxxxxx (Moe Trin)
- Date: Fri, 22 Feb 2008 14:07:23 -0600
On Thu, 21 Feb 2008, in the Usenet newsgroup comp.security.firewalls, in article
<846dc3a1-a3fe-4145-bd6e-235db18e794a@xxxxxxxxxxxxxxxxxxxxxxxxxxx>, Kevin VW
wrote:
I've recently noticed some packets coming in on port 22 (sshd) on my
external interface from the 192.168.1.0/24 network. I don't have any
local machines on this network and the packets are coming in on my WAN
interface (via my router). How is that possible?
By the "WAN interface", I'm assuming you really mean that interface
that is connected to the ISP, rather than a network under your (or
your companies) control. It probably means someone "down the street"
or somewhere else in town has a misconfigured (and probably 0wn3d)
box. It's highly unlikely to be outside of your "local" area, because
the routers connecting (example) 71.179.0.0/16 to the rest of the
ARIN block 71.160.0.0/11 would be dropping these packets as neither
source or destination IP are routable.
My understanding was that this network was not routeable from the
internet.
"internet" verses "Internet" - really are two different things. The
lower case word means the group of networks assigned/allocated to your
ISP. They can (and may well) use those IP ranges for "internal"
services not meant to be accessed from outside of their ranges. One of
my ISPs uses 192.168.170.x for the DNS, web, and mail servers that are
accessed by the customers directly. If you are outside, you can't
reach these services, nor are you expected to access them. Outsiders
access these services using "regular" addresses. The capitalized
word "Internet" means "the entire world", and includes ALL ISPs and
similar. RFC3330 (which refers to RFC1918) sets aside certain blocks
of addresses that are meant for "private use", and which should not
leave/enter the perimeter of an allocation/assignment. Thus, every
provider in the world could have hosts using 192.168.1.1 and there
is no confusion, because packets to/from that address get dropped at
the perimeter.
I'm guessing someone is try to get at my sshd server.
Possibly. See RFC2827 (and 3704), and block the RFC3330 ranges unless
you specifically know that something your ISP is using is on one of
those addresses. Actually, it's generally considered smart not to
allow connections from all 2,586,651,004 IPv4 addresses that are
allocated or assigned in the world as of last week. I know that the
only valid users who will be attempting to connect to my systems will
be on one of 1536 addresses (a /22 and 2 /24s) in the entire world. My
systems, MY RULES. Users in the rest of the world can shove it where
the sun don't shine if they don't like that.
Below are the packets. Is there any way to get more info on where
they are coming from?
Not really - this actually looks like some 37337 h4x0r-dude is playing
with nmap. You could bitch at your provider, but I don't know how much
(if any) good that would do.
Feb 20 20:02:14 tti kernel: iptables chain hostile: IN=eth1 OUT=
MAC=00:0e:0c:dd:73:16:00:11:6e:00:f9:70:08:00
See RFC0894. 00:0e:0c:dd:73:16 is the MAC address of the packet ON THIS
WIRE (but if you look at the output of /sbin/arp -a, it's likely to be
your router - meaning the packet is coming from "outside"):
[compton ~]$ etherwhois 00:0e:0c
00-0E-0C (hex) Intel Corporation
000E0C (base 16) Intel Corporation
2111 NE 25th Avenue
MS: JF3-420
Hillsboro OR 97124
UNITED STATES
[compton ~]$
while 00:11:6e:00:f9:70 is the destination
[compton ~]$ etherwhois 00:11:6e
00-11-6E (hex) PePLink Ltd.
00116E (base 16) PePLink Ltd.
17/F., Park Building
476 Castle Peak Road
Cheung Sha Wan Kowloon
HONG KONG
[compton ~]$
The 08:00 says this Ethernet packet is an IP datagram.
SRC=192.168.1.126 DST=172.16.251.61 LEN=228 TOS=0x10 PREC=0x00 TTL=47
Source and destination IPs - this infers that the packet didn't have to
go through an ISP router, as the 172.16.x.x destination is RFC1918
private space, and "could be anywhere" and thus is unroutable. The
TTL of 47 smells highly of a "fabricated" packet. (Most operating
systems set the TTL to one of five values [32, 60, 64, 128, or 255],
and the TTL is decremented at each router. As there are few places
that are on the internet and beyond ~30 hops, this implies that the
starting TTL would have to be 60 or 64, meaning the source is 60-47
or 64-47 hops [13-17 routers between you and them]. I'll merely
state this is HIGHLY unlikely.)
ID=19109 DF PROTO=TCP SPT=38196 DPT=22 WINDOW=16022 RES=0x00
More or less normal
ACK PSH FIN URGP=0
Interesting set of flags. This implies the "end" of a connection.
I'm using iptables on a 2.6 Linux box.
[compton ~]$ whatis hping2 hping3 nc nmap
hping2 (8) - send (almost) arbitrary TCP/IP packets to network hosts
hping3 (8) - send (almost) arbitrary TCP/IP packets to network hosts
nc (1) - TCP/IP swiss army knife
nmap (1) - Network exploration tool and security scanner
[compton ~]$
These might be representative of the tool being used, but the
documentation that comes with nmap is MUCH more useful.
RFC3330 specifies a number of IPv4 address ranges that basically should
not be seen on the Internet. It's normally considered to be A Good Thing
(tm) to block packets with these addresses as source or destination AT
YOUR PERIMETER unless you specifically know that they are needed. See
section 8.10.2 of the Security-Quickstart-HOWTO
-rw-rw-r-- 1 gferg ldp 278012 Jul 23 2002 Security-Quickstart-HOWTO
which should be on your system (/usr/share/HOWTO/) or you can find it at
your favorite search engine.
Old guy
.
- References:
- strange packets from 192.168.1.126
- From: Kevin VW
- strange packets from 192.168.1.126
- Prev by Date: Re: Stupid PIX configuration question.
- Next by Date: Re: Stupid PIX configuration question.
- Previous by thread: Re: strange packets from 192.168.1.126
- Next by thread: Stupid PIX configuration question.
- Index(es):
Relevant Pages
|
Loading
