I'm working with Apache 2.4.2 and I need to change the LimitRequestFieldSize. supposedly (according to some Google researchs) that can be done in the httpd.conf file but I cant find that LimitRequestFieldSize neither the httpd.conf or any file within the Apache. Have any idea how I can do it?
In the end I solved simply adding LimitRequestFieldSize 500000 to the file httpd-default.conf
What you just did is open the door to a DoS attack.
Take a look at the LimitRequestFieldSize directive in the Apache documentation:
Quoting from that source:
This directive specifies the number of bytes that will be allowed in
an HTTP request header.
The LimitRequestFieldSize directive allows the server administrator to
set the limit on the allowed size of an HTTP request header field. A
server needs this value to be large enough to hold any one header
field from a normal client request. The size of a normal request
header field will vary greatly among different client implementations,
often depending upon the extent to which a user has configured their
browser to support detailed content negotiation. SPNEGO authentication
headers can be up to 12392 bytes.
This directive gives the server administrator greater control over
abnormal client request behavior, which may be useful for avoiding
some forms of denial-of-service attacks.
The documentation also specifies that the context of that directive is server config (which means server-wide) and virtual host (you can apply this directive on a per-vhost basis).
In addition, you do not mention what your OS is. In case it's Linux (which I'm more familiar with):
The configuration file, httpd.conf, is found in /etc/httpd/conf/httpd.conf (RHEL, CentOS, Fedora, Scientific Linux).
In Debian, and derivatives like Ubuntu (I don't think that is the case here, but I am mentioning it anyway just for the record), the configuration file is apache2.conf and can be found in /etc/apache2/apache2.conf.
Hope it helps.
And last but not least, you may want to check out the Unix and Linux Q&A here in StackExchange for questions like this (assuming Linux or other *Nix OS). You may have better luck at getting an answer.
This issue can be solved by updating the directive LimitRequestFieldSize either in the apache httpd.conf or in the virtual hosts.
How to add the prop in the virtual host
<VirtualHost 10.10.50.50:80>
ServerName www.mysite.com
LimitRequestFieldSize 16384
RewriteEngine On
...
...
</VirtualHost>
How to add in the httpd.conf which is inside , apache2/conf/httpd.conf
LimitRequestFieldSize 16384
But even after doing this i am still getting bad request error.
Related
I just know this is one of those questions where the solution should have been obvious and I'm going to feel like an idiot but I'm stuck.
I've set up a basic apache2 web sever under openSUSE Leap 15.1 on my LAN with a single virtual host (for the moment).
If I create a simple html file of 255 bytes or less a browser on another workstation picks it up without problem. If the file gets to anything larger than 255 bytes apache doesn't serve it. The GET request shows up on the server but nothing shows in Firefox, Konqueror at least gives me a 1b Object not found error.
I should say that running a browser on the server itself shows all these files perfectly well should I use 127.0.0.1, localhost or the server name in the URL.
Is this an Apache2 directive I've missed or something else entirely?
After setting the LogLevel to trace1 and then hunting around on the web I came across what appears to be the solution. Set the Apache directive ...
EnableSendfile Off
Apparently Apache is compiled with this set to On and the kernel sendfile doesn't do the job. Not a detailed explanation I know but I haven't followed this all the way through - I just needed to get Apache working!
I've been trying to set up:
Require forward-dns somehostname.mydns.rocks
to prevent access to a sandbox except for devs. I can't use IPs, since they aren't static, and in theory the forward-dns directive is exactly what I need (used along with a dnynamic dns hostnames of the client machines)
But when I try to use the "Require forward-dns somehostname.mydns.rocks" directive, apache spits out:
.htaccess: Unknown Authz provider: forward-dns"
I feel like Im missing some required step that isn't clear in the docs to get forward-dns working (apache 2.4.6 on centos 7)
P.S. the Require host directive works, and since the host directive first does a reverse dns, followed by a forward dnslookup on the results of the reverse dns lookup, I wold expect forward-dns to just work.
What step could I be missing here?
https://httpd.apache.org/docs/current/en/mod/mod_authz_host.html
says:
The forward-dns provider was addded in 2.4.19
Your apache Version 2.4.6 is too old. Try updating to a newer version.
I'm using mod_proxy_fcgi with apache 2.4 on a debian Jessie with my C++ application which does ServerSentEvents with libfcgipp.
My problem is, that apache still buffers my response data. I confirmed that it isn't buffered by the libfcgipp library by using wireshark: After starting the fcgi application via spawn-fcgi, the data gets send to the apache web server as soon as possible. But in my browser (which I use for testing, later there will be a C++ client) it only shows up after I "killed"/closed the sending request in the server application.
So I assume I need to disable buffering for either apache or mod_proxy_fcgi (or both). But I cannot find the appropriate documentation on how to do this.
As the result of a subsequent discussion on the httpd-dev mailing list, support for flushpackets and flushwait was added to mod_proxy_fcgi in r1802040 and backported for Apache 2.4.31 in r1825765. If you are using Apache 2.4.31 or later, you can disable buffering using <Proxy flushpackets=on> as described in the BigPipe documentation:
<FilesMatch "\.php$">
# Note: The only part that varies is /path/to/app.sock
SetHandler "proxy:unix:/path/to/app.sock|fcgi://localhost/"
</FilesMatch>
# Define a matching worker.
# The part that is matched to the SetHandler is the part that
# follows the pipe. If you need to distinguish, "localhost; can
# be anything unique.
<Proxy "fcgi://localhost/" enablereuse=on flushpackets=on max=10>
</Proxy>
Note: flushpackets and flushwait are currently only included in the Apache mod_proxy_fcgi documentation for trunk because r1808129 has not been backported to the 2.4.x branch.
A few notes, since I just spent the past few hours experimenting to find the answer to this question:
It's not possible to entirely disable output buffering when using mod_proxy/mod_proxy_fcgi, however, you can still have responses streamed in chunks.
It seems, based on my experimentation, that chunks have to be at least 4096 bytes before the output will be flushed to the browser.
You can disable output buffering with the mod_fastcgi or mod_fcgi module, but those mods aren't as popular/widely used with Apache 2.4.
If you have mod_deflate enabled and don't set SetEnv no-gzip 1 for the virtualhost/directory/etc. that's streaming data, then gzip will not allow the buffer to flush until the request is complete.
I was testing things out to see how to best use Drupal 8's new BigPipe functionality for streaming requests to the client, and I posted some more notes in this GitHub issue.
I'm looking for an easy way to blacklist IP addresses in Apache 2.4.x. My web site logs ip addresses that tried illegal operations into a text file. I would like to use this text file within Apache to deny all access to all vhosts to this ip list. What would be the best way (easiest and least resource consuming way) ?
Found this but this is only for 2.2.. Not sure how this applies to 2.4..
Cheers.
edit: this is a windows x64 box running apache x64
#vastlysuperiorman called it right, csf/lfd is the best at this. Unfortunately, they only run on linux.
This free utility promises to provide the same functionality: dynamically monitor access attempts and auto-block IP addresses. You can unblock with a command, in case of false positives. Certainly worth a short.
An alternative could be to create a VM (if your platform supports virtualization) deploy a very small spec linux box, and use that as a proxy. This should be easy to implement. BTW, why not just use linux? .. :-)
(this should have been a comment on #vastlysuperiorman's post, but I don't have enough SO reps to comment on the post of others)
Edited to suggest a possible apache 2.4 based solution:
To translate ACL directives between the 2.2 and 2.4 in apache
2.2 Syntax
order Deny,Allow
include conf/IPList.conf
Allow from all
2.4 Syntax
DocumentRoot /some/local/dir
<Directory /some/local/dir/>
<RequireAll>
Require all granted
Include conf/IPList.conf
</RequireAll>
</Directory>
#this will also work
<Location />
<RequireAll>
Require all granted
Include conf/IPList.conf
</RequireAll>
</Directory>
# conf/IPLIst.com is actually in /etc/apache2/conf/IPList.conf
# (ie, paths are relative to where apache is installed.
# I guess you can also use the full path to the list.
And inside conf/IPList.conf, you will have individual lines with entries like the following
Require not ip 10.10.1.23
Require not ip 192.168.22.199
Require not ip 10.20.70.100
Using mod-rewrite and a list of IPs for banning
For a redirect-to-another-page to work, you need to keep the RewriteRule outside the base URL you are guarding.
For instance, the redirect would not work under a Directory directive on DocumentRoot or a Location directive on '/', because the ban affects the status page we want to display.
So, best to keep this outside a Directory or Location directive, or link to a status page on another unprotected web server.
#Required set of rewrite rules
RewriteEngine on
RewriteMap hosts-deny txt:/etc/apache/banned-hosts
RewriteCond ${hosts-deny:%{REMOTE_ADDR}|NOT-FOUND} !=NOT-FOUND [OR]
RewriteCond ${hosts-deny:%{REMOTE_HOST}|NOT-FOUND} !=NOT-FOUND
RewriteRule ^ /why-am-i-banned.html
## inside our banned hosts file, we have:
## /etc/apache2/banned-hosts (maintain the format .. its not just a plain text file)
##
193.102.180.41 -
192.168.111.45 -
www.example.com -
www.sumwia.net -
# inside our status page, could be html as below or a plain text file with '.txt' extension
#/var/www/html/why-am-i-banned.html
#
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Why is my IP banned?</title>
</head>
<body>
<h2>Why is my IP address banned?</h2>
<p>
To manage spammers and for other security needs, our server automatically blocks
suspicious IP address. If however you reckon your IP address has been blocked
wrongfully, please contact us.
</p>
</body>
</html>
And of course, you can parse your log files and populate conf/IPList.conf or /etc/apache2/banned-hosts as appropriate ..
As a short term solution
An alternative that will allow you to use the 2.2 syntax, is to install mod_access_compat module and continue using your deprecated 2.2 style 'Deny,Allow' directives. But this is only advisable as a short-term solution since that module is just there to aid transition, and would probably go away in future versions of apache 2.4
I too have not seen a good alternative for blocking access dynamically from within Apache itself. There are "hacky" ways: you could set an environment variable to contain a list of IPs and then use the module with ${REMOTE_ADDR} and the env function, but that's a stretch. Details on the Expression Parser
However, I have used several light weight modules that are helpful in protecting your Apache server.
ConfigServer Firewall (CSF/LFD) is a great solution for linux systems. It provides a simple method for managing iptables, and can be set up to do brute force detection and blocking. Info here
EDIT:
Add the following line to /etc/csf/csf.deny to include your custom IP block list:
Include /var/www/example.deny
Alternately, update your script to append IP addresses to csf.deny either directly:
echo $badIP >> /etc/csf/csf.deny
or using the CSF command line option (preferred):
csf -d 10.20.30.40
CSF readme here
mod_security is one of my favorite Apache/nginx modules. It detects dangerous GET and POST requests and blocks access accordingly. When set up properly, it will trigger CSF to block the IP addresses that frequently violate rules. Details here
so far I developed completey locally, having everything (Apache, Openfire, JSJaC application) on my laptop, running quite fine. Now I want to use remote server for Apache/Openfire. I did basically the same steps, incl. the whole http-bind stuff. I test the setting with simpleclient.html provided by JSJaC.
Now here's the deal, if I use the simpleclient directly on the remote server - e.g., http://here.domain.org/simpleclient.html - it works. If I use it locally - e.g., http://[local_machine]/simpleclient.html - and with the same settings I get an 503 (service unavailable). It seems to be more a network/Apache issue than Openfire/JSJaC one, but I'm not an expert.
My parameters for the simpleclient:
HTTP Base: http://here.domain.org/http-bind/
JabberServer: here.domain.org
So in my apache virtual host conf file I have the lines:
AddDefaultCharset UTF-8
ProxyReqests On
ProxyPass /http-bind/ http://127.0.0.1:7070/http-bind/
So basically the http bind works since I can connect when the simpleclient.html resides on the server. What I tried so far:
checked if 7070 open from extern: yes
checked etc/hosts - here the relevant lines
127.0.0.1 localhost
123.123.123.123 here.domain.org here
checked Apache conf for restrictions: can't find any, basically i have an "Allow from all" everywhere (but I'm not completely sure where to look at)
By the way, with,e.g., Pidgin I can connect from my laptop to the remote server. Just the JSJaC simpleclient won't do. So I assume it's the http-bind that causes the trouble. I would understand if port 7070 weren't open, but it is.
Any hints or help are much appreciated!
Christian
Ok, I got it. It was a cross-domain scripting issue. I started looking into the JSJaC library and noticed that it makes XmlHttpRequests which by default won't work across different domains. I therefore had to allow this with Apache on the Openfire-Server. I added the follwing entries in the VirtualHost conf file:
Header always set Access-Control-Allow-Origin "*"
Header always set Access-Control-Methods "POST, GET, OPTIIONS"
Header always set Access-Control-Allow-Credentials true
Header always set Access-Control-Allow-Headers "Content-Type, *"
Of course the mod_headers module must be loaded for this.
I'm not sure which entries are actually required, I didn't try every combinations. I think the always is needed since the request to the http-bind address is a proxy thingy.