I have SVN configured thru Apache 2.4.18 on Linux 6.6. Next i have to disable cross frame scripting for my svn url. SVN url is like https://servername/svn/projectA. I have compiled mod_security2.so and copied to /modules directory and loaded then in virtualHost have the lines below.
LoadFile /usr/lib64/libxml2.so
LoadFile /usr/lib64/liblua-5.1.so
LoadModule security2_module modules/mod_security2.so
httpd-vhosts.conf
<VirtualHost *:80>
ServerAdmin email#domain.com
DocumentRoot "/var/local/apache/httpd2.4.18/htdocs"
ServerName servername.fqdn.com
# For http to https redirect
Redirect / https://servername
TraceEnable off
RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* - [F]
SecRuleEngine On
#SecFilterEngine On
#SecFilterForceByteRange 32 126
#SecFilterScanPOST On
#SecFilter "<( |\n)*script"
SecRequestBodyAccess On
SecResponseBodyAccess On
ErrorLog "logs/error_log"
CustomLog "logs/access_log" common
</VirtualHost>
The rules that Apache not supported are
SecFilterEngine
SecFilterForceByteRange
SecFilterScanPOST
SecFilter
Blockquote
Instead of SecFilterEngine, its taking SecRuleEngine. But I do not know alternative rule for other rules. I am using modsecurity-2.9.0 source compiled. The error i see is below. [root#server extra]# /var/local/apache/httpd2.4.18/bin/apachectl configtest
AH00526: Syntax error on line 45 of /var/local/apache/httpd2.4.18/conf/extra/httpd-vhosts.conf:
Invalid command 'SecFilterForceByteRange', perhaps misspelled or defined by a module not included in the server configuration. Any one know the mod_security2 supported modules for SecFilterForceByteRange, SecFilterScanPOST and SecFilter. I also read documentation about mod_security but could not figure out and solve the issue. I followed the url below.
http://www.unixpearls.com/how-to-block-xss-vulnerability-cross-site-scripting-in-apache-2-2-x/
[EDIT]
Its solved by adding the header response.
All those unsupported commands are ModSecurity v1 commands and have been completely rewritten for ModSecurity2.
The rule you would want would be something like this:
SecRule ARGS "<( |\n)*script" "phase:2,id:1234,deny"
This basically scans any of your arguments (as parameters or the body) for items like this:
<script
or
< script
or
<
script
That's not a bad start to trying to protect for XSS but is a bit basic.
OWASP has a Core Rule Set of ModSecurity rules and their XSS rules are much more complex and can be seen here: https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/master/base_rules/modsecurity_crs_41_xss_attacks.conf
XSS can be exploited in a number of ways, some of which will make it to your server (and this sort of thing might catch) and some which might not even make it to your server at all (and so which this can't protect against).
The best way to protect against XSS is to look at Content Security Policy, which allows you to explicitly say what javascript you want to allow on your site, and what not, and to explicitly deny in-line scripts if you want. This may require some clean up of your site to remove inline scripts and is not always the easiest to set up, particularly if loading third party assets and widgets on your site, but is the most robust protection.
The X-Frame-Options header is useful to stop your site being framed, and someone overlaying content to make you think you are clicking on the real site buttons and fields, but actually clicking their buttons. It's not really a form of XSS, since you are more putting scripting on an invisible window on top of your site rather than directly on your site, but can have similar effects. It's a good header to use.
Related
My local development web server has all my different project folders, for example:
https://localhost/project1
https://localhost/project2
Due to dynamic content, some of my projects require absolute links, such as /images/example.jpg - when they are uploaded to my web server, under their appropriate domain they work perfectly, for example domain.com/images/example.jpg
However on my local server they do not, because they point to localhost/images/example.jpg (obviously), however I need the root directory to be viewed as ./project1 so I need the link to be interpreted as localhost/project1/images/example.jpg
My current solution is I have this in my root .htaccess file:
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.+)$ /project1/$1 [L,QSA]
However this only lets me rewrite the links for one dynamic project folder at a time, which is problematic if I want to jump between projects.
How can I do this from .htaccess in the project folder so I can develop on my local server with ease without having to switch directories in the root .htaccess file?
Edit: with the help from arkascha I want to further clarify my question:
With .htaccess I would like to check if a file/directory is existent in the root directory (as seen in my example), if is not, I would like it to look for the file in the directory of the referrer (the first directory after root).
Based on your comments to the question this probably is what you are looking for:
RewriteEngine on
RewriteCond %{HTTP_REFERER} ^https://[^/]+/([^/]+)/
RewriteRule ^/?images/ /%1%{REQUEST_URI} [END]
You can implement such rules in the http server's host configuration, or, if you have no access to that, you can use a distributed configuration file (".htaccess"), if you have enabled the consideration of such for that http host ...
Considering the clarification you made in your question after I offered my first answer, I would like to bring my first suggestions to notice again: using different host names. To me this sounds like the more promising approach to your situation.
You can use different hostnames locally without much effort. And if this only is about your local development environment anyway, then you also don't need to care about valid ssl certificates.
You just need to take care that a name resolution for such host name succeeds. All operating systems offer means for that, but the details obviously differ slightly. Unless you made really surprising changes to your local name resolution setup you should have a "hosts" file in your system where local host names can be registered in a static manner along with the address those names should get resolved to. That is effective, easy to setup and solves your issue.
Given that you can define a local host for each of your projects. Thus requesting these hosts just like your projects would get requested in production. This way your development setup stays much closer to the actual production setup you implement your projects for.
This would be an example for such a "hosts" file, here on taken from a typical Linux based system:
# Host addresses
127.0.0.1 localhost
127.0.1.1 bragi
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
You can simply add entries there using any plain text editor, for example you could append:
127.0.0.1 project1
127.0.0.1 project2
All that is left is to setup separate virtual hosts for those projects inside your http server:
<VirtualHost *:80>
ServerName project1
LogLevel notice
ErrorLog ${APACHE_LOG_DIR}/project1/error.log
CustomLog ${APACHE_LOG_DIR}/project1/access.log combined
DocumentRoot /var/www/hosts/project1
<Directory /var/www/hosts/project1>
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
<VirtualHost *:80>
ServerName project2
LogLevel notice
ErrorLog ${APACHE_LOG_DIR}/project2/error.log
CustomLog ${APACHE_LOG_DIR}/project2/access.log combined
DocumentRoot /var/www/hosts/project2
<Directory /var/www/hosts/project2>
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
That is all you need to request your local http server using different host names for different projects:
http://project1/foo
http://project2/bar
You could even use the https protocol locally using a snake oil certificate, you'd have to accept that certificate once for every project then in the browser used for testing.
The bottom line:
You use a host name per project, just as you do in production. This keeps your local development setup much closer to the actual production setup. You don't need any fancy rewriting rules.
I personally chose to include common, repeated configuration options for those virtual hosts in a shared configuration file I include in those host definitions above. But that is a question of personal choice, there are endless options, obviously. The documentation of the apache http server and all its glorious modules will answer all questions about that. That documentation is of excellent quality and comes with great examples, as typical for OpenSource projects.
I have a localhost on ubuntu 16. In the root localhost directory (/var/www/html/) i put this htaccess file.
AddDefaultCharset utf-8
RewriteEngine on
RewriteRule ^index?$ index.php
When I type localhost/index apache says me
The requested URL /index was not found on this server.
Is that an error in Apache configuration?
Basicly I want to make redirects to index.php in the root of my site and here I want to parse something like this localhost/cart/item/1 to array and then realize MVC. I am new in web dev and do not realy understand how can I do it, please help me.
You have to enable the interpretation of such dynamic configuration files (".htaccess" style files) first. They are disabled by default, since they slow down the server considerably. Usually it is preferable to place such rules directly in the servers static configuration files.
To enable them take a look at the AllowOverride command: https://httpd.apache.org/docs/2.4/mod/core.html#allowoverride
<Directory "/var/www/html">
AllowOverride All
</Directory>
So since you have to modify that configuration anyway... why don't you place your rewrite rules in there too? Easier, more robust and faster too...
Apart from that it sometimes is a good idea to implement rewrite rules in such way that they work in both locations, the http servers (virtual) host configuration and dynamic configuration files:
RewriteEngine on
RewriteRule ^/?index/?$ index.php [L]
And a general hint: you should always prefer to place such rules inside the http servers host configuration instead of using dynamic configuration files (".htaccess"). Those files are notoriously error prone, hard to debug and they really slow down the server. They are only provided as a last option for situations where you do not have control over the host configuration (read: really cheap hosting service providers) or if you have an application that relies on writing its own rewrite rules (which is an obvious security nightmare).
Maybe you need to create a folder, and then, work in your application inside there. Ex:
Create a var/www/html/project;
Put yout .htaccess inside;
Work with your application inside that folder.
We have a situation where ideally we would like a user to access a page on our site at a URL such as https://example.com/path/to/page. However, the HTML to render that page is sitting on an entirely different server (S3 to be exact) that we have control over, and we would like to render that page for that URL without redirecting (i.e. changing the URL itself).
I took a brief look at the Apache mod_proxy module, but it doesn't seem to do the job as we just get 500 or 404 errors. Here is an example entry from our .htaccess:
<IfModule mod_proxy.c>
RewriteRule "/path/to/page/(.*)$" "https://bucketname.s3-website-eu-west-1.amazonaws.com/path/to/page/$1" [P]
</IfModule>
Any help or a pointer in the right direction would be appreciated.
Most likely you stumble over the fact that you are using an absolute path inside a dynamic cohnfiguration files RewriteRule. Have a try with that instead:
RewriteEngine on
RewriteRule "/?path/to/page/(.*)$" "https://bucketname.s3-website-eu-west-1.amazonaws.com/path/to/page/$1" [P]
That slightly modified will work in dynamic configuration files and in the real http servers host configuration.
But as mentioned in the comment I wonder why you should not be able to use the proxy module directly to simplify things. You'd have to do that in in http servers host configuration though, this is not possible in dynamic configuration files:
ProxyRequests off
ProxyPass "/path/to/page/" "https://bucketname.s3-website-eu-west-1.amazonaws.com/path/to/page/"
ProxyPassReverse "/path/to/page/" "https://bucketname.s3-website-eu-west-1.amazonaws.com/path/to/page/"
And a general hint: you should always prefer to place such rules inside the http servers host configuration instead of using dynamic configuration files (".htaccess"). Those files are notoriously error prone, hard to debug and they really slow down the server. They are only provided as a last option for situations where you do not have control over the host configuration (read: really cheap hosting service providers) or if you have an application that relies on writing its own rewrite rules (which is an obvious security nightmare).
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
I am trying to fix this whole day without success, so I hope someone might be able to help me. I have an app at http://localhost/, and it uses Pylons for the app I am hosting. In addition to that, I need to host a PHP/MySQL site, so I had to use Apache too.
My current setup is that I use haproxy with this config for the Apache backend:
backend apache
mode http
timeout connect 4000
timeout server 30000
timeout queue 60000
balance roundrobin
server app02-8002 localhost:8002 maxconn 1000
This is triggered by this:
acl image url_sub images
use_backend apache if image
So, when I open my IP/images, it will trigger that and open Apache then, with port 8002.
For Apache, I created virtual hosts, and this is the "image" one:
<VirtualHost *:8002>
ServerAdmin my#email.com
ServerName image
ServerAlias image
DocumentRoot /srv/www/image/public_html/
ErrorLog /srv/www/image/logs/error.log
CustomLog /srv/www/image/logs/access.log combined
</VirtualHost>
So, that all works nicely, when I type IP/images it open the /srv/www/image/public_html. But then the issues come. As I am using the image uploading script, it involves a lot of rewriting, so I had to enable that mod. This is the .htaccess which is located in the public_html/images folder (I somehow had to make this subfolder too, to "match" the URL with the actual location in the public_html.
SetEnv PHP_VER 5_3
RewriteEngine On
# You must define your installation directory and uncomment the line :
RewriteBase /images/
RewriteRule ^([a-zA-Z]+)\.(jpg|gif|png|wbmp)$ controller/Resizer.php?m=original&a=$1&e=$2 [L]
RewriteRule ^(icon|small|medium|square)\/([a-zA-Z]+)\.(jpg|gif|png|wbmp)$ controller/Resizer.php?m=$1&a=$2&e=$3 [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule (.*) application.php?request=$1 [L,QSA]
So, basically, this is somethow not working. I suppose there is a conflict between this virtual host, subdirectory, rewriting or something, but I can't seem to isolate it.
It is a bit confusing that when I open the IP/images/xxxx.jpg it opens the image, which is located in the public_html/images/upload/original folder, so the rewrite is working. The the other rules seem not to be working. All of the thumbnails and smaller versions are not rendering properly (with the icon, small, medium, square), so that makes the site quite unsusable.
Here is the link of the development server: http://localhost/images/
Thanks in advance for your time and help!
The first thing you should do is determine whether mod_rewrite is in fact part of the problem by accessing one of the failing URLs directly via its rewritten form and verifying that you get the expected result.
Indeed, the problem might simply be that the PHP script for the smaller resolutions "doesn't work" while it does for the original size ones. The first of the following URLs nicely served me an image; the second one is supposed to give me a smaller version of the same image, but served me an HTTP 500:
http://106.186.21.176/images/controller/Resizer.php?m=original&a=q&e=png
http://106.186.21.176/images/controller/Resizer.php?m=small&a=q&e=png
I got the same result (HTTP 500) for any of the smaller-size format names mentioned in your post, which matches your problem description.
Once you've verified that the script works as expected, it's likely that the problem is with mod_rewrite. If so, enable rewrite logging: use the RewriteLog directive to activate it, and RewriteLogLevel to control its verbosity. Especially at the higher log levels, it can give you very detailed information about exactly what it's doing. This should make the problem readily apparent from the logs.
Also, if possible, try to avoid configuring mod_rewrite rules in .htaccess files -- move them into your main server config file instead. The reason is explained on Apache mod_rewrite Technical Details, section "API phases":
Unbelievably mod_rewrite provides URL manipulations in per-directory context, i.e., within .htaccess files, although these are reached a very long time after the URLs have been translated to filenames. It has to be this way because .htaccess files live in the filesystem, so processing has already reached this stage. In other words: According to the API phases at this time it is too late for any URL manipulations. To overcome this chicken and egg problem mod_rewrite uses a trick: When you manipulate a URL/filename in per-directory context mod_rewrite first rewrites the filename back to its corresponding URL (which is usually impossible, but see the RewriteBase directive below for the trick to achieve this) and then initiates a new internal sub-request with the new URL. This restarts processing of the API phases.
Again mod_rewrite tries hard to make this complicated step totally transparent to the user, but you should remember here: While URL manipulations in per-server context are really fast and efficient, per-directory rewrites are slow and inefficient due to this chicken and egg problem. But on the other hand this is the only way mod_rewrite can provide (locally restricted) URL manipulations to the average user.
In general, not using .htaccess at all has the added advantage that you can tell Apache to not even bother and disable the functionality all together, which save Apache from having to scan each directory level it serves from for the .htaccess files.