Intrusion Detection Systems mailing list archives

Traffic


From: justin.lister () csfb com (Lister, Justin)
Date: Tue, 26 Oct 1999 11:27:35 +0800



Received: from lois.dgim.crc.ca (lois.dgim.crc.ca [142.92.39.60])
      by wyrm.its.uow.edu.au (8.9.1a/8.9.3) with SMTP id BAA18049
      for <ids () uow edu au>; Mon, 25 Oct 1999 01:08:29 +1000 (EST)
Received: (qmail 14473 invoked from network); 24 Oct 1999 15:08:09 -0000
Received: from obelix.dgrc.crc.ca (142.92.38.223)
  by lois.dgim.crc.ca with SMTP; 24 Oct 1999 15:08:09 -0000
Received: (from > Received: (from don@localhost)
      by obelix.dgrc.crc.ca (8.9.3/8.9.3) id LAA08822
      for ids () uow edu au; Sun, 24 Oct 1999 11:08:09 -0400 (EDT)
Date: Sun, 24 Oct 1999 11:08:09 -0400 (EDT)
From: Donald McLachlan <don () mainframe dgrc crc ca>
Message-Id: <199910241508.LAA08822 () obelix dgrc crc ca>
To: ids () uow edu au
Subject: Traffic
X-Sun-Charset: US-ASCII


Thanks to Mathew starting the ball rolling, I've recently been running an
IDS to learn about this stuff and have some questions.

For instance, I logged the following on Thursday.

      12:53:10.681942 host.domain.com.80 > our.host.ca.55027: F
              629209871:629211027(1156) ack 1525437548 win 8460
              (frag 9564:>            (frag 9564:1176@0+)

I was surprised to see this for a couple of reasons.

- TCP trys to avoid frags, and by the end of the connection should know
  how big the mtu is. (and had done so successfully during this connection
  except for this packet.)
- I find it funny that a host would send a FIN packet (says I have no more
  data to send, close this half of the connection) yet set the more
fragments
  bit saying there is a frag to come!

Is this normal?  I've seen it more than once from this web server.

-----

I've been seeing what looks like icmp unreachable messages to our net
from private IP addresses.  Are sites starting to program their border
routers with private IP's to their ISP?  Possibly like:

      10.1.1.0
-------------------------
|                     |
| .1                  | .2
---------     -------------
|border |     | isp router |
---------     -------------

                      |
                      --------> to internet

-----

I ask because I've been seeing loads of ICMP echo replys like the
following
coming to our network.

      00:01:35.989204 192.168.1.1 > an.unused.address.here:
              icmp: host 200.250.78.49
              unreachable [tos 0xc0]

Any idea what the purpose of this would be?
- the source address is a private IP, so we cannot reply, right?
- the packet is sent to an unused address here
- Even if the packet was source routed (does/how does tcpdump show that
  without -v?), hosts should not send icmp (host unreachable in this case)
  in response to icmp messages, right?

So what is the point.  For 2 or 3 days I saw
traffic like this.  Mostly to unused addresses on our nets.  Never more
than 16 packets per hour, and usually 2 packets sent to each address tried
in the hour (others lost?), and no address ever repeated from hour to
hour.
But to what end?  Is it possible our border router is replying to these
(even though they are icmp) if they were source routed to us?

Don

This message is for the named person's use only.  It may contain confidential, proprietary or legally privileged 
information.  No confidentiality or privilege is waived or lost by any mistransmission.  If you receive this message in 
error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the 
sender.  You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if 
you are not the intended recipient. CREDIT SUISSE GROUP, CREDIT SUISSE FIRST BOSTON, and each of their subsidiaries 
each reserve  the right to monitor all e-mail communications through its networks.  Any views expressed in this message 
are those of the individual sender, except where the message states otherwise and the sender is authorised to state 
them to be the views of any such entity.



Current thread: