Re: Please vote - how to handle AllowEncodedSlashes
I've been following the discussion on this topic and, and I'd like to share a thought with you. From the security perspective, allowing end users to control how %2f is treated is problematic. Consider the situation in which you have some sort of a HTTP monitoring device (either passive, or a reverse proxy) in front of httpd. For this device to be effective, it must interpret traffic in the way identical to the interpretation of the web server. But if the %2f treatment is configurable, the device won't know if /path%2fto is the same as /path/to. That creates a problem, for example, when the device has to apply two different policies based on the path (e.g., one policy for /path, another for /path/to). A similar problem arises when httpd is used as a reverse proxy, forwarding traffic to a backend server that handles %2f differently. There are also other issues related to case sensitivity, the use of other characters as path separators, and so on. To sum it up, it would be best to choose one correct way to handle a %2f and stick with it. That means getting rid of the AllowEncodedSlashes directive, which was a bad idea to begin with. (On the other hand, if you think that AllowEncodedSlashes should stay, then Apache should add new directives to add all the other evasion techniques that apply in reverse-proxy mode.) On Mon, Jan 24, 2011 at 5:58 PM, Jim Jagielski j...@jagunet.com wrote: On Jan 22, 2011, at 3:45 AM, Ruediger Pluem wrote: [X] 4. backport the trunk behavior, but using a new option to set the current 2.2 behavior to avoid breaking existing configurations from 2.0/trunk but enable 2.2 users that rely on the new 2.2 behavior to get this back +1 -- Ivan Ristić
Re: mod_ssl, SNI and dynamic virtual hosts
You are assuming that the domain name will be in the SSL handshake. While it will be, in many cases, a very large number of browsers won't send it. In particular, Internet Explorer running on Windows XP does not support SNI. For more information, have a look at: http://en.wikipedia.org/wiki/Server_Name_Indication Once SNI becomes widely adopted (i.e. Windows XP dies), then, yes, you may need to resort to resolving certificates at run-time to support your setup . On Tue, May 25, 2010 at 11:03 AM, Adam Hasselbalch Hansen a...@one.com wrote: Adam Hasselbalch Hansen wrote: We have a setup that uses an in-house module which works not entirely unlike mod_vhost_alias, in that it has a single virtual host configured, and then determines stuff like domain name, docroot, etc, from the request. We'd love to be able to use SSL in this setup, but as far as I can see, the only way to do this would be to change (i.e. hack) mod_ssl to do the certificate loading sometime around request-time, since the apache server and SSL have no clue what virtual hosts they will be serving at startup. How would such a hack, if at all possible, affect stuff like certificate caching and other things? I'd love any feedback! Anyone? -- Adam Hasselbalch Hansen UNIX Systems Developer, CPH e: a...@one.com, w: www.one.com -- Ivan Ristic ModSecurity Handbook [http://www.modsecurityhandbook.com] SSL Labs [https://www.ssllabs.com/ssldb/]
Re: better SSL defaults in 2.4
Speaking of the SSL defaults, has anyone come up with something better than: BrowserMatch .*MSIE.* \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 Is anyone aware of any good reference that documents why the above code was added, and perhaps also explains how to test and what exactly the consequences of not using the snippet are? I am willing to test recent IE versions to see how they behave, but it'd be nice if I could have a decent starting point. On Wed, Nov 18, 2009 at 2:54 PM, Jeff Trawick traw...@gmail.com wrote: enable session cache by default? change SSLMutex default to SSLMutex default instead of SSLMutex none? (does this default to none to avoid checking if a session cache is enabled before creating the mutex?) -- Ivan Ristic ModSecurity Handbook [https://www.feistyduck.com] SSL Labs [https://www.ssllabs.com/ssldb/]
Re: Output filter order selection
[Sorry for my late response Ben, I missed your reply originally.
Comments below.]
On Mon, Sep 14, 2009 at 9:14 PM, Ben Noordhuis i...@bnoordhuis.nl wrote:
On Mon, Sep 14, 2009 at 21:39, Ivan Ristic ivan.ris...@gmail.com wrote:
There's an incompatibility between ModSecurity and mod_deflate, which
I would like to fix it. (It is triggered when AddOutputFilterByType is
used.) I basically need to ensure that ModSecurity's output filter
runs before mod_deflate's in all cases. I am aware of mod_filter
(which I suspect should be able to deal with this situation), but I
prefer a solution that does not require further work on the part of
ModSecurity users.
It depends. If module X registers its output filter in, for example,
the post-config hook, you can register your own hook and have it run
before module X's like so:
const char *runAfterUs = { mod_x.c, NULL };
ap_hook_post_config(your_post_config_hook, NULL, runAfterUs, HOOK_MIDDLE);
If however the module registers its output filter during the 'register
hooks' phase like mod_deflate does, your best bet is to register your
own filter and manipulate the ap_filter_rec_t structure (which is
essentially a linked list) so that your filter comes before
mod_deflate's.
Yes, I tried that first, but it didn't work. mod_deflate does register
its hooks in the register_hooks phase, but they are added to the
filter chain only later, by whoever handles the AddOutputFilterByType
directive (the core, I am guessing).
It's not entirely according to the book but it should be a fairly
robust solution. ap_filter_rec_t lives in util_filter, which is part
of the module API, and isn't a opaque structure so I don't foresee it
changing anytime soon.
This is, of course, to the best of my knowledge. I'm not aware of a
better way, but if there is, I'd also like to hear it. =)
After some more poking I decided that registering ModSecurity's output
filter to run as CONTENT_SET - 3 should be all right. A review of the
Apache's code revealed that this method (subtracting and adding from
known filter values) is used throughout to ensure filters run before
or after other filters. There are some filters (SUBREQ_CORE,
mod_expires and mod_cache) that use CONTENT_SET - 1 and CONTENT_SET -
2. No core module uses CONTENT_SET - 3.
--
Ivan Ristic
Security assessment of your SSL servers
https://www.ssllabs.com/ssldb/
Re: POST Body Buffer?
Are your multi-megabyte submissions going to use multipart/form-data encoding? If so, ModSecurity does exactly what you need when you enable request body buffering. Ivan On 19 Jun 2009, at 21:01, Houser, Rick houser.r...@aoins.com wrote: I'm facing a situation where we may be required to handle multi- megabyte POST submissions from dial-up users. We want to avoid tying up the backend servers for long periods of time if possible. Does anyone know of either built-in support for pre-buffering complete POST request bodies (i.e. avoid streaming through to the WAS plug-in) or a module that would do that same? If no, does this approach sound right? Input filter that: (a) determines if it should do anything (looks at the content-length, URL, etc.) (b) looks at each bucket (AP_MODE_PEEK?), holds a reference, and returns a empty brigade unless EOS found (c) if EOS found, the output brigade is filled with all the existing buckets I'm currently running 2.0, but could bump up my migration to 2.2 if there's a specific feature that would help. Thanks, Rick Houser Auto-Owners Insurance Systems Support (517)703-2580
Re: Reading request body an writing it back to the chain
You can look at how ModSecurity (http://www.modsecurity.org) does it: you can read the request body and store it somewhere, then you insert and input filter that sends data from the buffer down the chain and removes itself from the chain once it's done. You can choose where you're reading the request body. In a pure-filter approach you will read it on the first invocation. Alternatively, you can read it in a hook, but store it somewhere where your filter will find it. In the latter case, the purpose of the filter will be only to pass on the data in your buffer. By the way, ModSecurity can already do what you're describing. On Mon, Dec 15, 2008 at 11:04 AM, Ferdinand Arndt ferdinand.ar...@axiros.com wrote: Hi, I am trying to make a module that does the following: 1. Reading the request body 2. Checking the data with some regex 3. Setting some environment variables The environment variables are for later processing with mod_rewrite. My problem is, how to write the content of the request back to the chain, so that it can be used later again in other modules or can be forwared to another server with mod_rewrite/mod_proxy. My first approach is to do it all in an input filter, but as far as I understand it, the filter is only active, if I read the content in another hook outside the filter. So how can I read the data and write it back? /Regards, Ferdinand -- Ivan Ristic
Re: Reading request body an writing it back to the chain
On Mon, Dec 15, 2008 at 11:30 AM, Ferdinand Arndt ferdinand.ar...@axiros.com wrote: On Dec 15, 2008, at 12:10 PM, Ivan Ristic wrote: You can look at how ModSecurity (http://www.modsecurity.org) does it: you can read the request body and store it somewhere, then you insert and input filter that sends data from the buffer down the chain and removes itself from the chain once it's done. You can choose where you're reading the request body. In a pure-filter approach you will read it on the first invocation. Alternatively, you can read it in a hook, but store it somewhere where your filter will find it. In the latter case, the purpose of the filter will be only to pass on the data in your buffer. Ok, thank you, I'll have a look at it. So my inputfilter has to be executed before any other input filter runs. By the way, ModSecurity can already do what you're describing. Unfortunately, I have to perform also database lookups and use this data in my regex, so I unfortunately have to do it by myself :( Maybe. But, just FYI, it is trivial to extend ModSecurity with custom code (by writing another Apache module that makes itself known to ModSecurity, using the optional functions mechanism of Apache). There are some examples in the api subfolder. On Mon, Dec 15, 2008 at 11:04 AM, Ferdinand Arndt ferdinand.ar...@axiros.com wrote: Hi, I am trying to make a module that does the following: 1. Reading the request body 2. Checking the data with some regex 3. Setting some environment variables The environment variables are for later processing with mod_rewrite. My problem is, how to write the content of the request back to the chain, so that it can be used later again in other modules or can be forwared to another server with mod_rewrite/mod_proxy. My first approach is to do it all in an input filter, but as far as I understand it, the filter is only active, if I read the content in another hook outside the filter. So how can I read the data and write it back? /Regards, Ferdinand -- Ivan Ristic -- Ivan Ristic
Re: My hacked mod_xsendfile
I think it will be all right provided the feature is disabled by default and, as you say, the potential security issue is documented. On Jan 28, 2008 1:28 PM, Akins, Brian [EMAIL PROTECTED] wrote: On 1/28/08 4:35 AM, Ivan Ristic [EMAIL PROTECTED] wrote: The FastCGI process is likely to be running under a different account, but here we have a facility that allows that other process to use the privileges of the Apache user to fetch a file. I can see how this feature could easily find its way to the list of small tricks that can be used to compromise a web server installation, one step at a time. Perhaps. Most of out fastcgi stuff gets executed by httpd, so it has the same privileges. Also php under fastgci has access to everything completely outside httpd, for example. I guess if we choose to include support, but the appropriate security warnings. Also, this approach will use all the normal httpd file access controls rather than just grabbing it directly. It is also a first draft and I'm sure needs work, but I'd like us to push to get xsendfile into core. It's already Apache license, if that helps. -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies -- Ivan Ristic
Re: My hacked mod_xsendfile
On Jan 25, 2008 7:55 PM, Akins, Brian [EMAIL PROTECTED] wrote: I started to play with xsendfile more. I noticed the mod_xsendfile floating around tried to basically replace what the default handler does very well. Basically, my version does a subrequest for the file. This allows things like Deny from all, etc, to work. This should be more secure, ie, if you set your deny's correctly, you can't X-Sendfile: /etc/passwd. All in all, it seems more httpd-like, to me. I am not very familiar with X-Sendfile (as in: I read about it but never used it), but it sounds like it's breaking the FastCGI security model. The FastCGI process is likely to be running under a different account, but here we have a facility that allows that other process to use the privileges of the Apache user to fetch a file. I can see how this feature could easily find its way to the list of small tricks that can be used to compromise a web server installation, one step at a time. It is very rough. I do not understand brigades enough to know why it is chunking every reply in my tests. I have tested with just a normal cgi setting the header. Not well tested. I'd like to see us work toward getting X-sendfile into the normal httpd distribution (along with mod_fcgid...) -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies -- Ivan Ristic
Re: High security
On Jan 25, 2008 1:30 PM, Nick Kew [EMAIL PROTECTED] wrote: ... A compromise might be to create a chroot hook and allow module developers to use it. This would shift the support burden somewhat from the core Apache team to those willing to engage the users providing support. Isn't that basically the status quo (mod_security presumably hooks it in at post_config?) In ModSecurity I had to use one of the available hooks to execute the chroot call. As Torsten mentions, that might be a much better place to do it. Personally, I don't really have a need for the internal chroot feature ever since I discovered the makejail utility (part of Debian, and maybe other systems), which worked really well for me. On the other hand, I am interested in getting Apache to drop certain capabilities (where supported) at startup. I plan to look into it eventually. Can we expect your contributions to the apache core code in the not-too-distant? Possibly... Maybe I should aim to start with something simpler; for example, by proposing the suexec chroot patch I have lying around somewhere. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/ -- Ivan Ristic
Re: High security
I don't think this should be a discussion of whether chroot is worth using as a security measure. IMHO it should be about allowing Apache users to make a choice whether they will use chroot in this way or not. I am usually an advocate for user choice. For example, I am well aware of the various disadvantages of chroot but I still find some cases where it is useful. In particular, it is very good in preventing (or limiting damage from) automated attacks. It is also very good in significantly raising the effort required to compromise a server after a successful compromise of the web server installation running on it (e.g. through a badly written web application). For the record, I have regretted including the chroot feature in ModSecurity many times over. Not because of the feature itself (which -- I still think -- is very useful when the circumstances are right) but because of the support I was required to provide on the mailing list over the years. To troubleshoot chroot issues requires a very good understanding of how things work and takes a lot of time. Subtle problems may arise with modules that are not expecting to be cut-off from the filesystem half-way through, or with modules that fork at startup. With this in mind, I have always felt the reluctance of the Apache developers to include support for chroot has more to do with these support issues rather than with any technical reasons. A compromise might be to create a chroot hook and allow module developers to use it. This would shift the support burden somewhat from the core Apache team to those willing to engage the users providing support. Personally, I don't really have a need for the internal chroot feature ever since I discovered the makejail utility (part of Debian, and maybe other systems), which worked really well for me. On the other hand, I am interested in getting Apache to drop certain capabilities (where supported) at startup. I plan to look into it eventually. On Jan 24, 2008 8:33 PM, Ruediger Pluem [EMAIL PROTECTED] wrote: On 01/24/2008 04:55 PM, Nick Gearls wrote: Yes, chroot could potentially be escaped. Although, if you chroot the main process, then you spawn child processes under another userid, like in standard Apache config under Unix, I expect it to be really very difficult to escape if 1. you are not root 2. if the only files available are log files and htdocs files (even no HTML files in case of a reverse proxy Obviously, we could imagine a vulnerability (like a buffer overrun) in the child Apache process that would send a signal to the main process to use a second vulnerability, but I really find that chrooting Apache provides a very good defense. It is some kind of defense, but as stated chroot is not really a security tool (see also http://it.slashdot.org/article.pl?sid=07/09/27/2256235). Nevertheless, back to your problem. I think there is no gain at all doing a chroot in the httpd main process which keeps running as root. So IMHO mod_security is doing the chroot too early by doing it in the post config hook. I admit that I do not see any other hook at the moment to do this. But there is a patch in trunk that does chroot only for the child processes, just before the userid is switched. I haven't tested this so far, but this should work with graceful restarts. Plus: You do not need to keep your logs in the chroot jail as the logfiles are opened by the main process. Patch: http://svn.apache.org/viewvc?view=revrevision=611483 PR: http://issues.apache.org/bugzilla/show_bug.cgi?id=43596 Regards Rüdiger -- Ivan Ristic
Re: Limiting response body length
On 2/13/07, Dziugas Baltrunas [EMAIL PROTECTED] wrote:
Hi list,
thanks for the replies. Looks like squid in case Content-Length
response header is missing, does it's limitation in a hard way (snip
from src/client_side.c):
} else if (clientReplyBodyTooLarge(http, http-out.offset - 4096)) {
/* 4096 is a margin for the HTTP headers included in out.offset */
comm_close(fd);
} else {
However this seems to be the only way in case we want to avoid content
buffering. mod_security also relies on Content-Length an if is not
present, output buffering (and I suppose the limitation as well) stops
(snip from apache2/apache2_io.c:output_filter):
No. If there's no C-L ModSecurity will count the bytes as they arrive.
If there are too many the entire response will be blocked with 500
(and the error page sent to the client).
case 0 :
/* We do not want to observe this response body
* but we need to remain attached to observe
* when it is completed so that we can run
* the RESPONSE_BODY phase.
*/
msr-of_skipping = 1;
msr-resbody_status = RESBODY_STATUS_NOT_READ;
break;
The above happens when ModSecurity decides it is not interested in the
content (e.g. if it is an image, or some other opaque file).
On 2/13/07, Nick Kew [EMAIL PROTECTED] wrote:
On Mon, 12 Feb 2007 23:35:24 +0100
Henrik Nordstrom [EMAIL PROTECTED] wrote:
mån 2007-02-12 klockan 21:55 + skrev Nick Kew:
Because the chunking filter is equipped to discard the chunk that
takes it over the limit, and substitute end-of-chunking.
If we do that in a new filter, we have to reinvent that wheel.
Not sure substitue end-of-chunking is a reasonable thing here. It's
an abort condition, not an EOF condition. Imho you'd better abort the
flow, that way telling the client that the request failed instead of
silently truncating the response.
How would you abort it other than by truncating it?
Don't forget, the headers are long gone.
If you don't send an end-marker, the client will
sit there waiting for more.
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/
--
Dziugas
--
Ivan Ristic
Re: Limiting response body length
On 2/13/07, Nick Kew [EMAIL PROTECTED] wrote: On Tue, 13 Feb 2007 11:30:32 + Ivan Ristic [EMAIL PROTECTED] wrote: No. If there's no C-L ModSecurity will count the bytes as they arrive. If there are too many the entire response will be blocked with 500 (and the error page sent to the client). That's a tradeoff you make against performance. Of course it's a tradeoff. Isn't everything? I would consider it unacceptable to buffer entire requests or responses at a proxy. That depends entirely on system's security requirements. Some people require the screening/prevention functionality. Some people, such as yourself, don't. It's for everyone to consider what they want, along with the implications, and make their decisions accordingly. At best it's a big performance hit; at worst it's a DoS-magnet. Don't be so dramatic :) Every single new feature added to a web server is a performance hit and a DoS magnet. And yet there's plenty of sites that moved on from static files! The ingredients matter but it's how you build it that counts. I have made it a point to document everything there is to know about ModSecurity. It's what it is. I built it because it was fun and because I could. People should make their own minds. I am fine either way. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/ -- Ivan Ristic
Re: Limiting response body length
On 2/12/07, Ding Deng [EMAIL PROTECTED] wrote: Dziugas Baltrunas [EMAIL PROTECTED] writes: Hi list, I'm wondering if there any plans to implement implement a response body length limitation inside mod_proxy? For now we have only a global LimitRequestBody and what I'm looking is an analog LimitResponseBody. In case Apache HTTP works as a reverse/forward proxy, it's usual case for a proxy to block downloading files of a certain size (huge MP3 files as an example). To illustrate, squid for this purpose has reply_body_max_size [1] parameter. Looks like it is only Content-Length response header (if any) dependent, but IMHO with Apache filtering mechanism it should be possible to cancel a fetch transaction when output byte counter reaches some boundary. I've also tried to look at exiting third party modules like mod_throttle [2] (deprecated), mod_cband [3] and mod_bw [4], but all of them seem to be tied on bandwidth limitations and not a limits of a single request. mod_security may do the trick. It would do the trick, but only for those transactions that have response buffering enabled. When buffering is not enabled limits are not enforced. Thanks in advance. [1] http://www.visolve.com:81/squid/squid30/accesscontrols.php#reply_body_max_size [2] http://www.snert.com/Software/apache.html [3] http://cband.linux.pl/ [4] http://bwmod.sourceforge.net/, http://svn.apache.org/viewvc/httpd/mod_bw/ -- Dziugas Baltrunas -- Ivan Ristic
Re: State of perchild MPM
[Let's continue the discussion privately from now on as it's becoming less relevant for the httpd project...] On 2/2/07, Arnold Daniels [EMAIL PROTECTED] wrote: ... You do not need a secret, but the users who may changed are specified. In our setup user 'www-data', which has no privileges on the server, may change into any shared hosting user. Within the process where www-data changed into the shared hosting user, a call can be made to change back into 'www-data'. Since running a CGI script starts a new process, it is not possible for a shared hosting user to change into 'www-data' using a custom CGI script. Good. Still, if you allow PHP users to load their own code from shared libraries they'll be able to revert back to the www-data user. Due to permissions it isn't possible for customers to place any files in the extension directory and PHP won't load any binaries outside that directory. Anyhow it is highly recommended that dl() is disabled. Which is the case on our system. Good. Still, you are relying on mod_php to enforce certain restrictions. I prefer a mechanism where you can deploy securely with any module and any module configuration. We don't log to file, but use UDP, still the same goes. A hacker can't really accomplish anything with writing data to the log, except maybe a bit of vandalism. I actually think that is a very serious problem. With the ability to add to the access logs someone could frame a person for hacking. I'm not sure how the privileges of the access log are currently set on our system. But the access log could of course be written by www-data, so before the user is switched, which solves the problem. If you are using syslog/UDP then, because syslog lacks authentication, any user can fake an access log entry. As for the access log permissions - root should be the only user allowed write access. Either way, if a file descriptor is inherited then any user can write to it (permissions of the user that opened the FD are used). -- Ivan Ristic
Re: State of perchild MPM
Comments below. On 1/31/07, Arnold Daniels [EMAIL PROTECTED] wrote: Hi, I can't answer all your questions, since I'm not the developer of the patch and module. I've forwarded this message to Rik Arends. But let me answer the onces I can. We've looked at running PHP as CGI, but we've noticed a performance drop compared to running PHP as module, effectively being able to run 25% to 30% less accounts on a server, which is significant when you're running discount hosting. Besides this performance drop, running PHP as CGI doesn't really solve the problem. We run about 300 customers per server. All of which have their own system user, the 'shared hosting users'. We want all files, PHP files as well as HTML files, images, etc, to be owned by the shared hosting user without privileges for others (660). For Apache to handle a request, it needs to run under that user instead of www-data. That should be possible to do using suExec and some juggling of file permissions. Although it does create a problem where the user scripts run as also has write permissions over all files. I prefer to use two accounts, one to manipulate the files with, the other to execute scripts with. But this is difficult to pull off with mass hosting. We tried the perchild, but starting a new apache process for just about each request, promoted serious performance issues (I don't have the figures at hand, but it wasn't an option) as well as not being stable. It's not common for a setup like this to offer SSL, since it requires an unique IP address to be save. The module currently also implements mass virtual hosting, making it even impossible to support SSL. You do not need a secret, but the users who may changed are specified. In our setup user 'www-data', which has no privileges on the server, may change into any shared hosting user. Within the process where www-data changed into the shared hosting user, a call can be made to change back into 'www-data'. Since running a CGI script starts a new process, it is not possible for a shared hosting user to change into 'www-data' using a custom CGI script. Good. Still, if you allow PHP users to load their own code from shared libraries they'll be able to revert back to the www-data user. We don't log to file, but use UDP, still the same goes. A hacker can't really accomplish anything with writing data to the log, except maybe a bit of vandalism. I actually think that is a very serious problem. With the ability to add to the access logs someone could frame a person for hacking. Perhaps you give some examples on how the file descriptors can be used to take over the network sockets. I haven't tried to exploit the issue myself but, from memory, I believe it is enough to duplicate the original descriptor, close the original (thus preventing Apache from using it), and then serve your own stuff using the duplicate. The last time I looked PHP leaked file descriptors even on execution of external binaries, making it trivial to exploit the issue provided external command execution is allowed. Disclaimer: I played with this two years ago. It might have been silently fixed since then. But with a large number of different versions of Apache and PHP in deployment the only way to be sure is to test. I recommend env_audit (http://www.web-insights.net/env_audit/). We are aware that the solution might not yet be solid, be we think the approach is the right way to go. Of course, we're currently enjoying security by obscurity, but with your help and other experts on Apache internals, we should be able to make this into a good solution. Best regards, Arnold Ivan Ristic schreef: Hi Arnold, You have obviously spent a great deal of time implementing your solution. Personally I have always felt complete separation (e.g. what is done with FastCGI) is a more robust approach. But I don't think the issues surrounding the choices have been discussed enough in the public. If you don't mind I would appreciate if you could share your opinions and experiences. In particular, I am wondering if and how are you handling the issue of leaked Apache file descriptors (under quotes because they are not really leaked - it's the same process)? These file descriptors can be abused to, for example, log to the Apache log files and take over the network sockets. The other issue is the users loading custom shared libraries to gain direct access to the process memory and then extract sensitive information from it (e.g. SSL keys). Other questions that come to mind: 1) Have you ever evaluated a FastCGI-based approach? 2) Have you ever measured the performance increase you gain with your solution (as opposed to having a pure suExec-based approach)? 3) Do you require a secret of some kind to change users? For example, can I change the user from custom CGI script or a binary executed from PHP? Thanks, Ivan On 1/31/07, Arnold Daniels [EMAIL PROTECTED] wrote: Hi, We run a shared
Re: State of perchild MPM
, Rik Arends Originele bericht Onderwerp: RE: [PHP-DEV] Comments on PHP security Datum: Thu, 18 Jan 2007 14:14:17 -0800 Van: Andi Gutmans [EMAIL PROTECTED] Aan: 'Arnold Daniels' [EMAIL PROTECTED], internals@lists.php.net I haven't seen the patch yet but my concern would be with resources which have already been opened. Unless you guys clean that up in between requests it can be very dangerous as I doubt Linux re-verify's permissions when those are accessed. In any case, I'd be happy to review and might be completely wrong... - Nick Kew schreef: On Mon, 29 Jan 2007 20:31:40 -0600 [EMAIL PROTECTED] wrote: I have gotten the impression this may be a sore subject for the list based on searching through the archives, but I do not intend to work anyone up. I have been trying to find a solution to the problem of shared hosting with a dynamic language such as PHP. I found the old perchild MPM and it appears it is not being maintained or there was possibly a design problem. I would like to know two things. 1. Is there a mechanism (other than suexec) that allows functionality similar to perchild, that will allow a uid to be assigned on a per request basis? There are several third-party solutions: google for metux, peruser, mod_ruid, and fastcgi. 2. If there is, do the developers need help with it? I can write C and I am willing to help out with this. If there is not, Would anyone from the Apache team be interested in working with me so I may write such functionality, maybe for a future version of Apache? Patches welcome. Bear in mind that perchild was threaded, and therefore never likely to be suitable for php. -- Ivan Ristic
Re: Dynamic registration of a module in Apache 2.X?
On 11/29/06, Nick Kew [EMAIL PROTECTED] wrote: On Wed, 29 Nov 2006 16:27:23 +0200 Bartov, Asaf [EMAIL PROTECTED] wrote: Hello. Is it possible to dynamically register a new module (given some mod_moose.so) in a *running* httpd process, to get it to work *without* writing to the config file or restarting the httpd process? Essentially, to inject a module into a running httpd process, given appropriate, even root, permissions. Not off-the-shelf, but there are third-party modules that'll load and unload .so s in a running server. Can you name some of them? Thanks. -- Ivan Ristic
Re: Win x64 build targets?
On 11/2/06, Jorge Schrauwen [EMAIL PROTECTED] wrote: Yes its possible with some minor effort. ... Other modules i found that work fine: mod_auth_xml mod_macro mod_security 1.9.4 (2.0 doesn't work because of libxml grrr) FYI you should be able compile ModSecurity with XML features left out. Just comment out the DEFS = -DWITH_LIBXML2 line in the Makefile. -- Ivan Ristic
Re: Win x64 build targets?
On 11/2/06, Nick Kew [EMAIL PROTECTED] wrote: On Thu, 2 Nov 2006 12:41:39 + Ivan Ristic [EMAIL PROTECTED] wrote: Other modules i found that work fine: mod_auth_xml mod_macro mod_security 1.9.4 (2.0 doesn't work because of libxml grrr) FYI you should be able compile ModSecurity with XML features left out. Just comment out the DEFS = -DWITH_LIBXML2 line in the Makefile. Why is that? libxml2 works fine in Windows, and with apache in many different modules. Do you know why it's incompatible with mod_security, or is this just awaiting a round tuit? No, no, no. ModSecurity works fine with libxml2 (it uses it to parse and inspect XML). I understood the original poster to say that libxml2 does not work on Win x64 so I simply pointed out a way to avoid the problem (if you only need libxml2 for ModSecurity and you don't need the XML features). BTW, what's a round tuit? :) -- Ivan Ristic
Re: [PATCH 40026] ServerTokens Off
On 8/21/06, Ruediger Pluem [EMAIL PROTECTED] wrote: Not that I want to use it, but I am just curious about which one that could be. I know that you can hide the presence of mod_security itself from the server header ModSecurity does not advertise itself in the Server header, at least not any more. (It only did that in the very early days, before I realised it was a mistake.) but I do not know how to remove the Server header completly with mod_security. It is not possible to remove the Server header completely. ModSecurity can only change it to something else. But I guess one could write an output filter to remove it. In fact, I seem to recall someone mentioning such output filter recently. Now if I could only remember where... BTW, for all it's worth, I think Apache should support Server header removal/customisation natively. People that want to change/remove the Server header will do that anyway. Apache supporting the feature directly would mean that they will be able to do the job quickly and get on with their lives. -- Ivan Ristic, Technical Director Thinking Stone, http://www.thinkingstone.com ModSecurity: Open source Web Application Firewall
Trouble with the bundled PCRE
I have a problem with the bundled PCRE that I am not sure how to resolve. Basically, in a module I need to access more functionality than provided by the Apache PCRE wrapper. (More specifically, I need to perform matching against strings that are not NULL-terminated.) I can do this if I have the Apache source code around, simply by using the PCRE headers that are in the source tree. But I can't do that when there is no source code since the PCRE headers are not available. Is there a smart way around this? Am I missing anything? Is there a reason for not including the PCRE headers in the /include/ directory of the Apache installation? I'd be happy to submit a patch that makes more functionality available through the wrapper but that is not going to solve my short-term problems. (And I also think it makes more sense to make the wrapper, if it is going to be full-featured, part of APR, or APR-UTIL.) -- Ivan Ristic, Technical Director Thinking Stone, http://www.thinkingstone.com ModSecurity: Open source Web Application Firewall
Re: Execute apache or php as different user per virtualhost.
Quote: Also, CGI isn't an option. Currently the host uses the 'Apache 2.0 Handler'. We use Apache 2.0.x SuExec needs CGI, so that isn't an option. SuExec plus FastCGI should give you the performance *and* security. There are two FastCGI modules available: mod_fastcgi (works fine for me) and mod_fcgi (never used it). -- Ivan Ristic, Technical Director Thinking Stone, http://www.thinkingstone.com ModSecurity: Open source Web Application Firewall
Re: Philosophy, empty body still a request body?
On 7/5/05, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: RFC2616 says TRACE doesn't accept a body. Patches I'd committed to 1.3.x and working on 2.1.x (to port to 2.0.x) enforce this with TraceEnable On. But what about a 0-byte body? I think it is a body. Yes, it is only 0 bytes long but it is a body none the less. I think the right thing to do is not allow it for TRACE. Ivan
Re: Monitoring HTTP error logs
On 6/28/05, Henri Gomez [EMAIL PROTECTED] wrote: Hi to all, Did you know a tools on Unix/Linux system, which should be able to monitor in real-time the error_log of Apache2 servers and for example, send email/syslog message when a [error] string is detected ? Try SWATCH (http://swatch.sourceforge.net/) or SEC (Simple Event Correlator, http://kodu.neti.ee/~risto/sec/). The later is more complex but significantly more powerful. -- Ivan Ristic Apache Security (O'Reilly) - http://www.apachesecurity.net Open source web application firewall - http://www.modsecurity.org
Re: Re: RFC for a Perchild-like-MPM
Which reading part? I am not in a position to test right now but I think FastCGI never even required a file to exist on the local system, provided a proper handler was assigned to the request. But even if it does it's an implementation issue of mod_fastcgi, as FastCGI is just a data exchange protocol. Bye, Ivan - Original Message - Subject: Re: RFC for a Perchild-like-MPM From: Gustavo A. Baratto [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: 26-11-2004 3:18 I think the only part missing right now is the ability to compile Apache to function as a FastCGI client, and accept requests over FastCGI instead of HTTP. That can be a full version of Apache, or a slimmed-down version (e.g. with no input/output filters). It is a great idea use FastCGI's process manager to spawn httpd processes. FastCGI as it is now is ok when we need to execute stuff with another UID other than the webserver's But it doesn't address the reading part, which still have to be done by 'www' user... and this is a major problem.
Re: RFC for a Perchild-like-MPM
Max Bowsher wrote: Quoting Ivan Ristic ivanr webkreator com (2004-11-17 17:31:39 GMT): I've used FastCGI to give individual users their own PHP engines (since PHP now comes with FastCGI protocol support built-in). This sounds useful - would you be willing to share some config file samples? Sure: --- LoadModule fastcgi_module modules/mod_fastcgi.so FastCgiWrapper /usr/local/apache/bin/suexec # This configuration will recycle persistent processes once every # 300 seconds, and make sure no processes run unless there is # a need for them to run. FastCgiConfig -singleThreshold 100 -minProcesses 0 -killInterval 300 NameVirtualHost * VirtualHost * ServerName ivanr.example.com DocumentRoot /home/ivanr/public_html SuexecUserGroup ivanr ivanr AddHandler application/x-httpd-php .php Action application/x-httpd-php /fastcgi-bin/php # this is a normal CGI folder Directory /home/ivanr/public_html/cgi-bin Options +ExecCGI SetHandler cgi-script /Directory Directory /home/ivanr/public_html/fastcgi-bin Options +ExecCGI SetHandler fastcgi-script /Directory /VirtualHost --- A copy of PHP that is FastCGI-aware should be placed at /home/ivanr/public_html/fastcgi-bin/php (compile PHP as CGI and --enable-fastcgi). PHP will tell you whether it understands FastCGI or not when invoked directly: # /home/ivanr/public_html/fastcgi-bin/php -v PHP 5.0.2 (cgi-fcgi) (built: Nov 19 2004 11:09:11) If a php.ini file is present in the same location it will be picked up automatically, thus allowing each user to configure their PHP instance as they're pleased. Once you get it up and running (suEXEC is a pain, as usual), tail the suexec log to make sure PHP is started only once, and that all subsequent invocations are handled by the persistent instance (obviously, nothing appears in the suexec log). -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ]
Re: RFC for a Perchild-like-MPM
Leif W wrote: Andrew Stribblehill, Thursday, November 18, 2004 07:53 Quoting Ivan Ristic [EMAIL PROTECTED] (2004-11-17 17:31:39 GMT): Paul Querna wrote: Are you familiar with FastCGI? My first impression is that most of what you envision is possible today with FastCGI, or would be possible with some (small) additional effort. FastCGI is non-free. This solution also copes with things like mod_php and mod_perl being a different user. A Good Thing IMO. Just to clarify: Which FastCGI are we talking about? There are two listed on http://modules.apache.org/ . There's the (former?) OpenMarket's http://fastcgi.com/ (mod_fastcgi), with the unclear license, In what sense is the licence unclear? But even if it is, I think it is worth to reuse the protocol alone. There are many well-tested FastCGI libraries that support it on the client side. If the general idea of using FastCGI is acceptable a stress test can be performed to determine whether the performance of the existing modules/libraries is adequate. which was last released as version 2.4.2 on 2003-11-24. Does it still work with Apache httpd 2.0.x? Works fine with httpd 2.0.x in my tests (mod_fastcgi 2.4.2, I didn't try the more recent snapshot). I have the impression that many people feel FastCGI is dead because there isn't much activity on the web site. But it seems to me the authors have just made the protocol (and the Apache module) do what they wanted it to do. Does it work with 2.1.x? I don't know. Then there's http://fastcgi.coremail.cn/ (mod_fcgid), is GPL, which implements the FastCGI protocol, and was last released as version 1.0 on 2004-09-14. Is this implementation complete, efficient, comparable to the original mod_fastcgi? Never used that one. The web site does not say what motivated the developer to produce another implementation. -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ]
Re: RFC for a Perchild-like-MPM
Andrew Stribblehill wrote: Quoting Ivan Ristic [EMAIL PROTECTED] (2004-11-17 17:31:39 GMT): Paul Querna wrote: I have had an idea for replacing the perchild MPM boggling around inside my head for awhile now. This is an idea for a different architecture to allowing different UIDs to serve httpd requests. I am looking for all feedback with my proposed approach. Are you familiar with FastCGI? My first impression is that most of what you envision is possible today with FastCGI, or would be possible with some (small) additional effort. FastCGI comes with a process manager that can be configured to start server processes on demand. Server processes can work as different uids (through suEXEC). I've used FastCGI to give individual users their own PHP engines (since PHP now comes with FastCGI protocol support built-in). I think the only part missing right now is the ability to compile Apache to function as a FastCGI client, and accept requests over FastCGI instead of HTTP. That can be a full version of Apache, or a slimmed-down version (e.g. with no input/output filters). FastCGI is non-free. This solution also copes with things like mod_php and mod_perl being a different user. A Good Thing IMO. Below is the licence included in the distribution. The way I read it it's compatible with the Apache licence. --- This FastCGI application library source and object code (the Software) and its documentation (the Documentation) are copyrighted by Open Market, Inc (Open Market). The following terms apply to all files associated with the Software and Documentation unless explicitly disclaimed in individual files. Open Market permits you to use, copy, modify, distribute, and license this Software and the Documentation for any purpose, provided that existing copyright notices are retained in all copies and that this notice is included verbatim in any distributions. No written agreement, license, or royalty fee is required for any of the authorized uses. Modifications to this Software and Documentation may be copyrighted by their authors and need not follow the licensing terms described here. If modifications to this Software and Documentation have new licensing terms, the new terms must be clearly indicated on the first page of each file where they apply. OPEN MARKET MAKES NO EXPRESS OR IMPLIED WARRANTY WITH RESPECT TO THE SOFTWARE OR THE DOCUMENTATION, INCLUDING WITHOUT LIMITATION ANY WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL OPEN MARKET BE LIABLE TO YOU OR ANY THIRD PARTY FOR ANY DAMAGES ARISING FROM OR RELATING TO THIS SOFTWARE OR THE DOCUMENTATION, INCLUDING, WITHOUT LIMITATION, ANY INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES OR SIMILAR DAMAGES, INCLUDING LOST PROFITS OR LOST DATA, EVEN IF OPEN MARKET HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. THE SOFTWARE AND DOCUMENTATION ARE PROVIDED AS IS. OPEN MARKET HAS NO LIABILITY IN CONTRACT, TORT, NEGLIGENCE OR OTHERWISE ARISING OUT OF THIS SOFTWARE OR THE DOCUMENTATION. --- -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ]
Re: People still using v1.3 - finding out why
Nathanael Noblet wrote: On Nov 18, 2004, at 11:43 AM, Graham Leggett wrote: Hi all, I've been keen to do some digging for reasons why someone might need to install httpd v1.3 instead of v2.0 or later. Support for mod_backhand seems to be a significant reason (and getting backhand ported to v2.0 would be a win): Apart from backhand, are there in the experience of the people on this list any other significant apps out there that are keeping people from deploying httpd v2.x? I think there is still a thought that php isn't mature on 2.x. (I'm using it) But some people, notably the php folks last I saw. Suggested 1.3 as the stable production server to use instead of 2.x Yes, that's a big reason in my experience. People tried using PHP with a multithreaded Apache long time ago, got burned, and are now afraid to try it again. I think it's mostly a matter of marketing now. I think it would be a good idea to go with a stable 2.2, and make a strong marketing push to get people to adopt it. -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ]
Re: People still using v1.3 - finding out why
Jim Jagielski wrote: A can think of 4 big reasons, two from a developer standpoint and two from an admin. developer: 1. Builds and compiles in a minute, rather than several. This means you can play around and develop more and compile less. 2. More streamlined design; for some filters, bb's and the dependency may be stumbling blocks. And: 3. While the 1.3 API is well documented, the documentation for 2.0 is sparse. I have always thought a good book on APR programming, possibly with a chapter or two on Apache, would do wonders for the popularity of Apache 2. -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ]
Re: RFC for a Perchild-like-MPM
Paul Querna wrote: I have had an idea for replacing the perchild MPM boggling around inside my head for awhile now. This is an idea for a different architecture to allowing different UIDs to serve httpd requests. I am looking for all feedback with my proposed approach. Are you familiar with FastCGI? My first impression is that most of what you envision is possible today with FastCGI, or would be possible with some (small) additional effort. FastCGI comes with a process manager that can be configured to start server processes on demand. Server processes can work as different uids (through suEXEC). I've used FastCGI to give individual users their own PHP engines (since PHP now comes with FastCGI protocol support built-in). I think the only part missing right now is the ability to compile Apache to function as a FastCGI client, and accept requests over FastCGI instead of HTTP. That can be a full version of Apache, or a slimmed-down version (e.g. with no input/output filters). -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ]
Re: cvs commit: httpd-2.0/server protocol.c
Roy T. Fielding wrote: What would make more sense is Error while reading HTTP request line. (remote browser didn't send a request?). This indicates exactly what httpd was trying to do when the error occurred, and gives a hint of why the error might have occurred. We used to have such a message. It was removed from httpd because too many users complained about the log file growing too fast, particularly since that is the message which will be logged every time a browser connects and then its initial request packet gets dropped by the network. This is not an error that the server admin can solve -- it is normal life on the Internet. We really shouldn't be logging it except when on DEBUG level. As you say, it is normal life on the Internet. I don't think Apache should be hiding the fact that many browsers don't finish with the request line, or timeout in some other way. But the main problem, and it's how this all started, is that without the message it becomes very difficult to detect when you are being attacked. At the same time such attacks are trivial to execute and don't require a fast connection. A smart attacker will open new connections at a very slow rate, just a bit faster then Apache closes them. The only way to figure it out is to be there when it happens or use some other network-level mechanism (netflow, argus, etc), but even that would involve long time of looking at the logs and comparing it to the access logs. As for people complaining about the error log growing too fast, I am sure their access logs grow *much* faster and they handle that without a problem. My point being logging is part of the package. I am OK with assigning this message to a low log level, but I don't think DEBUG is the correct choice. -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ]
Re: cvs commit: httpd-2.0/server protocol.c
In the case you just mentioned... it is going to take a special 'filter' to 'sense' that a possible DOS attack is in progress. Just fair amounts of 'dataless' connection requests from one or a small number of orgins doesn't qualify. There are plenty of official algorithms around now to 'sense' most of these brute force attacks and ( only then ) pop you an 'alert' or something. Just relying on a gazillion entries in a log file isn't the right way to 'officially' distinguish a DOS attack from just ( as Roy says ) 'life on the Internet'. Sure, you may need to have some logic to determine what makes an attack and what not, but you must have the log entry to begin with so you feed it to the algorithm. -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ]
Re: cvs commit: httpd-2.0/server protocol.c
Jeff Trawick wrote: On Tue, 26 Oct 2004 14:51:59 +0100, Ivan Ristic [EMAIL PROTECTED] wrote: Sure, you may need to have some logic to determine what makes an attack and what not, but you must have the log entry to begin with so you feed it to the algorithm. Something I'm still curious about: Was the logging with Apache 1.3 not sufficient (logging only for the timeout error)? It still seems that Apache 2 is going to be logging more than Apache 1.3, which is something that deserves a bit of scrutiny. Logging timeouts only is fine by me. Actually, I didn't realize the patch would cause logging in other cases. I mean, I am not saying that message alone will resolve all possible abuse scenarios but it certainly helps significantly. I hope to spend some time in the near future testing various DoS scenarios. You'll hear from me if there's anything interesting to tell. -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ]
Re: cvs commit: httpd-2.0/server protocol.c
[EMAIL PROTECTED] wrote: You MUST have SOMETHING that knows the difference or you don't have DOS protection. Also... if you wait all the way until you have a 'log' entry for a DOS in progress then you haven't achieved the goal of sensing them 'at the front door'. I don't set myself that goal. I agree that it's the best place to detect a DoS but it's often not possible for various reasons. With that option not available I prefer to be able to detect DoS attacks anywhere I can. What I was suggesting is some kind of 'connection' based filter that has all the well-known DOS attack scheme algorithms in place and can 'sense' when they are happening before the Server gets overloaded. That does not need to be in web server at all. It can work from within the kernel, or be a part of a network gateway. -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ]
Re: Event MPM
Paul Querna wrote: Brian Akins wrote: We are interesting in the event mpm mainly for dealing with keep alives. Yes, this is the target the Event MPM aims at :) If I understand the nature of the patch correctly then you don't need to go increasing the number of clients at all. Instead you should be looking at changing ab to pause for a few seconds between every two requests carried out over the same connection. With that change, and limiting the maximum number of processes to, say, 100, you should be able to obtain meaningful results with your current setup. Worker MPM will max out at some point, with Event MPM going past it to max at a higher value. -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ]
Re: readTrivial enhancement request
Perhaps I don't understand the request, but wouldn't it be straightforward for a module like mod_security to implement this feature by using one of the connection hooks, perhaps create_connection? Or even by registering an input filter at the beginning of the chain? I don't know. I haven't attempted to solve the problem that way yet, mostly because I feel the feature is important enough to exist without users having to install additional modules. That, and it exists in Apache 1.3.x. In the meantime, I have found where to add one line of the code to make this feature happen. I'll submit a patch for it some time in the near future. -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ]
readTrivial enhancement request
[ The request is trivial to implement (at least I think so), but the feature itself is very important. ] If one connects to Apache 1.3.x and just sits on the connection, it gets disconnected after a while and a message is written to the error log: [info] [client 127.0.0.1] read request line timed out This does not happen with Apache 2.0.x. That is very unfortunate, since the message can be used to detect subtle denial of service attacks against Apache. And, after the detection, makes it much easier to figure out where the attacker is coming from. Would someone put the message back in, please? -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ]
Re: Username logging in Form-Based (Custom) authentication
Is there a module / or a development effort that allows to log form-based authentication (field j_username) i.e. username in standard apache log files? Not to the standard log files, but close. With mod_security (http://www.modsecurity.org), you can log POST requests to a separate log file. I am toying with the idea to trick the server into logging POST data as a QUERY_STRING, but I'm not quite sure how that would work. If anyone cares to comment, I'd gladly listen. I also plan to include functionality to sanitize parameters selectively, to avoid having sensitive stuff (passwords, CC details) in the log. -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ]
Re: Proposal: Allow ServerTokens to specify Server header completely
Jim Jagielski wrote: I'd like to get some sort of feedback concerning the idea of having ServerTokens not only adjust what Apache sends in the Server header, but also allow the directive to fully set that info. For example: ServerTokens Set Aporche/3.5 would cause Apache to send Aporche/3.5 as the Server header. Some people want to be able to totally obscure the server type. I like the idea. Right now you either have to change the source code or use mod_security to achieve this, but I think the feature belongs to the server core. But I think a new server directive is a better solution. ... BTW, I've recently joined the [EMAIL PROTECTED] mailing list to observe how things are done here. In the long run, I would like to start contributing to the Apache web server, on the security side of things. I've been doing this from the outside with the mod_security module, but there are some things that are better done from the inside. -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ]
Re: Proposal: Allow ServerTokens to specify Server header completely
I like the idea. Right now you either have to change the source code or use mod_security to achieve this, but I think the feature belongs to the server core. But I think a new server directive is a better solution. As Lars said (and I agree), it has nothing to do with security. Why do you provide such a feature then? Because I believe that changing the signature prevents some automated tools from attacking the server. I recently changed the signature of the Apache running on modsecurity.org (to pretend to be IIS5). As a result, I've started getting more IIS-related attacks than before. So, the signature does matter. -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ]
Re: Proposal: Allow ServerTokens to specify Server header completely
I recently changed the signature of the Apache running on modsecurity.org (to pretend to be IIS5). As a result, I've started getting more IIS-related attacks than before. So, the signature does matter. And what was the security advantage? Smaller number of attack attempts made specifically against my configuration. Would-be attackers going somewhere else to play. Also, imagine I have a PHP application (I chose PHP because it runs on Windows and on Unix), and that someone is trying to find a hole in the app. If they think I'm running Windows they'll try to run Windows-specific attempts, completely missing the point (I know about OS fingerprinting but a typical Web attacker doesn't). Changing the server signature is a small benefit, but one of many you can have. But, at the end of the day, I think sysadmins should be the ones making the decision, with programmers giving them... rope :) -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ]
check_forensic not working with GNU xargs?
I've installed mod_log_forensic to test (from the CVS, 1.3 branch) but the shell script check_forensic does not work for me. It fails because the xargs binary does not implement the -I placeholder parameter. Checked on RH, Suse and Cygwin, all running the GNU version of xargs. On which platforms does it work? -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ]
Re: check_forensic not working with GNU xargs?
Checked on RH, Suse and Cygwin, all running the GNU version
of xargs. On which platforms does it work?
Works for me on FreeBSD and OS X and would work with -i on RH8.0's GNU
version of xargs.
You're right, I missed that. After replacing -I xx with -ixx the
script works fine.
However, the module seems to write three log entries (two before and
one after) for requests with redirects, ie GET /. I've attached a
small patch that fixes the issue for me.
BTW, I don't know if it makes any difference but I'm testing
mod_log_forensic from an Apache 1.3.29 source tree.
--
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]
--- mod_log_forensic.c.orig Tue Jan 13 22:22:00 2004
+++ mod_log_forensic.c Tue Jan 13 22:22:19 2004
@@ -221,6 +221,8 @@
if (cfg-fd 0)
return DECLINED;
+
+if (r-prev != NULL) return DECLINED;
if (!(id = ap_table_get(r-subprocess_env, UNIQUE_ID))) {
/* we make the assumption that we can't go through all the PIDs in
Re: [apache-modules] Spam Using SMTP Over HTTP-Proxy
Eli Marmor wrote: Hi, ... It is VERY easy for mod_proxy of Apache to recognize such sessions and block them. Before I'm starting such a project, I'd like to know: 1. Is there any existing code and/or module that implements this? 2. Is there any plan to add this to Apache / mod_proxy? My plan will take a long time... 3. Is there anything that can be learned from other proxies (e.g Squid) regarding this issue? 4. Can anybody add anything to the details that I wrote or has anything else to contribute to the effort? Well, of the top of my head, you can stop this spam with mod_security and this line (just a crude filter, there are probably other better and more effective ways to do it): SecFilterSelective REQUEST_URI :25 But I would say that it would be better to change mod_proxy to block such requests by default. People who are likely to install and use mod_security are unlikely to have their proxies widely open like this. -- ModSecurity (http://www.modsecurity.org) [ Open source IDS for Web applications ]
