Domain: modsecurity.org
Stories and comments across the archive that link to modsecurity.org.
Comments · 32
-
Re:Poor security standards
Mod Security is a good example of a web application firewall.
-
Re:"We (/.) ban scrapers..." LOL
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).
-
Re:No workarounds? Really?
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.
-
these might be overkill ...
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
-
Re:Please be more forthcomingHere too, we have a threat which is already running wild. Thousands of websites are being attacked. Unfortunately, this article, like many which abound in the security theatre online media, is long on consequences and short on details. Someone knows how the attack spreads, but they aren't sharing the means of stopping the attack. We know exactly how it spreads: php. Don't get me wrong, php is a good language as of 5.x. However, to write something in it that's not simple to exploit you actually have to know what you're doing, which is not the case the for majority of php developers. Look at the majority of php code out there, it's no surprise at all why it's so security plagued: the developers simply have no clue and php doesn't protect you. Hell, even many tutorials out there have security exploits in them.
If you absolutely have to run a third party php script, do not under any circumstance run it without both the Suhosin patch and the Suhosin module. Running ModSecurity on top of that is also a good idea.
Always treat third party php code as hostile. -
Re:Phew! Nothing to see here!
Well, unfortunately, Apache and Postgres are not magically safe. However, mod_security can definitely help secure Apache, by filtering suspicious requests.
-
Re:Confirmedphpbb, Drupal and PHPNuke attempts mostly. Plus old sshd vulnerabilities, though we're up to date there and nothing got through. Have you played around with Suhosin and ModSecurity? Those are a requirement along with virtual machine snapshots if you use common PHP apps. RSBAC is also a great help.
Using phpBB, Drupal, PHPNuke, etc guarantees a successful server compromise. It's very sad, really. PHP alone is making IIS/.NET look like a great alternative to "LAMP".
Suhosin and ModSecurity can help, though. With those you can prevent scripted attacks, along with making it so that even good crackers have to put in too much effort to make it worthwhile. -
Securing LAMP
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. -
Re:Why is it "funny" to exploit security bugs?
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. -
Re:Why is it "funny" to exploit security bugs?
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. -
Re:Defective by Design?
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. -
modsecurity
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 -
Install modsecurity
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. -
Re:the winners are ...The whole thing is basically a clusterfuck and every time a client asks for it, the hairs stand up on the back of my neck. Unfortunately, I have NO IDEA what else is out there to replace it with, so I just stick it in a freebsd jail and hope for the best. I have scattered the code with all kinds of tricks and traps to detect hacking attempts which has helped to a certain extent. What I do for php apps that I must run is to stick them in a stripped down and heavily locked down custom built VM (Xen). I keep any filesystem read only that's possible (enforced through Xen). I use mod_security and Suhosin (new hardened php). I also disable every php feature I can possibly get away with and turn on safe mode. If it uses a database (most do, and rather poorly (foreign keys exist for a fscking reason!)), I make automated backups every thirty minutes. SQL injection exploits are inevitable in PHP apps.
Since I mostly do virtual hosts, I keep a parent NetBSD (in Xen) apache server (severely locked down) in running mod_proxy and have that send traffic to the diffent vms.
PHP really needs a redesign. It's a nice language (good OO in 5, awesome templating with Smarty*, etc). It really should be written in a way so that the n00bs can't easily write horribly insecure code.
* Does anyone know of an equivalent library in Java? Smarty is the reason I still do heavy amounts of work in PHP (with obsessive data checking). If I could find something that offers the same amount of power while continuing to allow me to keep a complete separation of the logic and presentation, I'd switch that minute. -
Re:Point of fact...
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 mod-security and Bad-Behaviour
Use Bad-Behaviour and mod-security.
These two work perfect for me. -
XSS is Common Because Our Tools Are Broken
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
-
mod_security
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. -
Re:OCR
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 ). -
Solution
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. -
Re:PHP vs. Java
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 -
Re:no login shell
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 -
Re:... and they affect Linux tooIf they are doing it with URL overflows, look for url requests that are over, say 80 characters, and throw them away.
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.
-
modsecurity for web apps
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.
-
mod_security
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. -
Proper Apache configuration helps too...
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. -
Third-party modules?
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.
-
Re:Free Software Wins again.
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" -
mod_security evaluation by Tegatai Systems
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.
-
Another neat module I've never heard of before...
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. -
Web Intrustion Detection
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.
-
Re:i've always wanted to know..
Or, you could add the mod_security module to your Apache server to take care of those common errors for you.