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.
I never said before on those pages that some months ago I migrated liborient to github: liborient project page.
For those who do not know liborient, it’s a LGPLv3 library that can be used by C programs to interact with the OrientDB DBMS Server using the orientdb binary protocol. At the time of this writing it’s in development stage, but almost all low level binary protocol methods are implemented and should be quite working.
After fixing some (well known) memory leaks on the new odocument interface, I’m now working on a high level API that can be used by C programs to manipulate objects going to and coming from OrientDB Server.
You can, for example, put or get records to/from the server containing different data type fields. Those fields are organized into an object that OrientDB calls Document. This Document can include structured types like: integers, shorts, dates, strings, binary, char, float, collections, maps, documents embedded into documents, and more.
The liborient’s new odocument higher level API should make you comfortable to access and manipulate this documents.
This can be, for example, a good starting point to create native bindings for other languages like PHP, python, perl, ruby, etc.
At the moment I am the author and the only developer on this project, but if you are brave you can join and submit patches, test the code, open bugs, put your considerations, and so on. Feel free to send me a mail, add a comment to this page, write to the orientdb mailing list, send me a tweet at @tuxweb, or anything else.
The first thing that I have to say, after more than 10 years working with different OSes, is that there is no better operative system than Linux. Any other OS that I’ve worked with is a pure shit, in my humble opinion off course. HP-UX is one of this. This is a closed box with custom patches here and there, not a true, modern os like linux or free bsd, and the like. The compiler is closed source and it’s not free.
The best way that I’ve found to compile apache with gcc on HP-UX 11.11 (pa-risc) using open source free software is:
At this point, after some minute, you probably will end with a compiler error like this one:
/var/adm/crash/src/httpd-2.2.21/srclib/apr/libtool –silent –mode=link gcc -g -O2 -pthread -L/usr/local/lib -o htpasswd htpasswd.lo -lm /var/adm/crash/src/httpd-2.2.21/srclib/pcre/libpcre.la /var/adm/crash/src/httpd-2.2.21/srclib/apr-util/libaprutil-1.la /var/adm/crash/src/httpd-2.2.21/srclib/apr-util/xml/expat/libexpat.la -liconv /var/adm/crash/src/httpd-2.2.21/srclib/apr/libapr-1.la -lrt -lm -lpthread -ldld
libtool: link: warning: this platform does not like uninstalled shared libraries
libtool: link: `htpasswd’ will be relinked during installation
/usr/ccs/bin/ld: Unsatisfied symbols:
apr_generate_random_bytes (first referenced in .libs/htpasswd.o) (code)
collect2: ld returned 1 exit status
gmake[2]: *** [htpasswd] Error 1
gmake[2]: Leaving directory `/var/adm/crash/src/httpd-2.2.21/support’
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/var/adm/crash/src/httpd-2.2.21/support’
gmake: *** [all-recursive] Error 1
This means that the APR library cannot generate random numbers. I have to investigate why, probably the system is not capable/patched to generate PRN numbers at kernel level (/dev/random or /dev/urandom) and the APR library breaks. Not a problem. Simply skip the creation of the htpasswd executable. You will probably not need it.
Now came back to compile:
when finished, simple “gmake install“, and you hopefully have done, thinking why you are still using a non modern os and becoming soon a happy new linux user..
😉 Hope this one will help some linux user fighting on HP as well like me!
Ciao, Dino.
When you have to publish mainly static contents, like static sites, the most powerful solution is to configure your apache http server to use the MPM Worker, mod_mem_cache e mod_deflate modules.
Why the MPM Worker
It implements a multi process / multi thread server model. The father process spawn processes, and each child process spawn threads. Each thread will handle a client connection.
This implementation can handle a large number of requests with fewer system resources than a standard prefork multi process server model.
Please note that you cannot use the MPM Worker in server environments that are not thread safe. For example, PHP, mod_perl, and other dynamic page processors do not ensure you that the environment it’s completely thread safe, so my advice is to NOT USE the MPM Worker with PHP, mod_perl and the like.
The Worker MPM can consume much less memory because the heap memory is shared among threads, while that’s not true for processes.
For more informations you can read the official page: http://httpd.apache.org/docs/2.2/mod/worker.html
Why the mod_mem_cache module
This module can be configured to cache open file descriptors and objects into the heap storage (memory).
If the same object (html, css, js, etc) it’s requested for the first time by a client, it get saved into the heap memory. The second time it got requested, the object got feeded directly from the memory cache. It can lower down CPU and disk I/O.
For more informations you can read the official page: http://httpd.apache.org/docs/2.2/mod/mod_mem_cache.html
Why the mod_deflate module
It can allows output from your server to be compressed before being sent to the client . The HTTP 1/1 protocol has a header called Accept-Encoding. This way a client can tell the server witch response encoding it can reads.
Any modern browsers today can handle page compression, so why not using it?
With it you can save bandwidth.
For more informations you can read the official page: http://httpd.apache.org/docs/2.2/mod/mod_deflate.html
Ok. Let’s begin to enable that stuff.
First step is to compile apache from source.
If you want to use the packages released by your linux distribution instead of compiling apache by yourself you can do it.
Always choose the latest apache stable version available.
To compile apache 2.2.X with most modules in shared form (*.so) you should run this configure:
$ ./configure –prefix=<YOUR_APACHE_DIR> –with-mpm=worker –with-included-apr –with-expat=builtin –enable-mods-shared=most –enable-ssl –enable-proxy –enable-proxy-connect –enable-proxy-http –enable-proxy-balancer –enable-cache –enable-disk-cache –enable-mem-cache –enable-nonportable-atomics=yes
Then, as usual, run:
$ make
$ make install
You hopefully end up with apache correctly installed with all needed modules in place.
Now configure your httpd.conf adding those lines:
# Compress on the fly HTML pages, TXT and XML files, CSS and JS.
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/x-js application/x-javascript
# Cache open file descriptors
CacheEnable fd /
# Enable memory caching
CacheEnable mem /
# Limit the size of the cache to 24 Megabyte
MCacheSize 25165824
# Minimum size of an object that can be cached: 1 Kbyte
MCacheMinObjectSize 1024
# Maximum size of an object that can be cached: 3 Mbyte
MCacheMaxObjectSize 3145728
# Spawn 10 child processes, spawning 100 threads for each child process.
# So, a pool of 1000 threads is left up and sleeping, ready to serve incoming requests.
# If more requests will come in, apache will spawn new child processes, each one spawning 100 threads,
# enlarging the thread pool until the total number of threads become 2000. In that case, apache begin
# to cleanly drop processes, trying to reach 1000 threads.
# New processes and its threads are spawned in case of a large spike of requests, until 4000 parallel
# client requests are reached, then apache will no longer accept new incoming connections.
# When the load calm down, and requests come back under 4000 parallel connections, apache will continue
# to accept connections. After 1,000,000 requests served by a child, q. 10,000 per thread, the process
# get closed by the father to ensure no memory leak is fired.
<IfModule mpm_worker_module>
ThreadLimit 100
ServerLimit 4000
StartServers 10
MaxClients 4000
MinSpareThreads 1000
MaxSpareThreads 2000
ThreadsPerChild 100
MaxRequestsPerChild 1000000
</IfModule>
Start apache.
Enjoy!!
The Apache Tomcat Native module, also called “TC-Native library” or “libtcnative”, is a library that implements HTTP, HTTPS and AJP connectors in tomcat using the Apache APR library. This ensure great scalability and performance because permits tomcat to access server native technologies like openssl, system calls like sendfile() or epoll(), advanced I/O, OS level functionality and native Inter Process Communication.
To install libtcnative you must first have a working C compiler environment, a valid “apr” and “openssl” installation with the development libraries, a working apache tomcat 6.0.X and a Java JDK.
On debian it’s as simple as to run:
apt-get install build-essential libapr1-dev libssl-dev
The libtcnative source software can be found in the Tomcat binary bundle, in the bin/tomcat-native.tar.gz archive, but if you want the latest version you can find it here: http://tomcat.apache.org/native-doc/
Untar the tomcat-native archive, then:
cd tomcat-native-1.*/jni/native
./configure –with-apr=`which apr-1-config` –with-java-home=$JAVA_HOME –with-ssl=yes –prefix=$CATALINA_HOME
If you want or need to, you can pass the correct path of APR and OpenSSL libraries to the –with-apr and –with-ssl parameters.
CATALINA_HOME and JAVA_HOME are the path of the Java JDK and Tomcat installations.
After the configure script succeeded, you have to:
make
make install
Now, the libtcnative library should be correctly installed into “$CATALINA_HOME/lib”.
If you want you can now configure tomcat with the new connectors parameters.
The official project page of libtcnative is here: http://tomcat.apache.org/native-doc/
The documentation page of the tomcat 6 APR native functionality is here: http://tomcat.apache.org/tomcat-6.0-doc/apr.html
Hope this help someone to speed installation.
Ciao a tutti, Dino Ciuffetti.
If you are using the powerful orientdb engine on linux/unix you may catch the following error when executing bin/orientdb.sh:
./orientdb.sh: line 52: return: can only `return’ from a function or sourced script
This is because of bash that does not permit the use of “return” from the main script body.
I prepared (and published to the orientdb list) a small patch that you can use if you don’t want to recompile the entire orientdb engine to solve this simple problem.
The problem it’s solved in SVN revision 3804 or greater.
In this short abstract I’ll show you how did I make my work on trying to create a highly scalable, geo localized and distributed system using the DNS.
What we are going to create is a simple but powerful DNS system that can handle queries for a domain returning records based on the user’s geo location.
To accomplish this task we have to choose a good opensource DNS server. My choice was powerdns (http://wiki.powerdns.com/trac).
Powerdns is a great piece of software. It’s a powerful DNS server daemon that can be configured to fit in different DNS environments.
You can save domain zones into different backends (MySQL, Oracle, bind zone file, ldap, etc), and you can have primary and secondary DNS servers with automatic zone replication. This is all what you need to create a full featured DNS system.
One of the powerdns backends do accomplish the geo lookup task, and it’s called “geobackend” (http://wiki.powerdns.com/trac/browser/trunk/pdns/modules/geobackend/README).
Our test environment will consist in a primary DNS server (powerdns as a master), a secondary DNS server (powerdns as a slave) and a geo lookup DNS server (powerdns as master with geobackend enabled). We will enable automatic zone transfer between the primary and the slave server, so that if you add a new record on the master it will be automatically created on the slave.
So, we need 3 servers with powerdns installed. The installation process may be different in each case, but if you are using debian, the task can be as simple as running by root the following command:
apt-get install pdns-server
Now you need the backend where you will save the zone data. May be you want to choose “MySQL” for the master and “bind format file” for the slave DNS. The geo dns server will not need a zone backend because its single task is to retrieve the caller’s IP address and fetch its geographic location from a particular location file, then lookup this location from a map file and return back to the calling user the associated CNAME record that’s into the map file.
A quick brain guideline is given below.
My system (yourdomain.com) is composed like this:
ns1.yourdomain.com (primary DNS server with mysql backend)
ns2.yourdomain.com (secondary DNS server with auto zone replication on bind zone file)
ns1.geo.yourdomain.com (geo lookup DNS server with geobackend)
I executed the steps below:
On ns1.yourdomain.com you have to:
1) install powerdns with the gmysql backend
2) install MySQL server, create a database and grant a user on that DB
3) configure powerdns as master, with gmysql backend connecting to MySQL
4) please note that this server is authoritative to the “yourdomain.com” zone
5) delegate the “geo” zone with a NS record to the geo dns server: “geo IN NS ns1.geo.yourdomain.com”
6) create the glue record for the geodns with the record: “ns1.geo IN A ip_geo_dns_server”
On ns2.yourdomain.com you have to:
1) install powerdns with the bind backend
2) configure powerdns to be a slave with bind backend and enable ns1.yourdomain.com as a supermaster
3) please note that this server is authoritative to the “yourdomain.com” zone
On ns1.geo.yourdomain.com you have to:
1) install powerdns with the geo backend
2) configure powerdns as master with geobackend
3) please note that this server is authoritative to the “geo.yourdomain.com” zone
4) create a map file to handle the association between your country location (eg: uk) and the CNAME that the server will reply
5) download the location database zone, for example I use: zz.countries.nerd.dk (http://countries.nerd.dk/)
If you need how to do that in details please do not hesitate to write me a email. You will find it into my contact page.
Ciao, Dino.
Hi people. On August 2011 has been discovered that apache httpd server is vulnerable to a simple to perform DOS attack. A simple perl exploit has been released called apache killer that make a big number of parrallel crafted HTTP calls (HEAD method) with the “Range” header. This make possibile to the attacker to consume memory and cpu on the attacked server bringing apache and the system down in no time. The attacker does not need large bandwidth to perform the attack.
Anyone using apache httpd in production environment is encouraged to upgrade to the latest apache version that solve the security problem.
If you cannot upgrade to >= 2.2.20 you can use mod_rewrite to deny requests with the Range header like the rewrite regexp below. This is what you need on your httpd.conf:
RewriteCond %{HTTP:range} ^bytes=[^,]+(,[^,]+){0,4}$
RewriteRule .* – [F]
You can find the exploit script on google. I will not put it here.
Ciao, Dino.
When you work as a horizontal support tech consultant for a very big company you may have to do with people that has basic linux/opensource knowledge and commercial system stuff (win, unix) skills. You may even have to do (… !?!?) with very prepared people (…).
Someone here takes care of apache installations and apache itself is very robust and stable so we all can sleep quietly, the problem comes out when someone with less OS system skills fires “kill -9” on apache processes to stop it.
[Thu Aug 11 17:47:01 2011] [error] (28)No space left on device: Cannot create SSLMutex
Configuration Failed
And apache does no longer come up and running.
The trouble may be weird because one could read “No space left on device” without reading the real error message: “Cannot create SSLMutex”.
But the problem is really easy to understand if you try to figure out what is going on at syscall OS level when apache starts up. This can be done with “strace” command on linux (“truss” or “tusc” on other expensive unix environments…).
The problem is caused by IPC SysV semaphores still standing up on the system from the previous apache kill.
The definitive solution here is to stop apache with “apachectl” command or calling “kill -15” (and not kill -9 !!!!) on the apache father process. This way you are instructing apache to stop gracefully, the father kills his childs and cleanup semaphores and the like, the clean way.
To solve your problem you have to cleanup hanging semaphores. You could reboot linux, but this is avoided on any serious environment, so which is the magic command?
If apache runs with “apache” user you can call this command to clean up semaphores created by the “apache” user:
ipcs -s | grep apache | perl -e ‘while (<STDIN>) {@a=split(/\s+/); print `ipcrm sem $a[1]`}’
You could do “ipcs -s | grep apache” to see the semaphores first, and then call ipcrm on each to clean it up.
Try to start apache now and the problem would solve.
The other way is to change the apache serialization mechanism from semaphores to pthread mutexes or fcntl. To do so you have to:
1) set “AcceptMutex fcntl” on httpd.conf
2) set “SSLMutex pthread” on httpd-ssl.conf
Hope this help someone… 🙂
Ciao, Dino.