Error when trying to generate the transcript - Squert 1.3.0
Closed this issue · 4 comments
Hi,
I installed Squert 1.3.0 on a existing Security Onion installation (12.04) following your installation procedure.
I managed to fix almost all the issues, but I'm stuck with this one: when I try to generate a transcript, I get the following error:
"Caught exception while sending data: error writing "sock3": software caused connection abort"
Thanks to put me on the way to fix this.
D.
Have you upgraded to sguil 0.9.0? If not there will be some things that won't work (transcripts should still work though)
Did you upgrade tcpflow? The newer versions (1.4.) try to write 'alerts.txt' and 'report.xml' to the directory where sguild resides (I think /usr/bin in SO?) which the user running sguild probably doesn't have write access to. This will cause the tx to fail. The only workaround for this right now is to use an older version of tcpflow.
Thanks for your feedback.
Indeed I'm still running Sguil 0.8.0.
I am now seeing why the error occurs in the sguild log file:
2014-06-10 11:23:02 pid(7623) Sensor Data Rcvd: SnortStats {3 0.000 0.014 0.000 0.015 112 313.810 0.238 0.202 236 {2014-06-10 11:22:19}}
2014-06-10 11:23:06 pid(7623) Client Connect: 127.0.0.1 39774 sock39
2014-06-10 11:23:06 pid(7623) Validating client access: 127.0.0.1
2014-06-10 11:23:06 pid(7623) Valid client access: 127.0.0.1
2014-06-10 11:23:06 pid(7623) Sending sock39: SGUIL-0.8.0 OPENSSL ENABLED
2014-06-10 11:23:06 pid(7623) Client Command Received: VersionInfo {SGUIL-0.8.0 OPENSSL ENABLED}
2014-06-10 11:23:07 pid(7623) ERROR: handshake failed: sslv3 alert handshake failure
2014-06-10 11:23:07 pid(7623) No clients to send info msg to.
2014-06-10 11:23:07 pid(7623) Error from socket sock39: SSL channel "sock39": error: sslv3 alert handshake failure
2014-06-10 11:23:07 pid(7623) Closing socket.
I will try to troubleshoot this.
If you know where to look, I'd be happy to hear it from you.
About tcpflow, I plan to investigate it later once this sguild error is fixed.
Br,
D.
Ahh.. of course. VictorJ submitted a patch for sguil that changed how ssl was established.
This might help:
Hi,
Thanks it helped a lot. In fact, I just changed the following in the cliscript.tcl:
#if { [catch {tls::import $socketID -ssl2 false -ssl3 false -tls1 true } tlsError] } {
and use the following:
tls::import $socketID
I expect that sguild 0.8.0 doesn't handle sslv3 or tlsv1 very well, so it comes back to v2. I know it's not good, but hopefully the fw blocks this port from the network :)
Br,
D.