RE: That don't look good!

From: Adam Shephard (
Date: 10/09/01

Message-ID: <315154A4F911D2118D9E00805FA9C2C62A6B23@nt0016a03>
From: Adam Shephard <>
To: "''" <>
Subject: RE: That don't look good!
Date: Tue, 9 Oct 2001 09:30:15 -0500 

I'd like to thank everyone for their input on this. I made use of all of it,
believe me.

I have been replying to everyone's responses but my posts were being
returned. This morning I found out that they were returned because I had
properly trimmed my posts. Mea culpa.

So here is the main info from my initial replies. Since this was never
posted to the list, I have trimmed it but have included all of the pertinent

This was posted on Thursday:

> Now, the ports in question are 137 and 53.
> I tried to sniff IT but get this. The timing on IT every day
> was exact, right? So I fired up the sniffer about ten minutes
> prior to the time IT was to start but IT didn't start. I
> sniffed for about an hour then I gave up, stopped the capture
> and went about my business. About two hours later I checked
> my logs and it turns out that IT started up again the second
> (and I mean "the second") the capture stopped.
> So this morning I just sat glued to the firewall and waited
> for IT. As soon as I saw IT hit, I started capturing again.
> When IT stopped, I stopped the capture. Then I start going
> through the sniffer's output searching for the 10. address. It's not
> there. So I search for anything to port 137. There was plenty
> but nothing from that address and nothing at the same time as
> the log entries (and, yes, I accounted for the offset in time
> between the two machines). There was nothing at all from any
> address for 53. However, there are entries in the firewall log
> for both ports, still from that 10. address.
> The only progress at all is, since I was eyeballing the
> firewall, I was able to ping the 10. address while this was
> happening (all other times it was after the fact and just
> came back unreachable). The response came back with an
> address from a block owned by Sprint. I've since blocked that
> set of addresses.

Then, from Friday:

>This has changed even more today. It's no longer once a day.
>Today it has happened three times, each time an hour apart. The
>first and third times I had the sniffer going. Still no entries
>at all.
I know this sounds a virus from a Fellini film, but I swear it's all real.

Well, I ran the sniffer all weekend (a 3-day weekend) for us.

Since late Friday afternoon, I have had no incidents whatsoever of this
happening. Sooooo, I guess IT has vanished into the night. Of course, that's
not very likely. I guess I'll see over the next few days.


Relevant Pages

  • nfs client readdir caching issue?
    ... we're seeing various problems on a linux kernel client ... duplicate directory entries. ... In the other capture, the responses ... second response of the first capture. ...
  • Re: nfs client readdir caching issue?
    ... duplicate directory entries. ... a first cookie value of 13. ... In the other capture, the responses ... Subsequently, the readdir cache needs ...
  • Re: Can trojan bypass sniffer?
    ... a sniffer is designed to capture ALL traffic originating from within ... if the sniffer has been configured to only ... capture traffic of a certain protocol and the trojan in question is designed ... > frames for emails to make sure that I do not have ...
  • Re: Intrushield vs. ISS once more...
    ... networks the problem is building a cost effective solution. ... remember going out and getting the latest packet sniffer some time ago. ... It was the latest 10 Gigabit Ethernet Sniffer that captured less then ... the capture - which was REALLY frustrating. ...
  • Re: NAT Logging
    ... In the meantime we're using a freeware firewall to ... NAT on win2k doesn't solve the problem. ... >thinking you'd need to run a sniffer on both sides of the ... >both Checkpoint and ISA are probably the most expensive ...