what is this probe

E Frank Ball III frankb at efball.com
Fri Jul 7 16:52:44 PDT 2000


} I have some questions for you:
} 
} Are you using IP Masquerading?
}  With a single interface that shares an aliased IP address and the real IP
} address on the same port (eth0) ?
} 
} Example:
}                  Host
}           uplink |         
} DSL ------------ HUB --- MASQ/GW/Router
}                  |
}                  Host
} 
} and if so, are you using a private network range with one machine that has
} that specified source address?


No, this is my setup:

                                  Host
           eth0             eth1   |         
 DSL --------- MASQ/GW/Router-----HUB---Host
                                   |
                                  Host

My local network is a 192.168. address.


 
} 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!  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.

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

Type    Name                                    Reference
----    -------------------------                ---------
  3     Destination Unreachable                  [RFC792]
 13     Timestamp                                [RFC792]

Many of these ICMP types have a "code" field.  Here we list the types
again with their assigned code fields.

  3     Destination Unreachable                  [RFC792]

        Codes
            0  Net Unreachable
            1  Host Unreachable
            2  Protocol Unreachable
            3  Port Unreachable
            4  Fragmentation Needed and Don't Fragment was Set
            5  Source Route Failed
            6  Destination Network Unknown
            7  Destination Host Unknown
            8  Source Host Isolated
            9  Communication with Destination Network is
               Administratively Prohibited
           10  Communication with Destination Host is
               Administratively Prohibited
           11  Destination Network Unreachable for Type of Service
           12  Destination Host Unreachable for Type of Service
           13  Communication Administratively Prohibited      [RFC1812]
           14  Host Precedence Violation                      [RFC1812]
           15  Precedence cutoff in effect                    [RFC1812]

 13     Timestamp                                [RFC792]

        Codes
            0  No Code

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.


} and we can see that rule #3 (line 3) in your ipchains rule list is the
} one that found this packet and logged it.

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.

From: www.robertgraham.com/pubs/firewall-seen.html

8.1 What ICMP traffic should I deny?

     The "correct" configuration of ICMP filters in a firewall is hotly
     debated.  The problem is that ICMP are the "control messages" for
     TCP/IP.  If you block some incoming ICMP, then you will break
     communication.

     The absolute minimum ICMP traffic to allow is the packets dealing
     with TCP path MTU discovery.  Fragmenting a stream is more
     efficient at the TCP layer rather than the IP layer, so the TCP
     layer will try to discover when IP packets are being inadvertently
     fragmented.  They do this by setting the "DF" (Don't Fragment) on
     all outgoing packets.  When a router cannot forward the packet
     because it is too big, rather than fragmenting it, it sends back a
     "fragmentation needed" ICMP packet (type=3/code=4).  The TCP stack
     then starts sending smaller IP packets, segmenting the data at the
     TCP layer rather than allow routers to fragment at the IP layer.
     Therefore, firewalls must be configured to allow incoming ICMP
     type=3, code=4 packets.

     Another issue is Host unreachable and Destination Unreachable
     packets.  Allowing these to come in through your firewall will
     allow connections to timeout faster, but they can also be used as a
     denial of service attack (by disconnecting clients from servers).

     ...
 
} Now, using the above, and a nifty web page I put up based on RFC data on
} ICMP, you can see what the type and code map out to.
} 
} http://libweb.sonoma.edu/mike/networking/icmppacket.html
} 
} >From the http://libweb.sonoma.edu/mike/networking/icmppacket.html page I
} see type 3, code 13 maps to:  - "communication administratively prohibited
} by filtering"  - according to a description in "TCP/IP Illustrated Volume
} 1" for the references in the web page that cite the book. I have not found
} the RFCs for some of the type/code combos yet annd I ref the book until I
} find them. My RFC index is a bit old, and I need to update to have a more
} complete list.)

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

4.3.3.1 Destination Unreachable

   If a router cannot forward a packet because it has no routes at all
   (including no default route) to the destination specified in the
   packet, then the router MUST generate a Destination Unreachable, Code
   0 (Network Unreachable) ICMP message.  If the router does have routes
   to the destination network specified in the packet but the TOS
   specified for the routes is neither the default TOS (0000) nor the
   TOS of the packet that the router is attempting to route, then the
   router MUST generate a Destination Unreachable, Code 11 (Network
   Unreachable for TOS) ICMP message.

   If a packet is to be forwarded to a host on a network that is
   directly connected to the router (i.e., the router is the last-hop
   router) and the router has ascertained that there is no path to the
   destination host then the router MUST generate a Destination
   Unreachable, Code 1 (Host Unreachable) ICMP message.  If a packet is
   to be forwarded to a host that is on a network that is directly
   connected to the router and the router cannot forward the packet
   because no route to the destination has a TOS that is either equal to
   the TOS requested in the packet or is the default TOS (0000) then the
   router MUST generate a Destination Unreachable, Code 12 (Host
   Unreachable for TOS) ICMP message.

   DISCUSSION
      The intent is that a router generates the "generic" host/network
      unreachable if it has no path at all (including default routes) to
      the destination.  If the router has one or more paths to the
      destination, but none of those paths have an acceptable TOS, then
      the router generates the "unreachable for TOS" message.


Not terribly informative.
 
} Now for a test...
} 
} If you do have IP Masqerading on a host behind your gw/firewall/proxy that
} is not a member of the 172.31/16 network, or you do not have
} any routing entries on your gw/firewall/proxy that address
} explicit hhandling for any IP addresses on the 172.31/16
} network range then try to issue a ping for 172.31.105.12
}
} Also try to connect up to a web page with netscape, or telnet to the same
} host.

No response to a ping 172.31.105.12, or a telnet or http.  But it's a
day later now.


} Since 172.[16-31]/16 are all private networks (as others like 10/24 etc)
} it would make sense for your upstream router to be configured to not allow
} traffic for these to pass out to the Internet. If they have such a policy,
} they may be configured to respond to your host saying, "I am a router and
} do not allow you to talk to this range of IP addresses" but send this
} message as though it came from the IP addressyou were trying to ping.
} 
} It is also possible that a request for a telnet or web session (etc) with
} that address would cause the upstream router to create an ICMP response to
} tell your machine "don't go there"
} 
} I would try testing the above with connecting to IP addresses on reserved
} networks to see if it produces similar messages.

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.


} One note of warning, you better have a lot of free disk space on your
} logging tree (assuming /var/log) if you are logging a *lot* of your
} ipchains violations. A DOS can be created against your logging systems if
} they can fill up your logs. It can also be difficult (or possibly
} impossible :-) for the logs to identify the actual src of the attack since
} the attacker does not need to see any responses, forged src addresses can
} be used - as long as it fills up your log file to the point ther actual
} attack cannot be logged.

I'm logging lots of stuff while I learn what's going on and what's normal.



More information about the talk mailing list