24 Nov 15 HTTP request header from a query string parameter on apache reverse proxy

Suppose you have a apache httpd server working as a reverse proxy. Now suppose that this server has to set a HTTP request header called “token” to be attached to every request made to the backends, and that the header’s value must be copied from a query string parameter called “querytoken”.

This can be simply done with the help of mod_headers + mod_rewrite.

RewriteEngine On RewriteCond %{QUERY_STRING} (?:^|&)querytoken=([^&]+) RewriteRule (.*) - [E=QS_TOKEN:%1]

RequestHeader set token %{QS_TOKEN}e env=QS_TOKEN ProxyPass / http://your_backend/

Will your external client make a request like this:

GET /?querytoken=somestuff HTTP/1.0 Host: example

The request header that apache will do to the backend will be something like this:

GET /?token=somestuff HTTP/1.1 Host: 127.0.0.1:1234 token: somestuff X-Forwarded-For: 127.0.0.1 X-Forwarded-Host: example X-Forwarded-Server: myserver.linux Connection: Keep-Alive

The request header “token” with value “somestuff” is added to the request made to the backend.

Tags: apache, http, https, Linux, proxy, relaying, server, sysadmin
Filed in Linux OS, Open source, Sysadmin pills with 0 Comments

27 Ago 14 Squid: how to get rid of “All url_rewriter processes are busy”

If you check your squid forward (transparent or not) proxy log files you may found errors like those:

WARNING: All url_rewriter processes are busy.
WARNING: up to 6 pending requests queued

This is true if you use the directive “url_rewrite_program”, for example with SquidGuard.
In this case, squid tells you that it cannot spawn more helper processes to externally scan your requests in parallel, so it’s queuing your requests.
This is not a great problem, but you may be annoyed to see this stuff in your log files, or there are cases in which the default may be too low!

You may raise this limit with the parameter called url_rewrite_children.

To solve, add something like this to your squid.conf configuration file, and restart squid:

url_rewrite_children 32

Ciao, Dino.

Tags: http, Linux, proxy, server, squid, sysadmin
Filed in Linux OS, Open source, Sysadmin pills with 0 Comments

21 Ago 14 How to enable apache NameVirtualHost with SSL

If you want to create name based virtualhosts in apache with SSL Certificates, you need openssl with SNI and TLS support (0.9.8f or better) and good apache 2.2.X version.

It’s a simple task, after you’ve read this official article: https://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI

Tags: apache, http, https, Linux, openssl, proxy, server, sysadmin
Filed in Linux OS, Open source, Sysadmin pills with 0 Comments

13 Nov 13 Apache HTTPD as 2WAY (mutual) authentication SSL reverse proxy balancer

In this small article I’ll instruct myself (and you too?) how to create a 2 way authentication (mutual authentication) SSL reverse proxy balancer gateway. This configuration is useful in any enterprise environment where it’s requested to separate clients, the frontend and the backend, and when the traffic between clients and the gateway, and between the gateway and the backends must be encrypted.
This also ensure the clients and the backends to be authentic, and avoids Man In The Middle attacks.

Since the reverse proxy is in the middle between the clients and the backends, it’s requested for the clients to send a known client certificate to the gateway (apache), so that the gateway can recognize them. This is done with X509 certificates.
For the same reason, each backend contacted by the gateway is requested to respond with a valid and known server certificate. This is also done with X509 certificates.
Generally, the clients and the backends will also check their peer’s (apache) certificate to be known and valid, so that if someone is going to impersonate the gateway, it will be found and will not be considered authentic.

To do so, we’ll use:

apache httpd
mod_ssl
mod_proxy_balancer + mod_proxy + mod_proxy_http

Everything is done with a simple and single virtualhost in apache to be included in httpd.conf.
A working example is given below (assumes apache to be installed in /opt/apache, working with IP 11.22.33.44 on port 443):

<VirtualHost 11.22.33.44:443>
# General setup for the virtual host
DocumentRoot “/opt/apache/htdocs”
ServerName 11.22.33.44:443
ServerAdmin hostmaster@yoursite.com
CustomLog “|/opt/apache/bin/rotatelogs /opt/apache/logs/ssl_request_%Y%m%d.log 43200” “%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \”%r\” %b”
ErrorLog “|/opt/apache/bin/rotatelogs /opt/apache/logs/error_%Y%m%d.log 43200”
CustomLog “|/opt/apache/bin/rotatelogs /opt/apache/logs/access_%Y%m%d.log 43200” combined

# SSL CONFIGURATION – SERVER SIDE
# Enable SSL Server on this virtualhost
SSLEngine on
# Disable SSLv2 in favor of the more robust and secure SSLv3
SSLProtocol all -SSLv2
# List of supported cryptografic server cipher suites
SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5

# Apache server certificate
SSLCertificateFile “/opt/apache/conf/ssl/server.pem”
# Apache server private key
SSLCertificateKeyFile “/opt/apache/conf/ssl/key.pem”
# Apache server CA certificate (certificate of who released your server certificate)
SSLCertificateChainFile “/opt/apache/conf/ssl/ca.pem”
# Client’s CA certificates (list of certificates of who released your client’s certificates)
SSLCACertificateFile “/opt/apache/conf/ssl/ca.pem”
# It’s mandatory for apache to authenticate the client’s certificate
SSLVerifyClient require
# END OF SSL CONFIGURATION – SERVER SIDE

# SSL CONFIGURATION – CLIENT SIDE
# Enable SSL Client on this virtualhost (the traffic to the backends can be encrypted)
SSLProxyEngine on
# Apache client CA certificate (certificate of who released your client certificate)
SSLProxyMachineCertificateChainFile “/opt/apache/conf/ssl/ca.pem”
# Apache client private key + client certificate (concatenated in a single file)
SSLProxyMachineCertificateFile “/opt/apache/conf/ssl/client.pem”
# Backends’ CA certificates (list of certificates of who released your backends’ certificates)
SSLProxyCACertificateFile “/opt/apache/conf/ssl/ca.pem”
# It’s mandatory for apache to authenticate the backends’ certificate
SSLProxyVerify require
# END OF SSL CONFIGURATION – CLIENT SIDE

<FilesMatch “\.(cgi|shtml|phtml|php)$”>
SSLOptions +StdEnvVars
</FilesMatch>
<Directory “/opt/apache/cgi-bin”>
SSLOptions +StdEnvVars
</Directory>

BrowserMatch “MSIE [2-5]” \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0

# Define a load balancer worker to be used to balance the HTTPS traffic to three backends.
# The traffic between apache and the backends is encrypted
<Proxy balancer://httpslb>
# Define the first backend (https) with 2 way auth
BalancerMember https://192.168.1.11:443/ route=worker1 retry=10
# Define the second backend (https) with 2 way auth
BalancerMember https://192.168.1.12:443/ route=worker2 retry=10
# Define the third backend (https) with 2 way auth
BalancerMember https://192.168.1.13:443/ route=worker3 retry=10
</Proxy>

# Don’t send the “/balancer-manager” uri to the backends
ProxyPass /balancer-manager !
# Distribute the traffic (any url, since it is “/”) to the backends with round robin + cookie based session persistence
ProxyPass / balancer://httpslb/ lbmethod=byrequests stickysession=JSESSIONID

</VirtualHost>

If the clients and the backends are configured to check the gateway (apache) certificates, this is considered to be a very secure configuration.

Enjoy!

Tags: apache, ca, cipher, cookie, debian, http, https, Linux, openssl, proxy, reverse, server, sysadmin
Filed in General, Linux OS, Open source, Sysadmin pills with 3 Comments

21 Feb 12 Mitigare attacchi di tipo Distributed Denial Of Service su apache con mod_evasive

Ciao.
C’e’ un modulo molto carino non official per apache che permette di bloccare o comunque mitigare facilmente attacchi di tipo DDOS.

Si scarica il modulo mod_evasive dal sito http://www.zdziarski.com/blog/?page_id=442, si decomprime il tar.gz e si compila con la seguente stringa:

<directory_di_installazione_apache>/bin/apxs -i -c mod_evasive20.c

Ora bisogna inserire due cosette in httpd.conf e successivamente riavviare gli apache:

1) LoadModule evasive20_module modules/mod_evasive20.so
2) La sua configurazione

Per quanto riguarda la numero 2 bisogna fare una considerazione importante, ovvero che il tuning del presente modulo con parametri errati o maldimensionati puo’ provocare dei falsi positivi che creano gravi disservizi per un periodo anche prolungato di tempo.

La configurazione e’ simile a questa (effettuo già un pre tuning che comunque dovrete ricontrollare e confermare voi che conoscete il vostro sistema):

<IfModule mod_evasive20.c>
DOSHashTableSize 196613
DOSLogDir “/tmp”

DOSPageCount 20
DOSPageInterval 10

DOSSiteCount 350
DOSSiteInterval 5

DOSBlockingPeriod 10
</IfModule>

Di seguito una breve spiegazione dei parametri:

DOSHashTableSize: e’ la dimensione della tabella di lookup interna usata dal modulo. Su server carichi il numero non deve essere troppo basso. Non andrebbe messo un numero casuale ma un numero primo presente nella struct dei numeri primi dentro mod_evasive20.c.

DOSLogDir: e’ una directory dove evasive appoggia dei dati che vengono utilizzati internamente per motivi di locking tra i processi child di apache

DOSPageCount: e’ la soglia per il numero di richieste effettuate verso una stessa url da uno stesso IP entro un determinato intervallo di tempo specificato dalla direttiva DOSPageInterval. Se il numero di richieste verso una stessa pagina/oggetto/uri viene superato nell’intervallo di tempo specificato apache blocchera’ l’IP del client per un determinato numero di secondi specificati dalla variabile DOSBlockingPeriod. Consiglio vivamente di non impostare questo parametro troppo basso per evitare falsi positivi all’interno di ambienti nattati o dietro proxy server (ad esempio clienti fastweb, utenti all’interno di grosse organizzazioni che usano un proxy server, ecc.)

DOSPageInterval: e’ l’intervallo di tempo espresso in secondi che attiva la soglia relativa al parametro precedente (DOSPageCount)

DOSSiteCount: e’ la soglia per il numero di richieste complessive verso tutto il sito effettuate da uno stesso IP entro un determinato intervallo di tempo specificato dalla direttiva DOSSiteInterval. Se il numero complessivo di richieste verso apache viene superato nell’intervallo di tempo specificato, apache blocchera’ l’IP del client per un determinato numero di secondi specificati dalla variabile DOSBlockingPeriod. Anche qui consiglio vivamente di non impostare questo parametro troppo basso per evitare falsi positivi all’interno di ambienti nattati o dietro proxy server (ad esempio clienti fastweb, utenti all’interno di grosse organizzazioni che usano un proxy server, ecc.)

DOSSiteInterval: e’ l’intervallo di tempo espresso in secondi che attiva la soglia relativa al parametro precedente (DOSSiteCount)

DOSBlockingPeriod: e’ l’intervallo di tempo espresso in secondi durante i quali tutti i client finiti in blacklist avendo superato i limiti imposti dai parametri specificati sopra non potranno collegarsi ad apache e navigare sul sito ottenendo invece un codice di errore HTTP/403 (Forbidden). Se i clients bloccati continuano ad effettuare nuove richieste durante il periodo di blocco, ogni richiesta resetta il timer percui il conteggio ricomincia. Consiglio quindi VIVAMENTE di non impostare questo parametro troppo alto, in genere non vanno mai superati i 20 secondi. Il motivo principale e’ la mitigazione di eventuali disservizi causati da falsi positivi. Il discorso e’ inoltre valido perche’ durante un attacco DDOS il timer viene continuamente resettato e l’attacco viene comunque mitigato anche impostando il parametro ad un valore molto basso.

Riavviate apache e buon divertimento.

Dino Ciuffetti.

Tags: apache, blacklist, http, Linux, policy, proxy, server, sysadmin
Filed in Linux OS, Notes, Open source, Sysadmin pills with 0 Comments

08 Mar 11 Modify JSESSIONID cookie path with apache and mod_headers

The question is: how can I change the path of the JSESSIONID cookie for a web application deployed in tomcat, jboss, or any other AS, and served by an apache reverse proxy (ProxyPass on mod_proxy, or jkMount on mod_jk) to add a trailing slash?

The answer is in mod_headers module. This module supports perl regular expression that you can use to substitute a string with another on any HTTP header, on the request or on the response.

We may want to add a trailing slash (mypath/) to the JSESSIONID cookie path, for example for security reasons.
This is the correct way (apache >= 2.2.4):
Header edit Set-Cookie "^(JSESSIONID=.*; Path=/YOUR_APP_PATH)(.*)$" "$1/$2"
eg:
Header edit Set-Cookie "^(JSESSIONID=.*; Path=/jsp-examples)(.*)$" "$1/$2"
The first attribute defines the regular expression that matches against the string that must be edited (the SESSIONID header in this case), the second attribute is the expression of the new string (the sessionid with the path modified with a trailing slash). Note that the expression begins with ‘^‘ character (it means: the string must begin with).
This kind of regexp defines that each match pattern is enclosed into brackets, so the first match is anything that begins with “JSESSIONID=”, have some kind of sub string (.*), and then contains “; Path=/jsp-examples”.
The second match is anything on the right of the path (.*).
The second argument implies that the string is composed by the first match, a slash, then the second match. So we have a cookie called JSESSIONID with a trailing slash added in the path.

If you don’t understand perl regular expression well, I advice you to get deeper into it, because it’s very very very useful for any sysadmin. There is very good documentation in internet, try to google “perl regular expression examples”.

Apache httpd is a very good and powerful piece of code, and it’s generally possible to do anything you can thinking of. You have only to know where to search, and the manual is generally the right place.

Ciao, Dino.

Tags: apache, cookie, proxy, server, sysadmin
Filed in Sysadmin pills with 0 Comments