Snort update coming soon – please read about an important change!
-
Is there any fix for the duplicate entry mysql issue with Barnyard2? I have started with a fresh Snorby install and DB, and after 5 minutes barnyard2 stops with the duplicate entry. I have cleared the sig_reference table and still get the same issue.
I posted a new thread last evening containing links to two potential solutions. Those worked for me on my Snorby install, but admittedly I only have a home network's traffic being logged so not very many events at all. Here is link to that thread: https://forum.pfsense.org/index.php?topic=75357.0
Also, I'm a bit confused by your two successive posts. The first one at 8:51 AM says you fixed the problem by removing the sensor name, but then your newer one at 8:55 AM implies the problem still exists. What underlying DB engine is your MySQL install using? The Barnyard2 developers say it must be InnoDB.
Bill
-
Is there any fix for the duplicate entry mysql issue with Barnyard2? I have started with a fresh Snorby install and DB, and after 5 minutes barnyard2 stops with the duplicate entry. I have cleared the sig_reference table and still get the same issue.
I posted a new thread last evening containing links to two potential solutions. Those worked for me on my Snorby install, but admittedly I only have a home network's traffic being logged so not very many events at all. Here is link to that thread: https://forum.pfsense.org/index.php?topic=75357.0
Also, I'm a bit confused by your two successive posts. The first one at 8:51 AM says you fixed the problem by removing the sensor name, but then your newer one at 8:55 AM implies the problem still exists. What underlying DB engine is your MySQL install using? The Barnyard2 developers say it must be InnoDB.
Bill
Bill - thanks.. I am trying your fixes now.. I have a production firewall/IDS in place that I can generate a ton of events from so I can put it to a good test in a few..
Im using InnoDB with the mysql install - it's actually a fresh Security Onion install that I am logging to.
The issue I fixed with removing the sensor name was not the duplicate entry problem. It was the problem of Barnyard2 wanting to log into mysql with the "root" user instead of whatever user you put in as the mysql username in the barnyard2 tab. If I put in a sensor name (versus leaving it blank) then barnyard always tries to login as 'root'. If I leave the sensor name blank, it logs in properly. It does this with multiple sensors.
-
Is there any fix for the duplicate entry mysql issue with Barnyard2? I have started with a fresh Snorby install and DB, and after 5 minutes barnyard2 stops with the duplicate entry. I have cleared the sig_reference table and still get the same issue.
I posted a new thread last evening containing links to two potential solutions. Those worked for me on my Snorby install, but admittedly I only have a home network's traffic being logged so not very many events at all. Here is link to that thread: https://forum.pfsense.org/index.php?topic=75357.0
Also, I'm a bit confused by your two successive posts. The first one at 8:51 AM says you fixed the problem by removing the sensor name, but then your newer one at 8:55 AM implies the problem still exists. What underlying DB engine is your MySQL install using? The Barnyard2 developers say it must be InnoDB.
Bill
Bill - thanks.. I am trying your fixes now.. I have a production firewall/IDS in place that I can generate a ton of events from so I can put it to a good test in a few..
Im using InnoDB with the mysql install - it's actually a fresh Security Onion install that I am logging to.
The issue I fixed with removing the sensor name was not the duplicate entry problem. It was the problem of Barnyard2 wanting to log into mysql with the "root" user instead of whatever user you put in as the mysql username in the barnyard2 tab. If I put in a sensor name (versus leaving it blank) then barnyard always tries to login as 'root'. If I leave the sensor name blank, it logs in properly. It does this with multiple sensors.
Thanks for the feedback on the sensor name anomaly. I will look into that. Could be I have a mistake in the code someplace. I know I never coded "root" by design, but I do have fat fingers when typing… :(
Bill
-
Is there any fix for the duplicate entry mysql issue with Barnyard2? I have started with a fresh Snorby install and DB, and after 5 minutes barnyard2 stops with the duplicate entry. I have cleared the sig_reference table and still get the same issue.
I posted a new thread last evening containing links to two potential solutions. Those worked for me on my Snorby install, but admittedly I only have a home network's traffic being logged so not very many events at all. Here is link to that thread: https://forum.pfsense.org/index.php?topic=75357.0
Also, I'm a bit confused by your two successive posts. The first one at 8:51 AM says you fixed the problem by removing the sensor name, but then your newer one at 8:55 AM implies the problem still exists. What underlying DB engine is your MySQL install using? The Barnyard2 developers say it must be InnoDB.
Bill
Bill - thanks.. I am trying your fixes now.. I have a production firewall/IDS in place that I can generate a ton of events from so I can put it to a good test in a few..
Im using InnoDB with the mysql install - it's actually a fresh Security Onion install that I am logging to.
The issue I fixed with removing the sensor name was not the duplicate entry problem. It was the problem of Barnyard2 wanting to log into mysql with the "root" user instead of whatever user you put in as the mysql username in the barnyard2 tab. If I put in a sensor name (versus leaving it blank) then barnyard always tries to login as 'root'. If I leave the sensor name blank, it logs in properly. It does this with multiple sensors.
Thanks for the feedback on the sensor name anomaly. I will look into that. Could be I have a mistake in the code someplace. I know I never coded "root" by design, but I do have fat fingers when typing… :(
Bill
Anytime, and anything I can do to help…
The first link you posted fixed the duplicate entry issue - BUT - although I now see events in Snorby, the dashboard is not showing any events, but when I look at events or sensors is shows all the events (I have a few thousand events now).. any ideas?
-
Hi gscasny,
Did you do a full Security Onion install or is this a Virtual Machine ISO boot?
Would be interested to know the steps you took to get pfSense to SO working?
Are the alerts visible in SGUIL or just Snorby?
Appreciate any info you can share.
Thanks in advance.
-
@BBcan17:
Hi gscasny,
Did you do a full Security Onion install or is this a Virtual Machine ISO boot?
Would be interested to know the steps you took to get pfSense to SO working?
Are the alerts visible in SGUIL or just Snorby?
Appreciate any info you can share.
Thanks in advance.
It's a full install. It's a "Server" install from the "Advanced" install as I run Snort on our edge FW's as sensors. I am logging only to Snorby at the moment, as SGUIL is on my list after OSSEC as we currently use OSSEC at client sites but not via Sec onion…. it bums me a little that SGUIL X windows application only... But I am happy to share any/all info I find out..
-
S.O. is great. I have OSSEC running on all of my Windows and Linux servers (Works really slick) Let me know if you need any help with that.
I run Snort on our edge FW's as sensors.
Are these SO sensors or pfSense snort?
I'm not sure what you mean by "SGUIL X windows application only"?
-
@BBcan17:
S.O. is great. I have OSSEC running on all of my Windows and Linux servers (Works really slick) Let me know if you need any help with that.
I run Snort on our edge FW's as sensors.
Are these SO sensors or pfSense snort?
I'm not sure what you mean by "SGUIL X windows application only"?
The sensors are our build of pfsense.
SGUIL X win only - meaning I have to run the interface in X, instead of via a web interface like Snorby or ELSA (which I don't use..we use a SIEM product for log storage and correlation)..
I really like OSSEC as a host ids.. we have a few installs, but I am looking to standardize the deployment and monitoring of OSSEC along with our IDS sensors and SIEM…
-
ok. I am using Xrdp for Sguil. Another option is just to load a VM from the live ISO cd and map the ports from there?
pfSense
What did you use as the Database name and credentials? I thought that SO uses "root" without a password?
Enable Barnyard
Add Dump payload ?
Sensor name = pfsenseEnable MySQL
hostname = x.x.x.x
Database name =
Database User =
Database password =Advanced Settings ?
S.O.
In Security Onion, what port do you need to open up in UFW? 8000?
I understood that SO only listens on the local host only?
Can you detail what you changed in SO?
This is my /etc/nsm/<sensor>/barnyard2.conf file
config logdir: /nsm/sensor_data/ <sensor>config classification_file: /etc/nsm/<sensor>/classification.config
config reference_file: /etc/nsm/<sensor>/reference.config
config sid_file: /etc/nsm/<sensor>/sid-msg.map
config gen_file: /etc/nsm/<sensor>/gen-msg.map
config hostname: <sensor>config interface: eth1
input unified2
output sguil: sensor_name= <sensor>agent_port=8000
output database: alert, mysql, user=root dbname=snorby host=127.0.0.1
output alert_syslog: LOG_LOCAL6 LOG_ALERTI predominantly use SGUIL as I think its a total Workhorse of a tool. Ver 0.9.0 was recently released a few weeks ago. I have the Server setup as a single sensor installation and one remote sensor. Wouldn't the pfense Barnyard2 info overlap into the existing sensors info?
Wouldn't it be better to setup a separate sensor for pfsense?
As I don't use Snorby, I wonder if I could disable events from SO and use that for pfSense? Getting it all into SGUIL would ultimately be the best setup. Wonder if SO iptables could forward the pfsense incoming port to the local host of SO? I dont think I would want to re-compile the SO Barnyard2 application to listen on its actual interface.</sensor></sensor></sensor></sensor></sensor></sensor></sensor></sensor> -
@BBcan17:
ok. I am using Xrdp for Sguil. Another option is just to load a VM from the live ISO cd and map the ports from there?
pfSense
What did you use as the Database name and credentials? I thought that SO uses "root" without a password?
Enable Barnyard
Add Dump payload ?
Sensor name = pfsenseEnable MySQL
hostname = x.x.x.x
Database name =
Database User =
Database password =Advanced Settings ?
S.O.
In Security Onion, what port do you need to open up in UFW? 8000?
I understood that SO only listens on the local host only?
Can you detail what you changed in SO?
This is my /etc/nsm/<sensor>/barnyard2.conf file
config logdir: /nsm/sensor_data/ <sensor>config classification_file: /etc/nsm/<sensor>/classification.config
config reference_file: /etc/nsm/<sensor>/reference.config
config sid_file: /etc/nsm/<sensor>/sid-msg.map
config gen_file: /etc/nsm/<sensor>/gen-msg.map
config hostname: <sensor>config interface: eth1
input unified2
output sguil: sensor_name= <sensor>agent_port=8000
output database: alert, mysql, user=root dbname=snorby host=127.0.0.1
output alert_syslog: LOG_LOCAL6 LOG_ALERTI predominantly use SGUIL as I think its a total Workhorse of a tool. Ver 0.9.0 was recently released a few weeks ago. I have the Server setup as a single sensor installation and one remote sensor. Wouldn't the pfense Barnyard2 info overlap into the existing sensors info?
Wouldn't it be better to setup a separate sensor for pfsense?
As I don't use Snorby, I wonder if I could disable events from SO and use that for pfSense? Getting it all into SGUIL would ultimately be the best setup. Wonder if SO iptables could forward the pfsense incoming port to the local host of SO? I dont think I would want to re-compile the SO Barnyard2 application to listen on its actual interface.</sensor></sensor></sensor></sensor></sensor></sensor></sensor></sensor>Ok - Ill start from the top and work my way down :)
xrdp is ok if you are local, but we support alot of customers all over the country and alot don't have the fastest inet connections, so tunneling x win over their links isn't feasible. :)
As far as database credentials, SO uses root with no password for local only logins… you can't login a remote sensor with root, nor would you want to, so we create a user per sensor - i.e. location-fw-interface in mysql and only give them privs on the snorby DB.
after that we open port 3306 (mysql) ONLY from the sensor to the security onion box (we delete all other ufw rules except port 444 for snorby), I don't like that SO allows connections from anywhere.
You also have to go into /etc/mysql/my.conf and change the 'bind address' to 0.0.0.0 and then do a 'service restart mysql' - it defaults to 127.0.0.1 which will not allow your remote sensors to connect.
We run our main sensors at the perimeter via our build of PFsense as we use the block function of snort on the WAN and LAN via a cutomized ET Pro ruleset and we use pfblocker with several customized ip block lists.. but since snort runs in userspace, we get reports on the blocked ip's via snort. It's important to us to catch, log an block any attacks at the perimeter, which Pfsense is amazingly efficient at.
We dont run any sensors on SO at the moment..though I would not mind testing Bro in conjunction with snort as it doesn't use signatures from what we have read.
The biggest thing for us is to be able to monitor and alerts exception (high severity) alerts as we monitor alot of networks (hundreds) along with our SIEM to keep any breach attempts to a minimum.
-
Ok - Ill start from the top and work my way down :)
xrdp is ok if you are local, but we support alot of customers all over the country and alot don't have the fastest inet connections, so tunneling x win over their links isn't feasible. :)
As far as database credentials, SO uses root with no password for local only logins… you can't login a remote sensor with root, nor would you want to, so we create a user per sensor - i.e. location-fw-interface in mysql and only give them privs on the snorby DB.
I found this link http://community.spiceworks.com/topic/466735-security-onion-and-pfsense
Does this look correct?
===========================
Open the terminal run the following commands
This will allow your pfsense to connect through Security Onions firewall to mysql
sudo ufw allow proto tcp from xx.xx.xx.xx/32 to any port 3306
mysql
This should open the prompt for mysql, run the following commands hereshow databases;
Make sure the databasesnorbyexists.This part will setup a user for Barnyard2 to use
create user 'sensorname'@'xx.xx.xx.xx' IDENTIFIED BY 'SENSORPASSWORD'
grant all privileges on snorby. to 'sensorname'@'xx.xx.xx.xx' with grant option;*
flush privileges;
exit
You should be out of the mysql prompt now, run these commands in terminalThis will allow any device to connect to mysql as MySQL will be listening for connections on any IP instead of just the loopback address (assuming its allowed through Security Onions firewall)
sudo vi /etc/mysql/my.cnf
You should have the mysql config open, use the down arrows to move down until you see the part that says
bind-address
Move the cursor (The one in the terminal window that indicates where you're typing) to where it says "= 127.0.0.1" and type 'i' (Without the ' )
It should say "– INSERT --" at the the bottom of the terminal window
Delete 127.0.0.1 and replace it with 0.0.0.0
Press 'esc' so that "– INSERT --" is gone, then type ':wq!' and hit return (Without the ' but with the Colon )
This should save and exit viNow run the command
sudo mysql restart
Wait for the MySQL Service to restartSetup Barnyard2 on pfSense in Snort
In web interface for pfSense goto Services > Snort, Under Snort Interfaces Click the
Editbutton and open the Barnyard2 tabChange and input the following settings in the
Log to MySQL Databasefieldoutput database: alert, mysql, dbname=snorby user=sensorname host=xx.xx.xx.yy password=SENSORPASSWORD
Save
goto Services > Snort > Snort Interfaces
Click the start Icon next under the Barnyard 2 Column, wait for it to go green.===========================
We run our main sensors at the perimeter via our build of PFsense as we use the block function of snort on the WAN and LAN via a cutomized ET Pro ruleset and we use pfblocker with several customized ip block lists.. but since snort runs in userspace, we get reports on the blocked ip's via snort. It's important to us to catch, log an block any attacks at the perimeter, which Pfsense is amazingly efficient at.
As SO is using "SALT", it would be good to try to incorporate that into the mix to mange the rules update process. But I guess as pfSense Snort is not using Pulled Pork that might not work? Salt is on the Freebsd ports.
Snort now has the IPrep processor which could replace pfBlocker functionality. The current pfsense integration doesn't reload the blocklists automatically when they are updated so will need to wait for the next release to see if that is fixed.
We don't run any sensors on SO at the moment..though I would not mind testing Bro in conjunction with snort as it doesn't use signatures from what we have read.
The biggest thing for us is to be able to monitor and alerts exception (high severity) alerts as we monitor alot of networks (hundreds) along with our SIEM to keep any breach attempts to a minimum.
Will changing mysql to 0.0.0.0 affect SO at all?
Getting the pfSense snort into Sguil would make this a whole lot better. The BRO integration would be much better.
I need to see if I can get Snorby to only listen to the pfSense boxes and not the local sensor installations.
Does pfSense push the full pcaps of the alert to SO Snorby? or just the alert?
Thanks for your help.
-
Anytime, and anything I can do to help…
The first link you posted fixed the duplicate entry issue - BUT - although I now see events in Snorby, the dashboard is not showing any events, but when I look at events or sensors is shows all the events (I have a few thousand events now).. any ideas?
I have seen other posts on Google relative to Snorby and the disappearing of the Dashboard events. It's something with the background cache jobs if I recall. I had that problem once several months ago, and some protracted Google searches led me to the fix. Sorry, but I don't remember exactly what fixed it or I would readily share.
Bill
-
@BBcan17:
Getting the pfSense snort into Sguil would make this a whole lot better. The BRO integration would be much better.
Thanks for your help.
I would love to send Snort's unified2 output to Squil. The problem is that currently, for some unknown reason, Barnyard2 will only connect to a local Sguil sensor. I was thinking about submitting a request to the upstream Barnyard2 guys to see if they would make it a remote connection option. You can set the port, but it always defaults to 127.0.0.1 for the IP address. That is hard-coded into the Barnyard2 source code.
Bill
-
@BBcan17:
Getting the pfSense snort into Sguil would make this a whole lot better. The BRO integration would be much better.
Thanks for your help.
I would love to send Snort's unified2 output to Squil. The problem is that currently, for some unknown reason, Barnyard2 will only connect to a local Sguil sensor. I was thinking about submitting a request to the upstream Barnyard2 guys to see if they would make it a remote connection option. You can set the port, but it always defaults to 127.0.0.1 for the IP address. That is hard-coded into the Barnyard2 source code.
Bill
Couldn't IPTABLES forward a listening port to the local port to get that to work?
I agree that recompiling Barnyard2 is not my first option….
EDIT:
Check this link
-
@BBcan17:
@BBcan17:
Getting the pfSense snort into Sguil would make this a whole lot better. The BRO integration would be much better.
Thanks for your help.
I would love to send Snort's unified2 output to Squil. The problem is that currently, for some unknown reason, Barnyard2 will only connect to a local Sguil sensor. I was thinking about submitting a request to the upstream Barnyard2 guys to see if they would make it a remote connection option. You can set the port, but it always defaults to 127.0.0.1 for the IP address. That is hard-coded into the Barnyard2 source code.
Bill
Couldn't IPTABLES forward a listening port to the local port to get that to work?
I agree that recompiling Barnyard2 is not my first option….
EDIT:
Check this link
Yeah, that first link is the one I found while doing the Suricata package. I was thinking about just modifying the BY2 source on pfSense, but the Core Team prefers to use plain vanilla ports whenever possible and I can understand why. It would be better to have the BY2 guys just add an option for remote Sguil connectivity to their code. It should be an easy option to add.
Bill
-
@BBcan17:
Ok - Ill start from the top and work my way down :)
xrdp is ok if you are local, but we support alot of customers all over the country and alot don't have the fastest inet connections, so tunneling x win over their links isn't feasible. :)
As far as database credentials, SO uses root with no password for local only logins… you can't login a remote sensor with root, nor would you want to, so we create a user per sensor - i.e. location-fw-interface in mysql and only give them privs on the snorby DB.
I found this link http://community.spiceworks.com/topic/466735-security-onion-and-pfsense
Does this look correct?
===========================
Open the terminal run the following commands
This will allow your pfsense to connect through Security Onions firewall to mysql
sudo ufw allow proto tcp from xx.xx.xx.xx/32 to any port 3306
mysql
This should open the prompt for mysql, run the following commands hereshow databases;
Make sure the databasesnorbyexists.This part will setup a user for Barnyard2 to use
create user 'sensorname'@'xx.xx.xx.xx' IDENTIFIED BY 'SENSORPASSWORD'
grant all privileges on snorby. to 'sensorname'@'xx.xx.xx.xx' with grant option;*
flush privileges;
exit
You should be out of the mysql prompt now, run these commands in terminalThis will allow any device to connect to mysql as MySQL will be listening for connections on any IP instead of just the loopback address (assuming its allowed through Security Onions firewall)
sudo vi /etc/mysql/my.cnf
You should have the mysql config open, use the down arrows to move down until you see the part that says
bind-address
Move the cursor (The one in the terminal window that indicates where you're typing) to where it says "= 127.0.0.1" and type 'i' (Without the ' )
It should say "– INSERT --" at the the bottom of the terminal window
Delete 127.0.0.1 and replace it with 0.0.0.0
Press 'esc' so that "– INSERT --" is gone, then type ':wq!' and hit return (Without the ' but with the Colon )
This should save and exit viNow run the command
sudo mysql restart
Wait for the MySQL Service to restartSetup Barnyard2 on pfSense in Snort
In web interface for pfSense goto Services > Snort, Under Snort Interfaces Click the
Editbutton and open the Barnyard2 tabChange and input the following settings in the
Log to MySQL Databasefieldoutput database: alert, mysql, dbname=snorby user=sensorname host=xx.xx.xx.yy password=SENSORPASSWORD
Save
goto Services > Snort > Snort Interfaces
Click the start Icon next under the Barnyard 2 Column, wait for it to go green.===========================
We run our main sensors at the perimeter via our build of PFsense as we use the block function of snort on the WAN and LAN via a cutomized ET Pro ruleset and we use pfblocker with several customized ip block lists.. but since snort runs in userspace, we get reports on the blocked ip's via snort. It's important to us to catch, log an block any attacks at the perimeter, which Pfsense is amazingly efficient at.
As SO is using "SALT", it would be good to try to incorporate that into the mix to mange the rules update process. But I guess as pfSense Snort is not using Pulled Pork that might not work? Salt is on the Freebsd ports.
Snort now has the IPrep processor which could replace pfBlocker functionality. The current pfsense integration doesn't reload the blocklists automatically when they are updated so will need to wait for the next release to see if that is fixed.
We don't run any sensors on SO at the moment..though I would not mind testing Bro in conjunction with snort as it doesn't use signatures from what we have read.
The biggest thing for us is to be able to monitor and alerts exception (high severity) alerts as we monitor alot of networks (hundreds) along with our SIEM to keep any breach attempts to a minimum.
Will changing mysql to 0.0.0.0 affect SO at all?
Getting the pfSense snort into Sguil would make this a whole lot better. The BRO integration would be much better.
I need to see if I can get Snorby to only listen to the pfSense boxes and not the local sensor installations.
Does pfSense push the full pcaps of the alert to SO Snorby? or just the alert?
Thanks for your help.
Everything looks good but I will make a few comments:
You really don't need "GRANT" options with the sensor user from what I can see.. no need to add extra vulnerabilities if not needed, no matter how remote.
Changing the mysql bind address to 0.0.0.0 just tell's mysql to listen on all interfaces… if you have more than 1 you can force it to listed on a specific interface by putting that interface's IP address as the bind address instead.SQUIL is good for looking at all alerts in detail, but we look more for exceptions and then if we see an issue dig into the SIEM for details, unless they are obvious from the snort alerts.
If you install SO as a "Server" instead of a "Sensor" or "Both" it will run as a collector versus a sensor (no local instances of snort or suricata).
PFsense just pushes the alerts, no pcap data from what we use.
-
SQUIL is good for looking at all alerts in detail, but we look more for exceptions and then if we see an issue dig into the SIEM for details, unless they are obvious from the snort alerts.
If you install SO as a "Server" instead of a "Sensor" or "Both" it will run as a collector versus a sensor (no local instances of snort or suricata).
PFsense just pushes the alerts, no pcap data from what we use.
Once you F8 (categorize) events in SGUIL or Snorby you need ELSA or another SIEM to do the rest of the detective work. ELSA is really nice can pivot on Snort/Suricata/BRO/OSSEC/Sancp/pads and Syslogs. I push all of my pfSense syslogs (Firewall and Syslogs) to ELSA.
pfSense needs a one-line patch to get it to work properly with ELSA.
http://files.pfsense.org/jimp/patches/pf-log-oneline-option-2.1.1.diffIf you arent getting the full pcap you are missing a lot of info. This is why I like Security Onions Distributed Architecture. The Sensors can be deployed anywhere. All of the local devices push their data to the remote SO Sensor and the sensor records all of the info locally. Than from the SO Server, it can pull as required from any of the sensors. So SGUIL or Snorby will be able to read the full packet capture from any of the remote sites without having a large footprint.
Also SO uses SALT which can manage all of the RULES for all of the Sensors and it makes life a lot easier.
If we can get the full Pcap from pfSense into SO, that would be a big help to manage False Positives. Managing several devices under one umbrella makes life a little easier so we can spend our time analyzing versus configuring and updated all over the place.
Hopefully we can convince (nudge nudge) Mr. Meeks in helping get pfSense to work well with SO?? ;) ;)
-
This is a barnyard error. Are you using i386 or x64?
x64. This error appears limited to only Barnyard, as Snort will startup without it but I'm unsure given that the issue initially began with signature errors which was a past problem pfSense version issue with Snort's rules.
This version of the Snort package made some big changes to Barnyard2 like adding more output plugins. One side effect of that was it needed to reconfigure how the MySQL DB login info was stored. I wrote some code in the installation routines that attempts to migrate the old MySQL settings to the new format. It is possible some old settings could trip it up. Your error is a MySQL login error, and when the login fails Barnyard2 will stop. Go to the Barnyard tab in Snort and manually re-enter the login ID and password for the MySQL DB, then click Save. Try to start Barnyard2 after that on the Snort Interfaces tab.
Bill
Yeah, I'd believe that it was a caching thing or a transfer at the start but then I did this:
In desperation following a remove / install of Snort still facing the same issues, I cleanwiped the drive and reinstalled pfSense from scratch - that is to say, clean from a CD with no imports from a previous config file, everything reentered by hand - and the error remains the same. pfSense is determined to use root only root and nothing but root, and I'm not gonna let it; especially when everything says it should be using the proper user that for some reason it is ignoring.
Gonna go out on a limb and say that it isn't a transfer issue. It simply isn't reading the configuration I gave it - the files I checked in Barynard's conf and the conf.xml for pfSense, as well as the GUI, are all pointing to the correct login but pfSense is still attempting to login with root and getting refused. Reentering the information by hand has no effect.
I think I found the cause of Barnyard2 trying to login to the DB as "root". It happened when a sensor name value was provided (that is, when the field was not blank). The code was including a comma after the sensor name in the barnyard2.conf file and there is not supposed to be one there. That was apparently confusing the parser for Barnyard2. The latest update for the Snort package that is being reviewed by the Core Team has this fixed. When they approve and merge the change, a new Snort update will appear under System…Packages.
Bill
-
I went ahead and grab the changes you made before the merge. Would it be possible to change the order of the database output? If I select the disable_signature_reference_table option (BTW you beat me too it, I started to test this option last night and was able to turn up 2 interfaces with no dup error), the 'root' error happens again when it tries to connect to mysql.
Right now the order is:
output database: log, mysql, sensor_name=pfsense_lan disable_signature_reference_table user=snort password=ABC123 dbname=snort host=someboxAfter reading barnyard2's README.database doc, it seems to work in this order:
output database: log, mysql, user=snort password=ABC123 dbname=snort host=somebox sensor_name=pfsense_lan disable_signature_reference_table -
I went ahead and grab the changes you made before the merge. Would it be possible to change the order of the database output? If I select the disable_signature_reference_table option (BTW you beat me too it, I started to test this option last night and was able to turn up 2 interfaces with no dup error), the 'root' error happens again when it tries to connect to mysql.
Right now the order is:
output database: log, mysql, sensor_name=pfsense_lan disable_signature_reference_table user=snort password=ABC123 dbname=snort host=someboxAfter reading barnyard2's README.database doc, it seems to work in this order:
output database: log, mysql, user=snort password=ABC123 dbname=snort host=somebox sensor_name=pfsense_lan disable_signature_reference_tableDid you disable the reference table on both interfaces? Do you know what effect (if any) this has on the logging of snort alerts in mysql?
Thanks!
Greg
