Unusual error messages in dsmerror.log

[rowl]

I have been getting tickets about the dsmcad.exe service on Windows causing high CPU/Memory utilization on and off for months now. Often when I check the dsmerror.log file I see pages and pages of entries like this...

07/25/2018 10:43:41 ANS0361I DIAG: sessRecvVerb(): Invalid verb received.
07/25/2018 10:43:41 ANS0361I DIAG: sessRecvVerb(): length=ffff, verb=ff,magic=ff
07/25/2018 10:43:54 ANS0361I DIAG: Error reading http request.
07/25/2018 10:43:55 ANS0361I DIAG: isFileNameValid: Invalid file name password - file type required.
07/25/2018 10:44:02 ANS0361I DIAG: Error reading http request.
07/25/2018 10:44:02 ANS0361I DIAG: Error reading http request.
07/25/2018 10:49:28 ANS0361I DIAG: isFileNameValid: Invalid file name favicon2.iso - file type not allowed.
07/25/2018 10:49:28 ANS0361I DIAG: isFileNameValid: Invalid file name favicon.iso - file type not allowed.
07/25/2018 10:49:41 ANS0361I DIAG: isFileNameValid: Invalid file name netmri/config/userAdmin/login.tdf - file type not allowed.
07/25/2018 10:49:41 ANS0361I DIAG: isFileNameValid: Invalid file name scgi-bin/platform.cgi - file type not allowed.
07/25/2018 10:49:41 ANS0361I DIAG: isFileNameValid: Invalid file name admin/login.do - file type not allowed.
07/25/2018 10:49:41 ANS0361I DIAG: Error opening input file en/main.js

It looks to me like this is some sort of security penetration testing tool scanning the client with invalid requests. This usually leaves the dsmcad.exe proces unresponsive and consuming high CPU/Memory till it is restarted, often it needs to be killed.

Curious if others have run into this and if/how you managed to resolve it.

Thanks,
-Rowl

 

[RecoveryOne]

I've ran into the same thing. And yes, I can reproduce the same errors with OpenVAS and Nessus.
What version of the client are you using? So far I've not had any issues with 7.1.6.5 and 8.1.x during these types of scans.

You could always ask for them to excluded the webports for the TSM client.

 

[rowl]

We are seeing with the 8.1.x client versions. It is most problematic with 8.1.4 from what I have seen.

What I need to capture is some "proof" of what is doing this, as our security team is not very cooprative.

 

[RecoveryOne]

Your poof is in the timestamps listed in the error log.
They should be able to tell you when the scanner hit your systems.
Ask to do a 'one off' scan at a specific time of an individual client. If the scan causes the same errors that you posted above, not sure what 'more' you need.