There is a discussion and a toool here:
http://www.ossec.net/dcid/?p=87
I suspect this is a bug in an application that is looking for a random
port to communicate on.
It binds to the port and then fails to listen, or it stops listening
then fails to unbind.
Since the issue seems to be showing up on later kernels, it is probably
a bug in an older app that has not been updated.
If the original app is not affected negatively by the issue, the apps
users(and developers) would not even know there was a problem.
I think ultimately, there is a problem,and ossec has properly alerted
you to the fact.
If you make the reasonable decision that the issue is not a security
threat, then it should be fine to suppress the alert as long as you are
precise.
Perhaps the folks on the list could volunteer suggestions on how to
create a filter that is as finely grained as possible.
On 11/19/2010 09:02 AM, Justin Redman wrote:
I am seeing this too. In our case I believe it is related to our Oracle
cluster's heartbeat since it is only occurring on those servers. Not sure if
that helps you any though.
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of x509v3
Sent: Friday, November 19, 2010 12:08 AM
To: ossec-list
Subject: [ossec-list] Anyone seeing false positives like this? : Port
'60256'(tcp) hidden. Kernel-level rootkit or trojaned version of netstat.
Hi, been running ossec for about a month now, after testing for
another month. Tonight I received the following from one my production
machines:
OSSEC HIDS Notification.
2010 Nov 18 19:36:56
Received From: (host) 10.1.1.1->rootcheck
Rule: 510 fired (level 7) -> "Host-based anomaly detection event
(rootcheck)."
Portion of the log(s):
Port '60256'(tcp) hidden. Kernel-level rootkit or trojaned version of
netstat.
--END OF NOTIFICATION
Host 10.1.1.1 is an IBM PowerPC host running AIX. I've seen this type
of alert on my mac at home (PowerPC running 10.4), every once in a
while. I confirmed from the Mac install DVD that the latter was a
false positive.
It's likely that this alert is a false positive too, but taking it
offline isn't really an option unless we're sure there's an issue.
Unfortunately, alerts like this trigger a mandatory incident response
and be disruptive, so many false alarms will not be good.
Anyone else seeing netstat-related false alarms list this?
--
R. Loyd Darby, OSSIM-OCSE
Project Manager DOC/NOAA/NMFS
Infrastructure coordinator
Southeast Fisheries Science Center
305-361-4297
