Re: icmp on ports 256, 512, 768 & 1024
Daniel Hartmeier said: > Since the ID is chosen randomly, it wouldn't make much sense to allow > filtering based on it as criteria, so you can just watch the IDs. If you > see more IDs like 256, 512, etc. (powers of 2), that means the sender is > not generating them randomly, I guess. Thanks to all for the very informative responses. I've c&p a few secs from my pftop output below... (my IP addr = X). As I said most (I'm guessing 95% +) have the 256, 512, 768 or 1024 "ID Field" :). Thanks, Jay icmp In 67.33.112.89:768 X:7680:0 1 9 2 184 icmp In 67.33.159.163:512 X:5120:0 8 2 2 184 icmp In 67.32.17.228:512 X:5120:0 12 0 2 184 icmp In 67.30.41.245:768 X:7680:0 3 7 2 184 icmp In 67.33.107.213:512 X:5120:0 3 7 2 184 icmp In 67.32.213.95:512 X:5120:0 4 6 2 184 icmp In 67.33.122.207:768 X:7680:0 1 9 2 184 icmp In 67.34.243.82:1024 X:1024 0:0 1 9 2 184 icmp In 67.30.123.99:512 X:5120:0 5 5 2 184 icmp In 67.30.19.226:768 X:7680:0 12 0 2 184
Re: icmp on ports 256, 512, 768 & 1024
On Tue, Oct 14, 2003 at 03:57:56PM -0500, Jay Moore wrote: > I see frequent inbound icmp from and to ports 256, 512, 768 and 1024 (and > occasionally other ports). I've googled this, but got nothing useful. > What's this traffic all about anyway? ICMP query/replies (like echo request and echo reply used by ping) create state entries per your rules. ICMP doesn't know ports like TCP and UDP, but queries have an ID field, which is used to associate replies with the queries they relate to. For instance, if you ping a host, the sender will pick a (random) ID for the echo requests, and the receiver will use the same ID in its echo replies. pf uses these IDs to match ICMP replies against ICMP state entries, in the same way as the ping process on the sender will do to calculate the round-trip time (imagine several ping processes pinging the same destination concurrently). Since there is no port information in ICMP state entries, and the ICMP ID has the same size as TCP/UDP ports, the ID is stored in the same place in the state entries. pfctl -ss and pftop show these IDs instead of the port for ICMP state entries, which is not particularly interesting to watch, but can help with debugging in certain cases (if you tcpdump ICMP packets, you see the same ID in hex). Since the ID is chosen randomly, it wouldn't make much sense to allow filtering based on it as criteria, so you can just watch the IDs. If you see more IDs like 256, 512, etc. (powers of 2), that means the sender is not generating them randomly, I guess. Daniel
Re: icmp on ports 256, 512, 768 & 1024
On Tuesday, Oct 14, 2003, at 14:18 US/Pacific, [EMAIL PROTECTED] wrote: I see frequent inbound icmp from and to ports 256, 512, 768 and 1024 (and occasionally other ports). I've googled this, but got nothing useful. What's this traffic all about anyway? That makes no sense. ICMP doesn't have port information. What's displayed is the ICMP id field, which only makes sense for echo/ts/info request/reply packets. It's used in the state tree in much the same way TCP/UDP ports are -- to match specific request/reply pairs. It has no meaning otherwise, and unlike TCP/UDP ports it is not useful for explicit filtering.
Re: icmp on ports 256, 512, 768 & 1024
> I see frequent inbound icmp from and to ports 256, 512, 768 and 1024 (and > occasionally other ports). I've googled this, but got nothing useful. > What's this traffic all about anyway? That makes no sense. ICMP doesn't have port information. -kj
icmp on ports 256, 512, 768 & 1024
Since watching pftop has become my favorite pastime :) I have a question: I see frequent inbound icmp from and to ports 256, 512, 768 and 1024 (and occasionally other ports). I've googled this, but got nothing useful. What's this traffic all about anyway? my pf.conf file has a rule to pass required ICMP traffic: pass in inet proto icmp all icmp-type $AllowIcmpIn keep state where AllowIcmpIn="echoreq" Thanks, Jay
