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.

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:

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.

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?

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:

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.

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.

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?

Quote:

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.

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:

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.

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

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.

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.

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum