I have figured out what this crap really is... The Windoz3 server is
indeed listening on port(s) 60001 TCP/UDP and it is broadcasting on both
60001 TCP/UDP (I found out about the UDP portion yesterday night).
Basically, it broadcasts TCP but from time to time it also broadcasts
UDP for no particular reason (or at least I'm not able to figure out
why). The application that listens on this port is the "OpenLink Data
Access Drivers" (Universal Data Access Driver Suite - Multi tier Edition
v4.1). Thanks to those who suggested I used the FPORT application
because without I wouldn't be able to figure it out. I am now past the
"Insanity" level and returning to normal thanks to all of you.
So, big thanks to everyone and I apologise for my lenghty e-mails.
Cheers,
Dimitris.
-----Original Message-----
From: Mailing list for discussion of Firewall-1
[mailto:FW-1-MAILINGLIST AT AMADEUS.US.CHECKPOINT DOT COM] On Behalf Of Crist
Clark
Sent: Thursday, June 26, 2003 9:06 PM
To: FW-1-MAILINGLIST AT AMADEUS.US.CHECKPOINT DOT COM
Subject: Re: [FW-1] A little off Topic - Unknown Port
Dimitris Chontzopoulos wrote:
>
> So, if its not "Broadcast" what is it then?
It is broadcast. 255.255.255.255 is _the_ generic local network
broadcast address. Assuming this is on an Ethernet link, I would also
guess it has the Ethernet broadcast address, 0xffffffffffff, as a
destination. I've never said this wasn't broadcast traffic. All I've
been trying to say is that it is likely to be...
> I pressume it is "Broken
> Traffic".
Right. It doesn't make a whole lot of sense for _any_ software, whether
it be stuff you installed deliberately or some malware, to be generating
this kind of traffic.
> But it might also be an "Announcement". You know, like NetOp
> Remote Control if you don't check the "Diasable Local Subnet
> Broadcasting" option (6502 TCP/UDP), or maybe "Broadcast SNTP
every..."
> in a very popular Time Server program(7 UDP), or even Compaq Insight
> Manager using TCP 2301 to "Announce" its presence, or even Symantec
NAV
> Corporate Edition and McAfee e-Policy Orchestrator, not to mention HP
> JetDirect TCP 9100.
I don't believe any of those do any broadcasting of TCP traffic. As we
have hashed out ad nauseum now, broadcast TCP traffic is bogus and any
decent TCP/IP stack is going to drop the stuff before any application
running on the system receives it. This makes it not particularly useful
for legitimate or illegitimate application.
> So, if it is a matter of terminology, then probably it should be
> "Announcement" instead of "Broadcast", or even "Broken Traffic". I
don't
> think that we should argue on the type of traffic (Broadcast,
Multicast,
> Broken Traffic, Announcement or whatever). I on the other hand, think
> that it may actually be "Announcement" instead of "Broken Traffic".
You
> just "can't be too carefull after all". So, if it is an "Announcement"
> (which is my best bet) it may be for a Trojan or something
"Announcing"
> its presence on the Network, or even some stupid installed Server
> application trying to "Announce" its presence on the network, why not?
*sigh* The reason "why not" is because it violates standards and Just
Won't
Work most of the time. If there is some user program on another machine
listening for 60001/tcp traffic, IT WILL NEVER HEAR THIS BROADCAST
TRAFFIC.
The OS drops the stuff before it gets passed to an application. That's
why
it is very unlikely to be intentional behavior from a friendly
application
or even from an unfriendly one.
> The thing is that "you can't be too carefull". What I am trying to do?
I
> am merely trying to find out what exactly this kind of traffic really
is
> in order to reduce the possibility of actually having a Trojan on the
> Server. If I get to know what this thing really is, I will be able to
> track it back to its source and get rid of it. After I'm done with
that,
> I'll be able to never let it happen again (I hope).
Firewall logs and IDS often turn out to be much more useful for
every-day
debugging of non-malicious broken stuff than tracking down intruders
simply
because non-malicious broken stuff happens with a frequency orders of
magnitude greater than intrusions. I'm just trying to help point you in
the most likely direction.
I'd want to find out whether it is malicious too. Heck, I'd just want to
find it, malicious or not, since it is so broken in the first place. But
before I go tearing a machine apart hunting for stealth kernel modules
(and kernel modules are the only kind of thing that would find this kind
of traffic useful), I'd check the systems for broken, but benign,
software
that's sitting out in the open. That's my point here.
> An Anti-Virus Scan, as well as scans from 3 different programs able to
> detect Trojans/Ad-goodies and the like, showed absolutely nothing. The
> Server is also listening (how obvious) on the particular port (TCP
> 60001) but when I try to connect using Telnet nothing happens (how
> obvious again). When I figure out what is going on, I'll let you know.
The first thing I always try on a listening port if I have no idea what
is actually listening is,
GET / HTTP/1.0
You might be surprised how often any-random-port is an HTTP server. The
second thing to do is repeat this exercise, but over SSL.
What operating system is the suspect box? Have your run lsof or the like
if it is a UNIX-type system? Or the equivalent if it is Windows? What
kind of daemons are running?
I haven't meant to be dismissing your concerns or telling you to ignore
the problem. I have personal experience with this kind of thing. One
issue that leaps to mind is all of this UDP traffic we were seeing
from several Solaris systems,
a.b.c.d:35435 -> 0.0.0.0:35437
That is, the machines were sending out high-UDP port broadcasts to
the old zero-net broadcast address. It's not malicious, it's just
broken apps binding to a '0' address accidentally (some programming
error) and sending this crap out on the network.
I feel your pain, dude.
--
Crist J. Clark crist.clark AT globalstar DOT com
Globalstar Communications (408) 933-4387
The information contained in this e-mail message is confidential,
intended only for the use of the individual or entity named above.
If the reader of this e-mail is not the intended recipient, or the
employee or agent responsible to deliver it to the intended recipient,
you are hereby notified that any review, dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this e-mail in error, please contact postmaster AT globalstar DOT com
=================================================
To set vacation, Out-Of-Office, or away messages,
send an email to LISTSERV AT amadeus.us.checkpoint DOT com
in the BODY of the email add:
set fw-1-mailinglist nomail
=================================================
To unsubscribe from this mailing list,
please see the instructions at
http://www.checkpoint.com/services/mailing.html
=================================================
If you have any questions on how to change your
subscription options, email
fw-1-owner AT ts.checkpoint DOT com
=================================================
|
