Security > Access control still lets visitors through

[brrr]

LSWS 3.31 Std, on CentOS 4.5.

Not using Apache config - pure LSWS test default setup, with just the one virtual host at $SERVER_ROOT/DEFAULT/

Problem/bug: LSWS doesn't seem to actually block IP addresses specified server-wide in the Denied List from hitting the server.

I've setup LSWS to block access to the server server-wide, via Configuration > Security > Access Control, then added a large number of IP addresses and CIDR ranges into the denied list.

I've done this at server level because I want each LSWS virtual site to inherit this block-list. Each virtual host has nothing specified in Configuration > Virtual Hosts > Virtual Host > Security > Denied List, because as the LSWS help text says:

"You can set up access control at server, virtual host and context levels. If there is access control at server level, the virtual host rules will be applied after the server rules are satisfied."

So what should happen is a visitor from one of the blocked IP addresses should get a '403-Forbidden' error, to be handled in this case by a custom error page. But that doesn't happen.

This is what happens instead:

In this example I have setup an 'Access Denied' entry for the ServerBeach hosting IP address CIDR that contains the bot from http://www.websiteoptimization.com/services/analyze/ that I will be using to test my access blocked list.

The CIDR range that I have entered to be blocked is 72.51.32.0/20, which corresponds to the netrange: 72.51.32.0 - 72.51.47.255.

Instead of a string of 403's, this is what I see instead - the HTTP request from that remote host has gone straight through to the server without being blocked...

72.51.34.164 - - [01/Dec/2007:19:30:29 -0800] "HEAD / HTTP/1.1" 200 - "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)" "123.456.789.0"
72.51.34.164 - - [01/Dec/2007:19:30:29 -0800] "HEAD / HTTP/1.1" 200 - "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)" "123.456.789.0"
72.51.34.164 - - [01/Dec/2007:19:30:29 -0800] "GET / HTTP/1.1" 200 321 "" ""Mozilla/4.0 (compatible; MSIE 6.0; Windows 98; Win 9x 4.90)"" "123.456.789.0"
72.51.34.164 - - [01/Dec/2007:19:30:29 -0800] "HEAD /image2.jpg HTTP/1.1" 200 - "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)" "123.456.789.0"

No errors are reported in any LSWS error log.

Am I doing anything wrong? This should work. (I also suspect that it did work in earlier versions of LSWS, although I haven't dug through my logs to confirm this).

Either way, if access denied doesn't work this way, it's a show-stopper for me with LSWS

My server config.xml is attached. It only lists 2 IP address ranges in the access denied section, but the test server actually has over 1000 entries there.

 

[mistwang]

When you specify multiple addresses in the list, use a comma to seperate two addresses.

It will not give 403 error, the connection will be closed without any reponse. and you will not see anything in access log for IPs being blocked.

 

[brrr]

When you specify multiple addresses in the list, use a comma to seperate two addresses.

Aha. Well, that should be easy to fix then. I'll give it a try. Thanks

Could I suggest that you update the help in the LSWS Admin interface to reflect this pls. Now that I look, I see this detail mentioned in the actual LSWS documentation , but it would be very useful to have this point made in the help box within the actual Access Control section.

It will not give 403 error, the connection will be closed without any reponse. and you will not see anything in access log for IPs being blocked.

Sigh. I wish LWSW would report errors like 403's somewhere, like Apache does into the error.log. It's handy to know the strike rate of your access control entries. Not reporting errors like 403's anywhere is not a good feature IMHO.

Why? Sometimes I want to know who exactly is scanning or attacking me so that (if it is serious) I can then upgrade them to a firewall block or take other measures.

 

[brrr]

NB: Using CSV in the access control entries now = successful blocking. Yay!

Still would like to see the 403's logged somewhere though...

 

[mistwang]

The reason of no 403 logged is that the server just close the connection upon accepting the TCP connection, never read the request, thus no way to produce a valid access log entry.

 

[brrr]

Aha. That's clearly very efficient from a technical/performance point of view, which is LSWS strength.

But the LSWS web manager then loses some valuable information about what is happening (including potential bad stuff) against their server.

For example, I have a lot of active CIDR blocks on my Apache setup and the 403 errors I see in my Apache setup are a very useful way of tracking stuff like badbot activity and individuals doing server vulnerability scans from within blocked IP address ranges.

I use this info to improve things like mod_security rules and/or impose firewall bans across all protocols for IPs that have identified themselves as potentially threatening to other services on other ports - eg when their web attack signature from the 403 log entries identifies them as using certain broad spectrum exploit tools.

Aside from 404 error logs, as it stands now LSWS can't feed any useful info into this management process which is unfortunate.