11/29/04 - All previous comments on this left on purpose to tell whole story. Two prior writings followed below with new information.
> > > > Not sure if anyone has run into this, but it appears as > > though I killed our exchange servers today. I do quarterly > > audits and always use Nessus, this is the first time I've > > really had any issues. I always disable all of the DoS > > plugins, as well as most other plugins that do not pertain. > > The only difference I can think of is that this quarter I > > used Nessus 2.2.0. > > > > It seems that during my scans, the Exchange servers lost the > > ability to communicate with the Global Catalog servers. We > > were getting a bunch of NSPI and RFR errors. I'm not an > > Exchange expert, so I'm not sure what other info to give > > here. We ended up rebooting the DC's and the Exchange servers. > > > > Now I just need to figure out why and if it really was the > > Nessus scan or coincidence. > > > > Any thoughts or ideas would be greatly appreciated. > > > > I think I have some more information on this, so hopefully > I'll get some more responses. > > Our Exchange servers have the the HP OpenView ITO agent > installed (version 7.25 I believe). If this service is > running when I run a Nessus scan against it, it basically > breaks the Exchange servers ability to communicate with the > domain controllers or with the Global Catalog. If you stop > the scan (or after the scan) you have to restart the System > Attendant service to get things going again. > > If the HP OpenView ITO agent service is stopped and a Nessus > scan is performed, there are no adverse affects. > > To me, this doesn't make sense how the ITO agent is affecting > the System Attendant service. > > More information: > When the ITO agent is running, TCP ports 381 and 383 are > listening. If you try to browse to http://server:381/ (or > 383) with FireFox, it thinks I'm opening a file. Thinks it > is an "application/octetstream"? If I try with MS IE, it > just gives me a 404. > > I am pretty sure that the pluggin causing the problem is > MISC./Directory Scanner (DDI_Directory_Scanner.nasl -- script > id 11032). This is the only pluggin running every time the > problem occurs. > > I am not sure where to go from here and am open to anyone's > suggestions. > Doing more discovery work to try and figure this out. I thought and still think that the DDI_Directory_Scanner.nasl may be the culprit, but am having a hard time reproducing it, depending on how I do the scan. (Again, the ITO agent has to be running on the Exchange server in order for me to actually kill the System Attendant process.) If I run all the scripts in the "General" category, eventually the system fails (is unable to contact AD or the Global Catalog). Then, if I review the nessusd.messages file and compare every scan that started and stopped, the only one that started and did not finish when I killed the scan (because I was affecting the Exchange server) is the DDI_Directory_Scanner.nasl script. <snip> [Tue Nov 23 17:29:53 2004][28378] user amerenscan : launching DDI_Directory_Scanner.nasl against exchcil [29987] <snip> [Tue Nov 23 17:35:32 2004][26473] Stopping the whole test (requested by client) [Tue Nov 23 17:35:32 2004][26473] Client abruptly closed the communication [Tue Nov 23 17:35:32 2004][26473] user amerenscan : test complete [Tue Nov 23 17:35:32 2004][26473] user amerenscan : Kept alive connection [Tue Nov 23 17:41:31 2004][26473] Communication closed by client I've tried running Nessus and only enabling the Directory Scanner plugin, but the scan completes fine and the Exchange server experiences no problems. I tried to run the script manually: nasl -t exchcil -T exchciltrace.txt /usr/local/lib/nessus/plugins/DDI_Directory_Scanner.nasl That also did not recreate the issue. I even modified the nasl script to point it directly at the HP ITO ports of TCP 381 and 383 (if I'm reading correctly what the script was even doing by default) The lines I changed: script_require_ports("Services/www", 383); port = get_http_port(default:383); Other interesting information: Doing an nmap scan reveals the following information about the 2 ports in question. nmap -sS -sV -O -v exchcil ==============NEXT SERVICE FINGERPRINT (SUBMIT INDIVIDUALLY)============== SF-Port381-TCP:V=3.50%D=11/29%Time=41AB4F42%P=i386-redhat-linux-gnu%r(HT TP SF:Options,AA,"HTTP/1\.1\x20404\x20Not\x20Found\r\ncontent-length:\x200\ r\ SF:ncontent-type:\x20application/octetstream\r\ndate:\x20Mon,\x2029\x20N ov SF:\x202004\x2016:35:20\x20GMT\r\nserver:\x20BBC\x202\.6\.4\.2;\x20com\. hp SF:\.openview\.Coda\x200\.0\.1\r\n\r\n")%r(RTSPRequest,CE,"HTTP/1\.1\x20 50 SF:5\x20HTTP\x20Version\x20not\x20supported\r\nconnection:\x20close\r\nc on SF:tent-length:\x200\r\ncontent-type:\x20application/octetstream\r\ndate :\ SF:x20Mon,\x2029\x20Nov\x202004\x2016:35:24\x20GMT\r\nserver:\x20BBC\x20 2\ SF:.6\.4\.2;\x20com\.hp\.openview\.Coda\x200\.0\.1\r\n\r\n"); ==============NEXT SERVICE FINGERPRINT (SUBMIT INDIVIDUALLY)============== SF-Port383-TCP:V=3.50%D=11/29%Time=41AB4F47%P=i386-redhat-linux-gnu%r(RT SP SF:Request,D9,"HTTP/1\.1\x20505\x20HTTP\x20Version\x20not\x20supported\r \n SF:connection:\x20close\r\ncontent-length:\x200\r\ncontent-type:\x20appl ic SF:ation/octetstream\r\ndate:\x20Mon,\x2029\x20Nov\x202004\x2016:35:25\x 20 SF:GMT\r\nserver:\x20BBC\x202\.6\.4\.2;\x20com\.hp\.openview\.bbc\.LLBSe rv SF:er\x202\.6\.4\.2\r\n\r\n"); And finally, I used NetCat to try and manually connect to the 2 ports in question and got the following results: nc -vv exchcil 381 exchcil.DOMAIN.com [10.ADDR.71] 381 (?) open GET / HTTP/1.1 505 HTTP Version not supported connection: close content-length: 0 content-type: application/octetstream date: Mon, 29 Nov 2004 16:41:47 GMT server: BBC 2.6.4.2; com.hp.openview.Coda 0.0.1 sent 6, rcvd 206 nc -vv exchcil 383 exchcil.DOMAIN.com [10.ADDR.71] 383 (?) open GET / HTTP/1.1 505 HTTP Version not supported connection: close content-length: 0 content-type: application/octetstream date: Mon, 29 Nov 2004 16:42:20 GMT server: BBC 2.6.4.2; com.hp.openview.bbc.LLBServer 2.6.4.2 sent 6, rcvd 217 Anyone have any more thoughts or ideas? Thanks, Chris Sawall, GSEC, GSNA Ameren Information Security 314-554-2086 ******************************* The information contained in this message may be privileged and/or confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. Note that any views or opinions presented in this message are solely those of the author and do not necessarily represent those of Ameren. All emails are subject to monitoring and archival. Finally, the recipient should check this message and any attachments for the presence of viruses. Ameren accepts no liability for any damage caused by any virus transmitted by this email. If you have received this in error, please notify the sender immediately by replying to the message and deleting the material from any computer. Ameren Corporation ******************************* _______________________________________________ Nessus mailing list [EMAIL PROTECTED] http://mail.nessus.org/mailman/listinfo/nessus
