Hi folks,

We are new to ASL and recently set it up on our server. Everything went smoothly and we can see the login screen on the web gui, however, it seems that we can't connect to our remote mysql server. During the install process we provided the host name (not the actual IP since the details are in our hosts file and can successfully ping the remote server without a problem using the host name) and it can't seem to find it.

It seems like ASL is defaulting to a localhost copy of mysql, which we don't really have one running unless ASL installed it. Under the hood it seems like everything is working but we can't login to the web gui since we can't connect to the database.

Any help is appreciated. Thanks!

OS - RHEL 5

ASL just connects to whatever mysql server you configured it do connect to. If you do not have a mysql server running on localhost then you will need to configure ASL to use that mysql server. Please check your mysql settings for ASL by running these commands as root:

grep DATABASE /etc/asl/config

You will see a result similar to this:

OSSEC_DATABASE_SERVER="127.0.0.1"
OSSEC_DATABASE="tortix"
OSSEC_DATABASE_USERNAME="tortix"
OSSEC_DATABASE_PASSWORD="password"

Check to make sure those are correct. You do not need to change the last three options, provided that you setup the ASL database in mysql during installation.

Hi Mike - thank you very much for your response. We changed the server name to the actual IP and it works like a dream! We noticed that some pages on a few of our web applications are being blocked, giving a Forbidden message, and when we check the audit_log they are being flagged. We will go through the code and check it out but in general, how do we "tune" the system to allow certain pages to be accessed? I'm thinking in terms of administrative pages that require the ability to change files and database information. Obviously we need to let ASL do it's job but I'm worried about the potential of false positives and how/where to solve these issues when they come up.

Thank you so much! So far we're really impressed with this.

Thanks for the question. The simple, quick and free way to do that is to log into the ASL GUI, pull up these events and click the False Positive button. That then opens a priority case with us and sends us all the debug info, whereupon we will tune the rules for you and put a release the same day you send in the FP.

If you wish to tune the rules yourself (and please dont feel you need to do this yourself, its no bother at all for us to tune the rules for you, its all part of the service!), please read the wiki page referenced below:

https://www.atomicorp.com/wiki/index.php/Mod_security

We are seeing modsecurity messages in the audit_log file but not in the web gui. The web gui is showing 0 events and 0 attacks. One of our issues was resolved by allowing fsockopen in php for google's reCaptcha. I'm not sure if enabling that function is the right solution but it was temporarily necessary. We tried to manually update this in the web interface but had to manually do it in the php.ini file. When changing settings like that via the web interface do we need to restart apache? It seemed like it wasn't working.

I will try to get more information on the page that is getting a Forbidden error. The php code looks fine so I am trying to capture the actual data to see if there is something in there that is being flagged.

Thanks again Mike I really appreciate it.

So if recent events (after you fixed mysql) and not showing in the GUI, then there is still something wrong with ASL talking to mysql, or the ASL database is corrupt. Can you please look at your /var/log/ossec/ossec.log file and tell us if you see any errors? Also, do you see any errors about a corrupt database in your mysql logs?



With the first issue above and this one its really starting to sound like you may have a broken or incomplete install. Did you have any errors on install or upgrade? And what process did you use for either?

Can you run the manual upgrade process for me, and send us the output:

https://www.atomicorp.com/wiki/index.ph ... al_Upgrade



modsecurity will record the whole payload. If you follow the process here:

https://www.atomicorp.com/wiki/index.ph ... _.28ASL.29

You can also report the false positive from the command line. Its pretty easy to do and will save you from having to sort it out yourself.

Hi Mike,

We tried the update that you provided and it didn't help. What we found is that the install script only seems to create 18 tables. We had a look at the database schema and found that there are more tables, so, we manually added those tables and everything seems to be working.

What lead us to this conclusion was in the ossec.log file (thank you!). It showed that the system could connect to the database but was failing due to certain tables not existing; specifically tortix.server. I'm not sure why the install didn't populate the database with all of the tables but it may be something to look into. I know we found someone else on this site that had a similar issue.

Thanks again Mike, we are very happy with this product so far.

Thanks for the reply. Do you recall what version of ASL you upgraded from? We'd like to see if we can reproduce this.

This was a brand new install on RHEL 5 using a remote mysql 4 server. The command we used for the installation was: wget -q -O - http://www.atomicorp.com/installers/asl | sh

Let me know if you require more information.

Thank you for the reply. mysql 4? If thats not a typo (if it is let me know), then that may be the cause, we normally test on mysql 5. I wonder if theres some function we use that mysql4 doesnt support. I'll see if we can reproduce this.

Whats the full version number you are using?

Not a typo!

version: 4.1.22 (this is an old development server)

Edit: This is also on RHEL 4 32-bit

No worries.