Riffraff and H20 still not perfected...

...but I'm getting closer to discovering where the breakdown's occurring. So far, one of Richard's excellent scripts tries to give sguil ownership of an object, and that object doesn't exist. I'm also having trouble getting barnyard-sguil6 downloaded via either the script or manually, but I'm working hard to ensure the barnyard-sguil6 package is installed from a trusted source and doing what it's supposed to.

Unfortunately, Riffraff's begun to act oddly. I think it's all the banging around that's happened due to Riffraff having a fairly rounded-bottomed case. I'm planning to get in there tonight and tighten down everything that appears to be loose.

Ergh.

"SGUILD: loaderd: Creating sancp table (daterange)"
"SGUILD: Unknown command recieved from loaderd:"
"SGUILD: Lost communication with loaderd"

This issue is still occurring. I wonder if I have to name every database (sensor, event, portscan, sessions, sancp) within MySQL. But if that's the case, why give the example "GRANT FILE ON *.* TO sguil@localhost; FLUSH PRIVILEGES;" on the Sguil FAQ? Shouldn't that automatically grant FILE on all tables in MySQL to sguil@localhost?

I'm confused. Especially as to why before it would die after 48 hours, and now it dies after 100. I'd like to ask on #snort-gui but I'm afraid I may not have time tomorrow morning.

Missed Tuesday's SUG meeting

Yes, I missed it. The Seattle Snort Users' Group meeting was on Tuesday, and I did not have permission to go. Wanted to, though.

I think I maybe understand why Riffraff and Nessie were having such problems with dangling pointers--I believe something didn't install properly off the script. That would explain why I've had to add the sguil user again AND why the system, even when it's got all the components up, won't let Magenta talk to it (whether Riffraff or Nessie).

Before, it would give dangling pointer errors after a time--usually 8 to 12 hours post-startup. It's been over 48 hours and Nessie is still up and running. Logging packets, too.

Perhaps it's time to learn more about scripting, so I can maybe improve these scripts to throw errors when something doesn't work as expected...?

http://sguil.sourceforge.net/index.php?page=faq#5.11_Sguild_loaderd_dies_while

Did so for sguil@localhost, sguil@magenta, sguil@magenta.company.com. Rebooted. Tried to start services again--not sure sguild_start.sh worked. Not seeing port 7734 on the sockstat -4 | grep -v sshd list...

Oh, there it is. It's looking good.

The answer?

Googling the first error returned this information: http://comments.gmane.org/gmane.comp.security.sguil.devel/151

If they mean "do a grant all on the mysql database for the user sguil and any others", I've done it already. Actually, I could reboot the thing and try again, but I remember adding nessie@localhost, nessie@company.com, magenta@localhost, magenta@company.com and such to the mysql database. What else did I maybe miss?

Gooling the second error returned a page that doesn't have what Google says it had on it, even under the cache:

gmane.comp.security.sguil.devel
This is the error I got from the sensor : Received : Failed to insert ... 3 - 1097875 ' for key 1 Expected Confirm 1097876 and got : Failed to insert ...
blog.gmane.org/gmane.comp.security.sguil.devel/page=1 - 42k - Supplemental Result - Cached - Similar pages

Oh, well. I should be thankful it's at least still able to be reached via PuTTY.

Oh. That's why...

After trying for days to get Magenta to talk to Nessie, I finally went over to the other building to check on her myself. I expected maybe to find a cable unplugged or something, but this familiar sight greeted me:

May 9 07:45:20 nessie SGUILD: Lost communication with loaderd.
may 9 07:59:40 nessie Barnyard[2250]: FATAL ERROR: Expected Confirm 7021 and got: Failed to insert 7021: mysqlexec: handle already closed (dangling pointer)

Hooray. Same error that prompted me to try to get Riffraff figured out at home is now happening on Nessie. At least this time I remembered to write it down. This would be why the two stopped talking.

Hmm...

Magenta and the new test box, Nessie, aren't talking to one another. I've tried adding lines like:

mysql -e "GRANT ALL on sguildb.* to sguil@magenta"
mysql -e "GRANT ALL on sguildb.* to sguil@magenta"
mysql -e "SET password for sguil@magenta=password('something')"
mysql -e "SET password for sguil@magenta.domain.com=password('something')"

I wonder if it's because Magenta is on 10.153.x.x, and Nessie is on 10.154.x.x? But if so, why did it work the other day between Riffraff and Magenta? I've got an entry in sguild.users, and I've definitely got port 7734 open.

But each time I still get an "unable to connect to 10.154.x.x on port 7734" message.

the latest frustration: a timeline

The Monday after the meeting: Place Riffraff at the remote (but still in-town) office. Have Magenta talk to Riffraff. Smile.

The Tuesday after the meeting: Become busy bee, working on another project that needs finishing. Scowl at monitor a lot. Finish. Smile.

The Wednesday after the meeting: Offer to show boss a demo of the Sguil boxes. Boss agrees. Attempt to connect to Riffraff...nothing. Install putty. Attempt again to connect to Riffraff...still nothing. Sigh. Become concerned with fixing Riffraff, since something's obviously wrong.

The Thursday after the meeting: Drive to remote office, plug in keyboard and monitor. Notice MySQL error...dangling pointer? Why? Sigh again. Reboot machine; talk to Riffraff from Magenta from the corporate office. Bliss.

The Friday after the meeting: Get too busy to look up the error. Realize that not only do I not have time to on Friday, but probably won't have time during the weekend.

The Saturday and Sunday after the meeting: Get too busy to look up the error. Weekends sure go fast...too much to pack into them...

Monday (05/01/06): Try to connect to Riffraff from Magenta while at the corporate office, which is my home base. Attempt to connect to Riffraff...and get nothing. No response from an attempt to use putty, either. Drive to remote office. Notice mysql dangling pointer error again. Sigh twice. Take Riffraff home for analysis and resolution of issue with dangling pointer.

Tuesday: Google "dangling pointer freebsd mysql". Come up with hits that relate in no way to the issue at hand. Spend hours reading through websites and attempting to navigate the really information-packed mysql site. Realize I'm not sure how to even troubleshoot the issue, as I'm not sure which mysql component is throwing the error. Is it mysqltcl? mysqld? Bang head against desk. Start looking through /var/db logs. Find nothing. Decide to run Riffraff on my home network for a week, to see if the issue isn't replicatable.