Slashdot Mirror

Mod Security is a good example of a web application firewall.

mod_security is pretty handy at spotting crawler patterns (you have to be a really weird human or a well designed crawler to look like something you're not).

Captchas aside, aren't there other ways of preventing bots from registering multiple accounts? Instead of focusing on humans, how about focusing on the behavior of the bots. Do they change their IP address every time? Do they fill forms faster than humanly possible? Does any human register more than one account on your site? Do they enter random text or put in URLs where they shouldn't?

I still do not see any attempts to weed out the bots.

You don't see the attempts because they're not visible. http://www.modsecurity.org/projects/modsecurity/apache/index.html The bad part is that the bots can be made to eventually fit within defined rules.

2 apps that come to mind - providing you are not running on shared hosting They may to overkill - they both have spam rules and can help web apps from hackers. modsecurity - http://www.modsecurity.org/ snort - www.snort.org both are free and GPL - the snort does have a paid for subscription service - however if you just free register you get pretty up to date rules

Well, unfortunately, Apache and Postgres are not magically safe. However, mod_security can definitely help secure Apache, by filtering suspicious requests.

Securing LAMP Mod Security Its so simple a fix with mod_security...

SecFilterSelective REQUEST_URI /admin.php chain
SecFilterSelective REMOTE_ADDR "!^YOUR.IP.ADDRESS$" redirect:http://www.infiltrated.net/sorry.jpg
SecFilterSelective ARG_username YOURUSERNAME chain
SecFilterSelective REMOTE_ADDR "!^YOUR.IP.ADDRESS$" redirect:http://www.infiltrated.net/sorry.jpg

Where your IP address and your username are the only ones to allow anything to the admin page. Anything else gets redirected elsewhere.

Whilst he's a very good security researcher, Stefan Esser has a reputation for being very hard to work with.

He claims that month of PHP bugs was created because he couldn't get the fixes into PHP. Whilst this may be true for PHP, he recently announced a vulnerability in mod_security complete with P.O.C code as part of MOPB. This had nothing to do with PHP, and Esser didn't bother to notify the mod_security team before releasing it.

Whilst he's a very good security researcher, Stefan Esser has a reputation for being very hard to work with.

He claims that month of PHP bugs was created because he couldn't get the fixes into PHP. Whilst this may be true for PHP, he recently announced a vulnerability in mod_security complete with P.O.C code as part of MOPB. This had nothing to do with PHP, and Esser didn't bother to notify the mod_security team before releasing it.

mod_security and Hardened PHP can help with preventing future attacks that people don't yet know about.
Also, using something like GRSec, or SELinux can further restrict what people could do if they did end up with a shell on your webserver. Although whether it's worth the effort to set up for everyone is another question.

I recently installed modsecurity http://www.modsecurity.org/ for apache along with the
rules from http://www.gotroot.com/ and it's done a good job of blocking attacks
on my server including a lot of the php mail() injection attempts.

ozgur uksal

I recently installed modsecurity http://www.modsecurity.org/ for apache along with the rules from http://www.gotroot.com/ and it's done a good job of blocking attacks on my server including a lot of the php mail() injection attempts, whilst it has shown up a few false positives like someone posting a message with sql keywords e.g. "select" "from", it is certainly worth installing even if you have to monitor the logs for a bit afterwards to watch for the false positives and alter the rules accordingly.

Whilst it probably won't solve a lot of the problems with php and security it does help protect the server especially when you don't have control over what your users are uploading to their web space.

From Goaway \\\
The thing is, the vast majority of PHP users don't even understand that there is a problem. PHP is a language used mainly by beginners, and actively aimed at beginners, but it is not designed to be used by beginners. It's a landmine-filled sandbox.
\\\

So, where do you get that PHP is a "landmine-filled sandbox"? Because people don't use it properly (see function list below)? If so, that rather asinine.

From Goaway \\\
Thus, the internet is full of SQL injection vulnerabilities.
\\\

SQL injection errors are created by people that have no clue how to do there jobs. It is NOT language dependent (see list of functions below).

From Goaway \\\
Blaming every PHP programmer for not being a security expert is idiotic. Most programmers aren't, and they wouldn't need to be, if the language was designed properly.
\\\

If you define a security expert as one who pretty much uniquely knows to escape params to a SQL query, then I'd hate to think what your code looks like. In fact, my first piece of paper was from a college where I got a 2 year diploma. And even there they EXPLICITLY taught to do sanity checking at the client AND server level. And the instructor HATED teaching that stuff AND his actual expertise was networking. This is NOT about being a security expert, it is about /common sense/.

This also is an issue that has NOTHING to do with language design. If we were talking about having a standard db interface then THAT would be language design (btw PHP doesn't have one and that is a problem, but that's a completely other issue). What we ARE talking about, is how that design is IMPLEMENTED. These things are completely different.

From Goaway \\\
I don't use PHP, for exactly that reason.
\\\

Well, it's obvious that you don't use PHP because you have no clue what functions are in its library.

From http://ca3.php.net/manual/en/function.dbx-escape-s tring.php

"""
Escape a string so it can safely be used in an sql-statement
"""

and from http://ca3.php.net/manual/en/function.pg-escape-st ring.php

"""
Escape a string for insertion into a text field
"""

and from http://ca3.php.net/manual/sv/function.mysql-real-e scape-string.php

"""
Escapes special characters in a string for use in a SQL statement
"""

etc

So, there are loads of functions that do the required escaping without the "programmer" having to be a "security expert" i.e. it's just having a clue as to what functions are available /and using them/.

Also, point of fact, web programming today REQUIRES knowledge of security features/programes/etc. If you don't know, then you have no business doing it.

Point of fact, security is about creating layers of defenses to ensue that the app is pretty much tamper proof.

This starts with sanity checking at the browser, then a web application firewall (e.g. http://www.modsecurity.org/), specific sanity checks in the application code itself (e.g. restricting usernames to alphanumeric and checking for it), and if one is using a language that has functions like the above, use them (if they implemented internally, great), if not, do it yourself.

Of course sanity checking at the client level and using a web application firewall are optional but the others are required, period. If you don't do this you're asking for trouble. Furthermore, if you depend on others to do this checking for you, you are as well asking for trouble.

There will always be vulnerabilities in any language, web server, db server, etc. What makes any vulnerabilities not exploitable (or extremely difficult to exp

Use Bad-Behaviour and mod-security.

These two work perfect for me.

How many "web" templating systems do you know that automatically escape HTML unless told otherwise? I know of one that can be made to do so: Mason. Even then, you have to enable it, as it's not turned on by default.

What about PHP, ASP, JSP and so on? Will they ever grow up and automatically escape HTML by default? I doubt it very much.

In the meantime, there's always mod_security if you're willing to invest the time configuring it. But it's no guarantee...

-Dom

You could use your in house search engine (or a google appliance if your lucky) to find any existing content or I supose your current system of crawling, parsing and regexes would suffice.

Then I would recoment the mod_security module for apache http://www.modsecurity.org/ It will scan any POST requests for banned pattern. You could leverage the regexes you already wrote to scan the content in the first place.

I think mod_secrity does what the FS and McAfee appliances do at much better (free as in beer) price.

There's also a proof-of-concept called PWNtcha (http://sam.zoy.org/pwntcha/ which can automatically work out a large number of common CAPTCHAs (including PHPbb and vBulletin's standard ones ) with well over 90% correct.

CAPTCHAs are NOT the best solution - they're just a band-aid, and they make your site harder to use ( especially for low vision people ). Personally I prefer web-server level blocking of dodgy UA's, IP ranges, POST payloads with something like the wonderful mod_security for Apache, coupled with word filtering ( Spamassassin or just a black list ).

Easy way of fixing the problem:
Install mod_security for Apache. Install the current development version (2.0.0-dev1) and use DNSBl with mod_security to block most of those spam-bots. Go to got root? and download their rule set and include it into your mod_security configuration.

That's it! This gives you a good tool set to fight the spam bots. I was able with the above mentioned setup to block ALL spam bots and all the anoying linkdumper bots, without any problems.

If you're going to use PHP, please do yourself a huge favour and install mod_security.

Snarf mod_security from here and snarf the awesome rulesets available from gotroot.com

It's a DEAD EASY installation and is quite educational. You'll notice in the logs it generates that people/scripts are scanning your sites all freaking day for phpmyadmin, phpbb2 vulnerabilities etc. Awesome software.

mod_security should come OOTB with all Linux distros that use Apache, configured with a decent set of rules such as those from gotroot.com.

I sincerely wish the developers of PHP put more of a focus on security. It's a hard job: people are writing insecure PHP applications (heck, they're doing it in other languages as well such as Perl). I don't have a really intelligent suggestion here because I don't do a lot of PHP (I'm a systems guy rather than a developer) but it would be great if it wasn't so easy for PHP programmers to inadvertantly open up massive holes. It's probably not all laziness that causes most PHP applications to be insecure: sometimes programmers simply make mistakes. Anything the language can do (within reason) to help avoid these mistakes is a Good Thing. In the meantime, mod_security baby!

Cheers
Stor

Yes cgi access gives them a virtual shell, you can control how it functions.
You should be using mod_security.
http://understudy.net/tutorials.php?name=wget comes back failed You can run limited ablity shell accounts such as scponlyc (chrooted version of scponly)

And the servers I run on are all FreeBSD based.

Mod security can be found here:
http://modsecurity.org/
http://www.gotroot.com/tiki-index.php?page=mod_sec urity+rules
http://www.onlamp.com/pub/a/apache/2003/11/26/mod_ security.html

I looked into mod_security for apache and it lets you return 500 errors for regex URL patterns, or content. I'm sure it would let you ignore those URLs too.

Surprising that no ones mentioned it: http://www.modsecurity.org/ - available as either an Apache module (C) or as a servlet filter (Java).

Basically it's aware of HTTP "variables" being submitted via a browser in GET / POST or in cookies and is able to screen them using regular expressions and "access list like" rules, before they get to any application code for processing. That means you can add it to a server transparently, without needing to change existing code.

Like Apache config files, the rules can be similar to "permit xyz" or "deny abc". In other words you could block certain input globally, such as attempted XSS attacks while having a set of rules that are like a "signature" of permissable input for a given application i.e. "here's all the permissable input for PHP-Nuke. Block all the rest".

Certainly, for shared LAMP hosts, modsecurity could help lots to keep the rampaging PHP apps under control. Apparently the commercial offerings in the same field (web intrusion detection and prevention) are more mature right now, in particular where friendly admin GUIs are concerned, but typically come with hefty price tags.

I installed mod_security on my server a few weeks ago with a few simple regexes to cover the more prolific referrer spammers recorded by awstats. Set the mod_security default action to deny,status:412. Then in httpd.conf I set the ErrorDocument for the 412 code to an empty file.

Now when the referer spammer hits my site, they get denied and get nothing back. Bandwidth wasted serving up pages to referer spammers is cut to virtually nil. The spammers are still there banging away and a few still get by though. The list of referrers needs to be monitored so that new mod_security rules can be added as required. That's no different than using mod_rewrite to deny the referrer spammers though.

If you're doing shared hosting and you allow your users to run CGIs-- regardless of what CGI it is-- you should have reasonable limits in place that keep child processes in check. Apache has had such directives for doing this for some time, one of them being RLimitNPROC. This directive allows you to limit the number of subprocesses that Apache will run concurrently.

You can even specify subprocess limits on a per-virtual host basis. With Apache 2, you can even limit based on directory. Using RLimitMEM is also a good idea.

Yes, MT's comment system can use some improvement. We're working on that. But these servers are getting hammered; in effect a denial-of-service style attack.

Even a "Hello, world" type script can be hit hard enough to bring down a server, assuming there are no process limits in place. Invoking a modern interpreter to execute a CGI script is no small feat. Perl, Python, Ruby, and even PHP (when run as a CGI as many shared hosting companies do for security reasons) consume enormous amounts of resources at startup regardless of the size or complexity of the script they are summoned to execute.

So, sure, code can be added to MT to recognize and adapt to a flood of comments coming in, but by the time the CGI runs, it's already chewing up CPU and memory. In my opinion, a better defense for these flood-style attacks is for Apache itself (or third-party in-memory Apache modules) to handle such situations.

mod_security, mod_dosevasive and others are excellent defensive tools for any public Apache server admin to use.

I'd love to know what others have done to configure Apache to prevent denial-of-service attacks.

I read about this yesterday and couldn't find out if mod_security and suPHP are vulnerable to these attacks. With mod_security blocking buffer overflows, "bad" characters, etc. and mod_suphp forcing PHP to run as the user, I don't think that it gives people who run these modules (that) much to worry about.

If you're using mod_security on your Apache server then you only need to add one line to the configuration file:

SecServerSignature "MyServer/19.5.1"

Tegatai Systems has been using mod_security in its development labs recently. It has been determined through white and blackbox testing that mod_security needs more work before it will be stable enough for wide-spread production use.

I had to browse the site to see what this does, this overview page was good.

It reminds me of URLScan for MS's IIS - but with extra features.

If you are interested in detecting and preventing web attacks specifically then you should have a look at mod_security. It is an Apache module (both branches are supported) that allows for some very interesting HTTP-specific filtering. It even supports POST method analysis, and can reject an offending request. Since it works as part of the web server it makes it much easier to detect attackes carried out through an SSL channel.

Or, you could add the mod_security module to your Apache server to take care of those common errors for you.