16 Apr 16 How to check if JCE Unlimited Strength policy is installed

JCE Unlimited Strength policy files are two files distributed by Oracle (this is for jdk8: http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html) that must be installed inside your JDK/jre/lib/security path if you want to unlock high strength cryptographic security for you java environment.

You need it for sure in a server environment outside USA.

If you don’t have this stuff installed, your jboss, tomcat, or any other server or client with a keylength higher than 1024 will not work.
To enable JCE Unlimited Strength you simply need to unzip the file downloaded from Oracle and copy US_export_policy.jar and local_policy.jar files in <JDK>/jre/lib/security.

You can check if JCE is unlimited using this command:

jrunscript -e ‘exit (javax.crypto.Cipher.getMaxAllowedKeyLength(“RC5”) >= 256);’; if [ $? -eq 1 ]; then echo “JCE Unlimited OK”; else echo “JCE NOT Unlimited”; fi

The jrunsctipt command is installed inside your JDK/bin path.

Tags: authority, cipher, https, java, jce, library, Linux, policy, server, sysadmin
Filed in Linux OS, Sysadmin pills with 0 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

07 Set 11 How to map DNS responses based to user’s geo location

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.

Tags: blacklist, dns, Linux, policy, server, sysadmin
Filed in Linux OS, Open source, Sysadmin pills, What I'm doing with 0 Comments

04 Lug 11 How to use Huge Pages with Java and Linux

Hi.
Today we get how to use Huge Pages with Java from a Linux powered system.
While a Linux system generally splits memory segments into pages of 4 kb, Huge Pages are memory pages large 2Mb or more.
This is proved to increment speed when the application make use of large quantity of ram, like Java with a large heap (2 GB or more).
It’s correct to say that this is not always the correct configuration choice because the memory setted to be dedicated to Huge Pages cannot be accessed by the kernel (buffer cache) or by the applications, so that memory is subtracted from the virtual memory pool of the system. Since it’s very fast to make it a try and decide if use it or not, let me play with it.

Here in this example we will set 2,5 GB of RAM to be used as Huge Pages. Your mileage may vary.
HPM (huge page memory) is expressed in GB.

First: set the quantity of memory (bytes) to be defined as a shared memory segment
This is quickly found calculating this simple formula: ((HPM * 1024 * 1024 * 1024) – 1).
In our example: ((2,5 * 1024 * 1024 *1024) – 1) = 2684354559
Set it up online with this command:
echo 2684354559 > /proc/sys/kernel/shmmax
If you want to set it permanent at the next system reboot, append those two lines to your /etc/sysctl.conf file:
# Shared memory – max segment size: 2,5 Gb (-1 b)
kernel.shmmax = 2684354559

Second: set the number of reserved large memory pages
This is the number of reserved pages. Each page is large 2 Mb, so finding the number of pages to reserve is simple:
((HPM * 1024) / 2). In our example: ((2,5 * 1024) / 2) = 1280
Set it up online with this command:
echo 1280 > /proc/sys/vm/nr_hugepages
If you want to set it permanent at the next system reboot, append those two lines to your /etc/sysctl.conf file:
# Enable kernel to reserve 2,5GB / 2Mb large pages
vm.nr_hugepages = 1280

Third: set the system group id enabled to use huge pages
Java programs usually should not be fired by the root user. In my case, the group id of my program is “1001”.
Set it up online with this command:
echo 1001 > /proc/sys/vm/hugetlb_shm_group
If you want to set it permanent at the next system reboot, append those two lines to your /etc/sysctl.conf file:
# System group id that can use huge pages (hugepages gid: 1001)
vm.hugetlb_shm_group = 1001

Fourth: run the java program with the Huge Page support
In our example we are using the JVM distributed by Oracle. Other Java vendors may use different parameters to enable Huge Pages. They can even call Huge Pages differently.
The program can now be fired with “-XX:+UseLargePages -XX:LargePageSizeInBytes=2m”
My complete java parameters for my java program are:
java -d64 -server -Xms1900m -Xmx1900m -Xss192k -XX:+UseLargePages -XX:LargePageSizeInBytes=2m -XX:+UseParNewGC

Ciao ciao.
Dino Ciuffetti.

Tags: hugepages, java, Linux, memory, policy, server, sysadmin
Filed in General, Linux OS, Open source, Sysadmin pills with 1 Comment

29 Gen 10 Per un buon mailserver

Chiunque ha, o abbia provato ad avere un proprio mailserver per spedire mail in uscita ha potuto costatare personalmente che moltissimi mailserver dall’altra parte del filo hanno dei sistemi di blacklist per cercare di combattere lo spam, e che presto o tardi finiscono con il bloccare temporaneamente il nostro IP, o peggio mandare le nostre mail nella cartella Spam del destinatario.

Sebbene non esista un capitolato standard, dopo qualche anno di combattimento con le mail ho potuto stilare una serie di buone regole per cercare di attenuare la problematica.

Io utilizzo da anni Courier MTA (http://www.courier-mta.org/) e mi trovo veramente bene, ad ogni modo le seguenti regole valgono per qualsiasi mailserver.

Attenendosi alle seguenti regole, sara’ possibile inviare tante mail senza troppi problemi.

1) utilizza NECESSARIAMENTE un IP statico per inviare le mail
2) crea un Reverse PTR record sul DNS per il tuo IP e chiamalo mail.tuodominio.it
3) crea un A record chiamato mail.tuodominio.it sul DNS che punta all’IP
4) crea un MX record per accettare le mail in ingresso/ritorno e fallo puntare a mail.tuodominio.it
5) crea sul DNS il TXT record per il Sender Policy Framework e crea regole che abilitano a spedire posta dal tuo dominio solo dall’IP del mailserver
6) fai utilizzare al tuo MTA una connessione di rete stabile, e soprattutto un DNS stabile e veloce!!
7) crea sul server SMTP un account postmaster@tuodominio.it
8) disabilita il relaying per il tuo mailserver. Se lo devi abilitare, crea degli utenti abilitati al relaying con password robuste e abilita SSL sul server SMTP
9) fai uscire dall’IP del tuo MTA solo le mail originate dal tuo mailserver. Se ad esempio c’e’ un Firewall che fa source NAT in uscita, fai in modo di aprire la porta di destinazione 25 sul firewall verso internet solo ai pacchetti provenienti dal mailserver. Se hai nella tua rete altri client SMTP che creano mail in uscita spegnili, o falli passare necessariamente in relaying per il tuo MTA
10) utilizza se possibile accorgimenti atti a sopprimere i Delivery Status Notification per le mail in ingresso, come ad esempio ritornare errore subito durante la ricezione della mail se un utente non siste o la mail viene bloccata
11) utilizza un sistema antispam come spamassassin e abilita le blacklist IP basate su DNS per tutte le mail in ingresso
12) imposta il tuo “Helo” message sul mailserver affinche’ si esponga sempre come “mail.tuodominio.it”
13) se possibile, per le mail in relaying, configura il tuo mailserver per strippare i “Delivered to” headers. In questo modo gli altri mailserver crederanno che la mail in relaying e’ stata generata dal tuo mailserver.
14) se possibile, quando spedisci le mail, utilizza sempre come mittente un account esistente che corrisponda ad un dominio gestito dal tuo mailserver
15) evita se possibile account non esistenti del tipo “no-replay@tuodominio.it”. Nel caso ti servisse, crea l’account e scarta tutte le mail in ingresso buttandole in “/dev/null”

Queste regole sono secondo me un buon modo per evitare di finire velocemente nelle miliardi di blacklist in giro per il mondo.

Mi raccomando, scrivetemi a dino@tuxweb.it e fatemi sapere se funziona, o mandatemi i vostri suggerimenti con altre regole e io le integrero’.

Ciao, Dino.