RE: Interesting packets

From: Boyan Krosnov (
Date: 09/17/02

Date: Tue, 17 Sep 2002 10:13:46 +0300
From: "Boyan Krosnov" <>
To: "Jeremy Junginger" <>, <>

Just a few notes.

The log that you have provided is for an icmp->dest
unreachable->prohibited message, which is usually an effect of acl
blocking of the packets that you send. It may or may not be the case
that you really sent those packets to
( Although I'd bet that you really did,
and this icmp is because of the filter or other blocking mechanism
installed on the machine that has the ip address on one of
it's interfaces(this is most probably a router of a firewall). The point
of this paragraph is to remind you that IP is connectionless and
stateless, and anybody on the internet may have sent this packet.

Also note that there is no such thing as an UDP "connection". There are
only UDP _packets_ (or datagrams) floating forth and back. UDP is
connectionless and stateless as IP is (each protocol working over it has
to provide statefull mechanisms, like keeping the port on one or both
sides the same throughout the communication).
So even if the ICMP is genuine you can't know if the packet from x.y.z.4
to (sport:17468 dport:8197) is the first in this
communication or if there were packets in the opposite direction before
it. And you can't know which of the two machines is initiating the
communication. Also you can't know if the packet in question was sent by
somebody else on the Internet with a spoofed source, or by your machine.

Boyan Krosnov, CCIE#8701
Just another techie speaking for himself

> -----Original Message-----
> From: Jeremy Junginger []
> Sent: Monday, September 16, 2002 6:31 PM
> To:
> Subject: Interesting packets
> I've been tracing these packets for a while now, and am
> having a bit of
> trouble deciphering what's happening. It appears that this host is
> attempting to contact an external host over udp port 8197 where the
> firewall blocks it. Interesting points are:
> It looks like host x.x.x.4 is initiating a udp session with
> over port 8197.
> We block this port with egress filtering at the firewall, as
> it is not a
> dataflow we utilize in our production systems.
> Anybody deciphered similar alerts?
> Generated by ACID v0.9.6b21 on Mon September 16, 2002 08:02:58
> --------------------------------------------------------------
> ----------
> ------
> #(1 - 8399) [2002-09-16 06:50:18] ICMP Destination Unreachable
> (Communication Administratively Prohibited)
> IPv4: -> x.x.x.4
> hlen=5 TOS=0 dlen=56 ID=2147 flags=0 offset=0 TTL=241
> chksum=31000
> ICMP: type=Destination Unreachable code=Packet Filtered
> checksum=42554 id= seq=
> Payload: length = 32
> 000 : 00 00 00 00 45 00 00 3D 78 26 00 00 70 11 8B 34
> ....E..=x&..p..4
> 010 : AC 10 37 04 44 3C 20 05 0F 72 00 35 00 29 46 E8
> ..7.D< ..r.5.)F.
> Original IP information: UDP x.x.x.4 17468
> 8197
> -Jeremy
> --------------------------------------------------------------
> --------------
> This list is provided by the SecurityFocus ARIS analyzer service.
> For more information on this free incident handling, management
> and tracking system please see:

This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management
and tracking system please see:

Relevant Pages

  • Re: pinging without root privileges
    ... > feasible, since I want to be able to do this w/out root privileges, so ... > The closest thing I found was a promise about sending UDP packets to ... > an unbound port, and looking for a port unreachable message. ... > weakness of UDP is that the sender has no way of knowing what happened ...
  • Re: recvfrom udp packet dropping??
    ... The device sends UDP packets on port 4950 to a listener socket ... > The packets sent by the embedded device are getting to the UNIX ... Make sure your embedded network device is properly setting the UDP checksum. ...
  • recvfrom and recv socket buffer
    ... I am writing a communication program using both TCP and UDP, ... help in case of processing partial packets. ...
  • Re: NTP security hole CVE-2013-5211?
    ... a relatively large outflow of packets from my server, ... from UDP port 123. ... server is not actually supplying NTP information to any other systems, ...
  • Re: Winmx *source* port 6257 - Valid?
    ... packets are being dropped because my cable router is not configured to allow ... the port 6257 traffic I see from WinMX has both source *and* ... If a user has configured WinMX for UDP ... > may see more dropped packets then with TCP. ...