Hi All,
I want to know thoughts on if I am being to paranoid/security conscious.
CentOS 5.6, Apache, MySQL, running an Firewall in front of everything and obviously the built-in firewall on the box. I have ssh on a different port and starting to use Keys instead of password authentication. I host an intensive website and I am getting about 150 unique visitors per day.
What I am seeing is LogWatch reporting a lot of 404's like:
404 Not Found //PHPMA/: 1 Time(s) //admin/myadmin/: 1 Time(s) //admin/phpmyadmin/: 1 Time(s) //adming/: 1 Time(s) //ascils/phpmyadmin/: 1 Time(s) //blog/wp-content/plugins/phpmyadmin/: 1 Time(s) //database/: 2 Time(s) //db/: 1 Time(s) //dba/: 1 Time(s) //dbadmin/: 2 Time(s) //html/phpMyAdmin/: 1 Time(s) //html/phpmyadmin/: 1 Time(s) //lamp/phpmyadmin/: 1 Time(s) //myadmin/: 1 Time(s) //mydatabase/: 1 Time(s) //mydb/: 1 Time(s) //myphp/: 1 Time(s) //mysql-admin/: 1 Time(s) //mysql/: 1 Time(s) //mysqladmin/: 2 Time(s) //mysqlmanager/: 1 Time(s) //phpMyAdmin-2.8.0.2/: 1 Time(s) //phpMyAdmin-2.8.1-rc1/: 1 Time(s) //phpMyAdmin-2.8.1/: 1 Time(s) //phpMyAdmin-2.8.2/: 1 Time(s) //phpMyAdmin/: 1 Time(s) //phpadm/: 2 Time(s) //phpma/: 1 Time(s) //phpmanager/: 1 Time(s) //phpmy/: 2 Time(s) //phpmyadmin/: 1 Time(s) //pma/: 1 Time(s) //pmaadmin/: 1 Time(s) //pmadmin/: 1 Time(s) //sql/: 1 Time(s) //sqladmin/: 2 Time(s) //sqldatabase/: 2 Time(s) //sqlmanager/: 1 Time(s) //sqlweb/: 1 Time(s) //typo3/phpmyadmin/: 1 Time(s) //webadmin/: 1 Time(s) //webdb/: 1 Time(s) //websql/: 1 Time(s) //wp-content/plugins/phpMyAdmin/: 1 Time(s) //wp-content/plugins/wp-phpmyadmin/: 1 Time(s) //xampp/phpmyadmin/: 1 Time(s)
So I turned on Apache ReWrite and I created a file and I put in rules like: (just a small subset)
RewriteCond %{REQUEST_URI} ^/php(.*) [NC,OR] RewriteCond %{REQUEST_URI} ^/phpmy(.*) [NC,OR] RewriteCond %{REQUEST_URI} ^/phpma [NC,OR] RewriteCond %{REQUEST_URI} ^/phpmyadmin [NC,OR] RewriteCond %{REQUEST_URI} ^/phpadmin [NC,OR] RewriteCond %{REQUEST_URI} ^/phpgadmin [NC,OR] RewriteCond %{REQUEST_URI} ^/phppgadmin [NC,OR] RewriteCond %{REQUEST_URI} ^/phpmyadmin(.*) [NC,OR] RewriteCond %{REQUEST_URI} ^/php-my-admin [NC,OR] RewriteCond %{REQUEST_URI} ^/php-myadmin [NC,OR] RewriteCond %{REQUEST_URI} ^/phpmy-admin [NC,OR] RewriteCond %{REQUEST_URI} ^/phpmanager [NC,OR] RewriteCond %{REQUEST_URI} ^/player(.*) [NC,OR] RewriteCond %{REQUEST_URI} ^/plugins [NC,OR] RewriteCond %{REQUEST_URI} ^/pma [NC,OR] RewriteCond %{REQUEST_URI} ^/p/m/a [NC,OR] RewriteCond %{REQUEST_URI} ^/pmadmin [NC,OR] RewriteCond %{REQUEST_URI} ^/pmaadmin [NC,OR] RewriteCond %{REQUEST_URI} ^/scripts [NC,OR] RewriteCond %{REQUEST_URI} ^/sd(.*) [NC,OR] RewriteCond %{REQUEST_URI} ^/sql [NC,OR] RewriteCond %{REQUEST_URI} ^/sqladmin [NC,OR]
and if one of these is hit I use a Rule of:
RewriteRule .* http://%%7BREMOTE_ADDR%7D%%7BREQUEST_URI%7D [L,R=301,QSA]
Everyday I look at the LogWatch E-Mail and I add one people are trying to hit and restart apache.
This yields a few questions.
1. Am I being to paranoid by doing this? My logic is they dont belong here and I could get mad if someone walked up to my apartment and tried jiggling the door handle to see if it was unlocked.
2. I know I can simplify these rules. Wouldn't RewriteCond %{REQUEST_URI} ^/php(.*) [NC,OR] get most of the attempts for thinks like /php, /php-myadmin, /phpmyadmin-2.0.8.8, etc?
3. Is there a better way to right these rules?
4. Why does LogWatch show this to me as a 404 , when a rewrite rule is hit and they are re-directed back to themselves? My rules seem to be working, if I try and hit /scripts right now, it does what I expect.
Can anyone shed some light for me on my thoughts/questions?
2011/5/8 Jason slackmoehrle.lists@gmail.com:
Hi All,
I want to know thoughts on if I am being to paranoid/security conscious.
CentOS 5.6, Apache, MySQL, running an Firewall in front of everything and obviously the built-in firewall on the box. I have ssh on a different port and starting to use Keys instead of password authentication. I host an intensive website and I am getting about 150 unique visitors per day.
What I am seeing is LogWatch reporting a lot of 404's like:
404 Not Found //PHPMA/: 1 Time(s) //admin/myadmin/: 1 Time(s) //admin/phpmyadmin/: 1 Time(s) //adming/: 1 Time(s) //ascils/phpmyadmin/: 1 Time(s) //blog/wp-content/plugins/phpmyadmin/: 1 Time(s) //database/: 2 Time(s) //db/: 1 Time(s) //dba/: 1 Time(s) //dbadmin/: 2 Time(s) //html/phpMyAdmin/: 1 Time(s) //html/phpmyadmin/: 1 Time(s) //lamp/phpmyadmin/: 1 Time(s) //myadmin/: 1 Time(s) //mydatabase/: 1 Time(s) //mydb/: 1 Time(s) //myphp/: 1 Time(s) //mysql-admin/: 1 Time(s) //mysql/: 1 Time(s) //mysqladmin/: 2 Time(s) //mysqlmanager/: 1 Time(s) //phpMyAdmin-2.8.0.2/: 1 Time(s) //phpMyAdmin-2.8.1-rc1/: 1 Time(s) //phpMyAdmin-2.8.1/: 1 Time(s) //phpMyAdmin-2.8.2/: 1 Time(s) //phpMyAdmin/: 1 Time(s) //phpadm/: 2 Time(s) //phpma/: 1 Time(s) //phpmanager/: 1 Time(s) //phpmy/: 2 Time(s) //phpmyadmin/: 1 Time(s) //pma/: 1 Time(s) //pmaadmin/: 1 Time(s) //pmadmin/: 1 Time(s) //sql/: 1 Time(s) //sqladmin/: 2 Time(s) //sqldatabase/: 2 Time(s) //sqlmanager/: 1 Time(s) //sqlweb/: 1 Time(s) //typo3/phpmyadmin/: 1 Time(s) //webadmin/: 1 Time(s) //webdb/: 1 Time(s) //websql/: 1 Time(s) //wp-content/plugins/phpMyAdmin/: 1 Time(s) //wp-content/plugins/wp-phpmyadmin/: 1 Time(s) //xampp/phpmyadmin/: 1 Time(s)
So I turned on Apache ReWrite and I created a file and I put in rules like: (just a small subset)
RewriteCond %{REQUEST_URI} ^/php(.*) [NC,OR] RewriteCond %{REQUEST_URI} ^/phpmy(.*) [NC,OR] RewriteCond %{REQUEST_URI} ^/phpma [NC,OR] RewriteCond %{REQUEST_URI} ^/phpmyadmin [NC,OR] RewriteCond %{REQUEST_URI} ^/phpadmin [NC,OR] RewriteCond %{REQUEST_URI} ^/phpgadmin [NC,OR] RewriteCond %{REQUEST_URI} ^/phppgadmin [NC,OR] RewriteCond %{REQUEST_URI} ^/phpmyadmin(.*) [NC,OR] RewriteCond %{REQUEST_URI} ^/php-my-admin [NC,OR] RewriteCond %{REQUEST_URI} ^/php-myadmin [NC,OR] RewriteCond %{REQUEST_URI} ^/phpmy-admin [NC,OR] RewriteCond %{REQUEST_URI} ^/phpmanager [NC,OR] RewriteCond %{REQUEST_URI} ^/player(.*) [NC,OR] RewriteCond %{REQUEST_URI} ^/plugins [NC,OR] RewriteCond %{REQUEST_URI} ^/pma [NC,OR] RewriteCond %{REQUEST_URI} ^/p/m/a [NC,OR] RewriteCond %{REQUEST_URI} ^/pmadmin [NC,OR] RewriteCond %{REQUEST_URI} ^/pmaadmin [NC,OR] RewriteCond %{REQUEST_URI} ^/scripts [NC,OR] RewriteCond %{REQUEST_URI} ^/sd(.*) [NC,OR] RewriteCond %{REQUEST_URI} ^/sql [NC,OR] RewriteCond %{REQUEST_URI} ^/sqladmin [NC,OR]
and if one of these is hit I use a Rule of:
RewriteRule .* http://%%7BREMOTE_ADDR%7D%%7BREQUEST_URI%7D [L,R=301,QSA]
Everyday I look at the LogWatch E-Mail and I add one people are trying to hit and restart apache.
This yields a few questions.
Am I being to paranoid by doing this? My logic is they dont belong here and I could get mad if someone walked up to my apartment and tried jiggling the door handle to see if it was unlocked.
I know I can simplify these rules. Wouldn't RewriteCond %{REQUEST_URI} ^/php(.*) [NC,OR] get most of the attempts for thinks like /php, /php-myadmin, /phpmyadmin-2.0.8.8, etc?
Is there a better way to right these rules?
Why does LogWatch show this to me as a 404 , when a rewrite rule is hit and they are re-directed back to themselves? My rules seem to be working, if I try and hit /scripts right now, it does what I expect.
Can anyone shed some light for me on my thoughts/questions?
You should take a look at mod_security: http://www.modsecurity.org/ , if provides better ways to block hostile attacks and probes.
-- Eero
On Sun, May 08, 2011 at 08:57:23PM +0300, Eero Volotinen wrote:
You should take a look at mod_security: http://www.modsecurity.org/ , if provides better ways to block hostile attacks and probes.
Really? 99 lines of untrimmed material for a 2 line reply?
John
On 5/8/2011 4:53 PM, John R. Dennison wrote:
On Sun, May 08, 2011 at 08:57:23PM +0300, Eero Volotinen wrote:
You should take a look at mod_security: http://www.modsecurity.org/ , if provides better ways to block hostile attacks and probes.
Really? 99 lines of untrimmed material for a 2 line reply?
I don't have personal experience with this, but I have heard that modsecurity does not play nice with some websites. If you are in a virtual hosting situation, it might be a bit too early to jump on that ship? I'll hopefully wait for it to become more of a 'standard'.
I run Ossec on several servers and Fail2Ban on several others. At the moment, I prefer Fail2Ban. Configuration is not straight forward on either, but personally, I seem to get along better creating/editing Fail2Ban rules. It's sort of hard to do comparisons as each server has differing accesses, but my gut tells my that Fail2Ban is a little easier on server loads. Both do a lot of reads, constantly monitoring for intrusion attempts.
I know Fail2Ban is not a CentOS standard package, but it would be nice if we could build a place on the CentOS website where rules could be shared. Each environment is a bit different and so the rules need to be adapted. I have found the need for edits even between CentOS 3, 4 and 5 boxes.
On 08/05/11 23:31, John Hinton wrote:
I know Fail2Ban is not a CentOS standard package, but it would be nice if we could build a place on the CentOS website where rules could be shared. Each environment is a bit different and so the rules need to be adapted. I have found the need for edits even between CentOS 3, 4 and 5 boxes.
That would be the CentOS Wiki.
Feel free to jump on over to the centos-docs list and create a page describing how to install, configure and write custom rules. You can also document the differences between CentOS 3, 4 and 5. Sounds like an ideal topic for a HowTo guide.
Being a Wiki, others can then easily add and share their rules too.
Then every time someone asks about Fail2Ban we can refer them to your documentation :-)
quick answer: even paranoids have enemies
On Sun, 8 May 2011, Jason wrote:
So I turned on Apache ReWrite and I created a file and I put in rules like: (just a small subset)
RewriteCond %{REQUEST_URI} ^/php(.*) [NC,OR] RewriteCond %{REQUEST_URI} ^/phpmy(.*) [NC,OR]
.snip
I know I can simplify these rules. Wouldn't RewriteCond %{REQUEST_URI} ^/php(.*) [NC,OR] get most of the attempts for thinks like /php, /php-myadmin, /phpmyadmin-2.0.8.8, etc?
Is there a better way to right these rules?
I wrote about my approch some time ago ...
http://orcorc.blogspot.com/2010/06/reading-logs-part-3-run-your-updates.html
Send them safely off your box, and back home
-- Russ herrold
Hi Russ,
- Is there a better way to right these rules?
I wrote about my approch some time ago ...
http://orcorc.blogspot.com/2010/06/reading-logs-part-3-run-your-updates.html
Send them safely off your box, and back home
I read your article and It seems we are doing the same thing? Is there a benefit I dont understand to use your approach versus the one I am using already?
Is it true that you can to (.*) to handle easier matching?
Say phpmyadmin, phpadmin, php-myadmin
Could I do something like: RewriteCond %{REQUEST_URI} ^/php(.*) [NC,OR] and that would handle all of them?
-Jason
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Jason Sent: Sunday, May 08, 2011 15:02 To: CentOS mailing list Subject: Re: [CentOS] Am I being to paranoid?
Hi Russ,
- Is there a better way to right these rules?
I wrote about my approch some time ago ...
http://orcorc.blogspot.com/2010/06/reading-logs-part-3-run-your-update
s.html
Send them safely off your box, and back home
I read your article and It seems we are doing the same thing? Is there a benefit I dont understand to use your approach versus the one I am using already?
The point you missed was that he packaged the conf gile as a RPM and then added it to his local yum repo, so all his machines would get it durring the update cycle.
Is it true that you can to (.*) to handle easier matching?
Say phpmyadmin, phpadmin, php-myadmin
Could I do something like: RewriteCond %{REQUEST_URI} ^/php(.*) [NC,OR] and that would handle all of them?
-Jason _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100 - - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00.
My 2 cents : OSSEC is quite good at actively blocking attackers in situations like this.
2011/5/8 Jason Pyeron jpyeron@pdinc.us
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Jason Sent: Sunday, May 08, 2011 15:02 To: CentOS mailing list Subject: Re: [CentOS] Am I being to paranoid?
Hi Russ,
- Is there a better way to right these rules?
I wrote about my approch some time ago ...
http://orcorc.blogspot.com/2010/06/reading-logs-part-3-run-your-update
s.html
Send them safely off your box, and back home
I read your article and It seems we are doing the same thing? Is there a benefit I dont understand to use your approach versus the one I am using already?
The point you missed was that he packaged the conf gile as a RPM and then added it to his local yum repo, so all his machines would get it durring the update cycle.
Is it true that you can to (.*) to handle easier matching?
Say phpmyadmin, phpadmin, php-myadmin
Could I do something like: RewriteCond %{REQUEST_URI} ^/php(.*) [NC,OR] and that would handle all of them?
-Jason _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
--
-- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100 -
- +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 05/08/2011 10:46 AM, Jason wrote:
- Why does LogWatch show this to me as a 404 , when a rewrite rule is hit and they are re-directed back to themselves? My rules seem to be working, if I try and hit /scripts right now, it does what I expect.
[...]
Because the remote loader is a robot, not a web browser. It is throwing stuff at the wall and seeing what sticks. It flat out doesn't care if you send back a redirect - it is just looking for a response that indicates a vulnerability and anything else is ignored by it.
Redirects are largely ineffective in combating bots hunting for exploitable scripts and programs. You would be better off using something like Fail2Ban to dynamically update firewall rules against detected attackers.
At Sun, 8 May 2011 10:46:17 -0700 CentOS mailing list centos@centos.org wrote:
Hi All,
I want to know thoughts on if I am being to paranoid/security conscious.
CentOS 5.6, Apache, MySQL, running an Firewall in front of everything and obviously the built-in firewall on the box. I have ssh on a different port and starting to use Keys instead of password authentication. I host an intensive website and I am getting about 150 unique visitors per day.
What I am seeing is LogWatch reporting a lot of 404's like:
404 Not Found //PHPMA/: 1 Time(s) //admin/myadmin/: 1 Time(s) //admin/phpmyadmin/: 1 Time(s) //adming/: 1 Time(s) //ascils/phpmyadmin/: 1 Time(s) //blog/wp-content/plugins/phpmyadmin/: 1 Time(s) //database/: 2 Time(s) //db/: 1 Time(s) //dba/: 1 Time(s) //dbadmin/: 2 Time(s) //html/phpMyAdmin/: 1 Time(s) //html/phpmyadmin/: 1 Time(s) //lamp/phpmyadmin/: 1 Time(s) //myadmin/: 1 Time(s) //mydatabase/: 1 Time(s) //mydb/: 1 Time(s) //myphp/: 1 Time(s) //mysql-admin/: 1 Time(s) //mysql/: 1 Time(s) //mysqladmin/: 2 Time(s) //mysqlmanager/: 1 Time(s) //phpMyAdmin-2.8.0.2/: 1 Time(s) //phpMyAdmin-2.8.1-rc1/: 1 Time(s) //phpMyAdmin-2.8.1/: 1 Time(s) //phpMyAdmin-2.8.2/: 1 Time(s) //phpMyAdmin/: 1 Time(s) //phpadm/: 2 Time(s) //phpma/: 1 Time(s) //phpmanager/: 1 Time(s) //phpmy/: 2 Time(s) //phpmyadmin/: 1 Time(s) //pma/: 1 Time(s) //pmaadmin/: 1 Time(s) //pmadmin/: 1 Time(s) //sql/: 1 Time(s) //sqladmin/: 2 Time(s) //sqldatabase/: 2 Time(s) //sqlmanager/: 1 Time(s) //sqlweb/: 1 Time(s) //typo3/phpmyadmin/: 1 Time(s) //webadmin/: 1 Time(s) //webdb/: 1 Time(s) //websql/: 1 Time(s) //wp-content/plugins/phpMyAdmin/: 1 Time(s) //wp-content/plugins/wp-phpmyadmin/: 1 Time(s) //xampp/phpmyadmin/: 1 Time(s)
So I turned on Apache ReWrite and I created a file and I put in rules like: (just a small subset)
RewriteCond %{REQUEST_URI} ^/php(.*) [NC,OR] RewriteCond %{REQUEST_URI} ^/phpmy(.*) [NC,OR] RewriteCond %{REQUEST_URI} ^/phpma [NC,OR] RewriteCond %{REQUEST_URI} ^/phpmyadmin [NC,OR] RewriteCond %{REQUEST_URI} ^/phpadmin [NC,OR] RewriteCond %{REQUEST_URI} ^/phpgadmin [NC,OR] RewriteCond %{REQUEST_URI} ^/phppgadmin [NC,OR] RewriteCond %{REQUEST_URI} ^/phpmyadmin(.*) [NC,OR] RewriteCond %{REQUEST_URI} ^/php-my-admin [NC,OR] RewriteCond %{REQUEST_URI} ^/php-myadmin [NC,OR] RewriteCond %{REQUEST_URI} ^/phpmy-admin [NC,OR] RewriteCond %{REQUEST_URI} ^/phpmanager [NC,OR] RewriteCond %{REQUEST_URI} ^/player(.*) [NC,OR] RewriteCond %{REQUEST_URI} ^/plugins [NC,OR] RewriteCond %{REQUEST_URI} ^/pma [NC,OR] RewriteCond %{REQUEST_URI} ^/p/m/a [NC,OR] RewriteCond %{REQUEST_URI} ^/pmadmin [NC,OR] RewriteCond %{REQUEST_URI} ^/pmaadmin [NC,OR] RewriteCond %{REQUEST_URI} ^/scripts [NC,OR] RewriteCond %{REQUEST_URI} ^/sd(.*) [NC,OR] RewriteCond %{REQUEST_URI} ^/sql [NC,OR] RewriteCond %{REQUEST_URI} ^/sqladmin [NC,OR]
and if one of these is hit I use a Rule of:
RewriteRule .* http://%%7BREMOTE_ADDR%7D%%7BREQUEST_URI%7D [L,R=301,QSA]
Everyday I look at the LogWatch E-Mail and I add one people are trying to hit and restart apache.
This yields a few questions.
- Am I being to paranoid by doing this? My logic is they dont belong here and I could get mad if someone walked up to my apartment and tried jiggling the door handle to see if it was unlocked.
Well, yes. There is a simplier way -- Apache does have an 'error page' handler, where you can customize your 404 page or how Apache responds to a 'page not found' error. Doing the redirect is not really going to solve anything anyway. Most (all?) of these accesses are from a program -- a kind of 'bad' robot, which is probably going to ignore the 301 status and come to the conclusion that these URIs are actually working and report success to its (human) master. That will open you up for more (automated) attacks and/or piss off the human hacker, who will just come up with more and nastier attacks or maybe just launch a dos attack for spite. You are better off just letting Apache handle these as 404. Imagine you have a storefront and people come by after hours and see the lights off and the closed sign -- people will go away and come back later. Imagine that the lights are on and there is no closed sign, and instead you have some poor clerk there answering the door telling people to go away. That is likely to cause more trouble, since people will just come back in 5-10 minutes and ask if the store is open now. Or worse, wait around until there is some indication that the store is open.
I know I can simplify these rules. Wouldn't RewriteCond %{REQUEST_URI} ^/php(.*) [NC,OR] get most of the attempts for thinks like /php, /php-myadmin, /phpmyadmin-2.0.8.8, etc?
Is there a better way to right these rules?
Why does LogWatch show this to me as a 404 , when a rewrite rule is hit and they are re-directed back to themselves? My rules seem to be working, if I try and hit /scripts right now, it does what I expect.
Question: are you using virtual hosts? If so, they the 'visitors' are either NOT sending HTTP 1.1 headers or not using the virtual host name.
Can anyone shed some light for me on my thoughts/questions?
Robert,
- Am I being to paranoid by doing this? My logic is they dont belong here and I could get mad if someone walked up to my apartment and tried jiggling the door handle to see if it was unlocked.
Well, yes. There is a simplier way -- Apache does have an 'error page' handler, where you can customize your 404 page or how Apache responds to a 'page not found' error. Doing the redirect is not really going to solve anything anyway. Most (all?) of these accesses are from a program -- a kind of 'bad' robot, which is probably going to ignore the 301 status and come to the conclusion that these URIs are actually working and report success to its (human) master. That will open you up for more (automated) attacks and/or piss off the human hacker, who will just come up with more and nastier attacks or maybe just launch a dos attack for spite. You are better off just letting Apache handle these as 404. Imagine you have a storefront and people come by after hours and see the lights off and the closed sign -- people will go away and come back later. Imagine that the lights are on and there is no closed sign, and instead you have some poor clerk there answering the door telling people to go away. That is likely to cause more trouble, since people will just come back in 5-10 minutes and ask if the store is open now. Or worse, wait around until there is some indication that the store is open.
This is a good analogy. It does open up more to stating: "Damn'd if you do, damn'd if you dont".
- Why does LogWatch show this to me as a 404 , when a rewrite rule is hit and they are re-directed back to themselves? My rules seem to be working, if I try and hit /scripts right now, it does what I expect.
Question: are you using virtual hosts? If so, they the 'visitors' are either NOT sending HTTP 1.1 headers or not using the virtual host name.
Yes, I am and I have a few domains on this box. Each <virtual> has an include to a file that stores my rewrite rules so I just maintain them in a single place.
-Jason
On 5/9/2011 11:09 AM, Scott Silva wrote:
on 5/8/2011 10:46 AM Jason spake the following:
Hi All,
I want to know thoughts on if I am being to paranoid/security conscious.
<snip> You know what they say; "Just because you are paranoid does not mean that some one is NOT out to get you!"
I think the currently fashionable way to probe for vulnerabilities is to send URLs that will execute something that will contact a central server if they succeed, so it doesn't really matter what you do in the way of blocking/redirecting, etc. They are probably going to ignore the return status and are already running on distributed compromised hosts. At least that's the sort of thing I see regularly trying to exploit a struts vulnerability in our java web server's logs.
Weblabyrinth is another offensive countermeasure that no one had mentioned yet. It's still pretty new but worth keeping an eye on.
It basically creates a bunch of bogus pages that traps scripts that are trying to crawl your website. It also logs anything that gets trapped so you can tie this to your monitoring and alerting solution. You can set it up to trigger a temporary firewall rule banning traffic on any IPs that fall into the trap. Or just let them churn down the rabbit hole.
You already have a good list of rewrite rules so just point those to your labyrinth. Another way to entice bad traffic to the labyrinth is to put bogus entries in your robots.txt that look like that point some where interesting and rewrite them to your labyrinth.
http://www.mayhemiclabs.com/content/new-tool-weblabyrinth http://code.google.com/p/weblabyrinth/ -- David
Weblabyrinth is another offensive countermeasure that no one had mentioned yet. It's still pretty new but worth keeping an eye on.
It basically creates a bunch of bogus pages that traps scripts that are trying to crawl your website. It also logs anything that gets trapped so you can tie this to your monitoring and alerting solution. You can set it up to trigger a temporary firewall rule banning traffic on any IPs that fall into the trap. Or just let them churn down the rabbit hole.
You already have a good list of rewrite rules so just point those to your labyrinth. Another way to entice bad traffic to the labyrinth is to put bogus entries in your robots.txt that look like that point some where interesting and rewrite them to your labyrinth.
http://www.mayhemiclabs.com/content/new-tool-weblabyrinth http://code.google.com/p/weblabyrinth/
Thanks David, this looks very interesting.
-Jason
-
Benjamin Franz -
David Miller -
Eero Volotinen -
Eric Viseur -
Jason -
Jason Pyeron -
John Hinton -
John R. Dennison -
Les Mikesell -
Ned Slider -
R P Herrold -
Robert Heller -
Scott Silva