what is this probe

[ME]

On Fri, 7 Jul 2000, E Frank Ball III wrote:
[chop]
> No, this is my setup:
[chop]
> ...My local network is a 192.168. address.
[chop]

OK, that rules out that direction of review. :-)


> } For ICMP (if the above page is still accurate) the "port" number listed
> } next to the src address is not a port number. For ICMP, it specifies the
> } ICMP type. For the dst port with ICMP, it is not a port, but the code. 
> } 
> } So, this would *suggest* an ICMP packet from SRC=172.31.105.12 to
> } DST=209.204.172.XXX with a code of 3, and a type of 13

> That's it!

Kewl!

> The logs display it the same as a port number, but it's
> really the ICMP type.  That makes sense.  The only ICMP packets I've
> intercepted until now were pings, so I'm new at this.

Hey, I still consider myself new to this. Actually most people are new to
this as firewalls are not *that* old. At least we are on the right track!

> Here's an example of a blocked ping (ICMP type 8):
> Jul  6 14:57:06 zouave kernel: Packet log: input DENY eth0 PROTO=1 
> 208.201.224.239:8 209.204.XXX.153:0 L=84 S=0x00 I=28152 F=0x0000 T=63 (#19)
> I logged onto 208.201.224.239 and generated this for an example.
> 
> I was used to seeing ICMP traffic on "port 0", which is really the code
> for the ICMP type.  Pings (type 8) are always code 0.
> 
> There is some good info at www.robertgraham.com/pubs/firewall-seen.html
> But they don't talk about type 13 ICMP packets (I guess he doesn't think
> they are dangerous), this page does have link to
> http://www.isi.edu/in-notes/iana/assignments/icmp-parameters

Kewl, I will have to check that out. (Thanks for the links and the
verification listed above.)

[chop]
>            13  Communication Administratively Prohibited      [RFC1812]
>            14  Host Precedence Violation                      [RFC1812]
>            15  Precedence cutoff in effect                    [RFC1812]

ahh yes, I need to read up on RFC1812 and update my page. My last pull of
RFCs was from a long time ago and did not include this RFC.

> Perhaps you got it backwards?  Could it by ICMP type 3 code 13 instead
> of type 13 code 3 (which isn't defined)?  Yes I see that you switched
> what you said below to type 3 code 13.

I'll be the first to admit to mistakes. If I did this, please pardon this
mistake. (Sometimes my thoughts get ahead of my fingers.) Even though you
understood what I meant, it is good to correct it for any other readers.

> Rule #3:
> ipchains -A input -i eth0 -s 172.16.0.0/12 -l -j DENY
> Block all of the private address block 172.16.0.0 thru 172.31.255.255.
> I don't block ICMP type 3 packets, I do block types 4,5,8,9, & 12.

Yes i have a similar entry in my rules to cover this, 10/24 and the class
C range of reserved addresses.

Also, for ICMP, I think I have limited what passes through on a few boxes:

#ICMP:
echo "Setting up basic ICMP input rules..."
ipchains -A input -p icmp -s 0/0 destination-unreachable -j ACCEPT
ipchains -A input -p icmp -s 0/0 source-quench -j ACCEPT
ipchains -A input -p icmp -s 0/0 time-exceeded -j ACCEPT
ipchains -A input -p icmp -s 0/0 parameter-problem -j ACCEPT
ipchains -A input -p icmp -s 0/0 echo-reply -j ACCEPT
ipchains -A input -p icmp -s 0/0 echo-request -j ACCEPT
ipchains -A input -p icmp -s 0/0 -j DENY

I know it is kind of open, and ping actually works, but I like most of
the way it works.

One of my systems has about 10 interfaces and its ipchains rules are
rather amusing.

[chop]
> rfc1812 can be found here:
> http://www.ietf.org/rfc/rfc1812.txt?number=1812

Kewl! URL makes it easier to grab. It will provide some entertainment to
me later this weekend provided I have time. 

> } Now for a test...
[chop]
> No response to a ping 172.31.105.12, or a telnet or http.  But it's a
> day later now.

I was hoping that the default gw through which your box contact as the
upstream router would have some routing rules to automatically tell your
box that it cannot connect to any of the private network addresses
(preferrably with the 13,3 ICMP response.) Bummer deal that this did not
offer a repeat performance of your logged entry when using a telnet to
that IP, or oher kinds of connection attempts.

If you have no response from the upstream router, then this theory is
probably not correct in its assumption for the cause for the offending
packet. They could have been re-configuring their routing tables to allow 
this to happen.

off topic but...
Want to have some fun? See how many routers between you and the Internet
do not have rules to deal with any of the private networks. Try
traceroutes to random private IP host address values. I have been able to
make 4 hops on a few campuses before getting the expected response(s).
* * *...

Kind'a fun.

[chop]
> I asked the ISP about private network addresses on the DSL connection,
> but I didn't really get a straight response.  I suppose I could put a
> machine on with a private IP address get Bill (he's on the same subnet)
> to see if he could talk to it.

If you could know the subnet mask, that would help. Then you could ping
the broadcast addresses for each subnet as you change your IP to be in the
new subnet and look for DUP! responses. If they use switches that do not
pass on brodcast src/dst packets (I guess this is possible for home users
to not have a need for them) then this may not help.

Also, for each host that exists out there that *could* be on a private
network, they probably have a default host to act as their router. If
their router declines to route packets to you. they may get your packet,
but have no way to pass back a response.

[chop]
>> blah blah disk space blah blah danger danger will robinson
[chop]

> I'm logging lots of stuff while I learn what's going on and what's normal.
> 
> >From "df":
> /dev/sdb4               267639     20747    233068   8% /var
> 
> Log space isn't a problem yet, and since /var has it's own partition it
> least the logs can't crash the system if they overflow (like from a
> denial of service attack).

Yep,you have the standard-good-practice idea. That is a good practice for
mounts. One thing to note: It may affect your system performance if/when
your /var ever does fills up. In my limited experience with filling up my
/var/log and /var mounts (yes different devices/partitions) the system
would claim 100% of capacity, but would still caches the desired write in
memory for processes writing with kernel/root privs, and continue to flush
to disk at odd intervals. 

Weird stuff started happening with my web server (sluggish responses and
kind of "spirty" behavior.)

As I continued to clear up space in /var, cached data was flushed to disk.
Well over 600Mb of cached data was in memory waiting to be flushed as I
deleted 1Gb of files I did not need any longer.

The space you show for you system seems healthy enough for your purposes
with only 8% of capacity, you're pretty healthy. :-)

> } BTW, I seem to recall you worked for Agilent...
[chop]

> I do work for Agilent.  There is a hiring freeze in some departments,
> others are hiring as fast as they can.  Email me privately or call and
> tell me what she does.

Excellent, I'll contact you off list.

> Thank you.  So I'm still not exactly sure what was going on, but I'm not
> too concerned about it.  It looks mostly harmless.  No other probes from
> that IP address, and not much else that day from anybody else.  I just
> like to understand what's going on.  I hope somebody else found all this
> useful.

Yeah, I hope they find it helpful too.

-ME