Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security ISSForum
[Top] [All Lists]

Re: [ISSForum] Unable to queue the TCL Request

Subject: Re: [ISSForum] Unable to queue the TCL Request
Date: Sat, 19 Feb 2005 14:11:53 +0100
Jason, Shabbir,

this is quite an old issue. In the past we experienced severe trouble at one of our large customer sites with 6.5U and 7.0 release of server sensor regarding TCL processing. However we got engineering support from ISS on site and finally managed to get this fixed. When you are running 7.0 SP 4.1 you should be relatively safe. When you are running older releases of server sensor please ask support@iss.net for a fixed issdaemon and tclproc version or do an upgrade to 7.0 SP 4.1 if possible. One potential cause for this message is a large number of security events or user defined events that are using the tcl process for event verification, e.g. domian controllers processing thousands of login requests. Of course any new signature being rolled in via xpu could potentially trigger this message and we monitored one case last year where this actually happened.

Background Info:
server sensor is using tcl scripts for event verification. The event params are getting parsed into different queues. The tclproc.exe is reading the queue entries and executing those scripts. The return code is used by server sensor to determine if the event needs to get sent to the managing system. There are different queues for security events and user defined events. In those cases where the queue gets full (too many events per minute), you will always see this error. It just means that the corresponding event will trigger without further validation by the tcl script. In most cases the error will go away as soon as the queue is being emptied. In some rare cases the tclproc may fail at all and you will have to restart the sensor services. Please check your security log for the number and type of events being logged at the time of the failure.


Regards
Karl Jaeger

Jason Baeder schrieb:

Shabbir,

I've seen this recently. About 1.5 days after pushing XPU 24.2 to 14
server sensors (all now at 7.0 SP4.1 XPU 24.2), _one_ sensor began
producing this error.  That system is NT4.0.  Before we (security)
could do anything, the sysadmin had rebooted the box.  The errors have
not returned.

One other system that was updated at the same time also exhibited an
error.  This one was a Win2K system that dropped communication with
SiteProtector.  In this case we were able to approach the box with the
sysadmin.  A reboot would have been a drastic measure for this
particular system.  Fortuately, manually stopping and restarting all of
the ISS processes resolved the issue.

Jason Baeder
CISSP, GCIA



--- "Bashir, Shabbir" <Shabbir_Bashir@csx.com> wrote:



ALL,
We have 5 windows server sensors that are reporting this alert in the
thousands. The OS are NT, 2K and 2K3. The sensors are on different
XPU and SP levels. When I googled for this error, I saw a post from
this mailing list
(archives.neohapsis.com/archives/iss/2004-q3/0079.html) that mentions
the same issue.
First I thought, I should install all the XPU's, but one of the NT4
server sensor that is seeing this event shows as 7.0 (SP4.1:XPU
22.37).

Has anyone else seen this alert





__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________
ISSForum mailing list
ISSForum@iss.net


TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to 
https://atla-mm1.iss.net/mailman/listinfo/issforum

To contact the ISSForum Moderator, send email to mod-issforum@iss.net

The ISSForum mailing list is hosted and managed by Internet Security Systems, 
6303 Barfield Road, Atlanta, Georgia, USA 30328.




--

Besuchen Sie uns auf der CeBIT - Sie finden uns in Halle 7 Stand D03 bei unserem Partner Sygate. Gerne erwarten wir Ihre Terminanfrage unter cebit@bdg.de.

Treffen Sie am 19. jeden Monats IT-Sicherheits-Experten beim BDG-Security-Point!
Informieren Sie sich hier: http://www.bdg.de/security-point
______________________________________________________

BDG GmbH & Co. KG - Make IT safe.
Stolberger Str. 307
D-50933 Koeln

Tel:     +49 (0)221-954231-0
direkt:  +49 (0)6126-94433-21
Fax:     +49 (0)6126-94433-31

E-Mail:  karl.jaeger@bdg.de
Web:     www.bdg.de
______________________________________________________




_______________________________________________ ISSForum mailing list ISSForum@iss.net

TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to 
https://atla-mm1.iss.net/mailman/listinfo/issforum

To contact the ISSForum Moderator, send email to mod-issforum@iss.net

The ISSForum mailing list is hosted and managed by Internet Security Systems, 
6303 Barfield Road, Atlanta, Georgia, USA 30328.

<Prev in Thread] Current Thread [Next in Thread>