29 Lug 21 Don’t use SORBS DNSBL

Sorbs is a infamous DNS blacklist born to try to fight spam. They have a too much restrictive policy that won’t block spam at all but they just create some pain to your MTA.

They can delist your IP a couple of times but if one of your clients get hacked your good quality MTA will be listed for months, even years!

What they don’t understand is that we work with our IP reputation, so just change the IP is not a valid solution. When a valid MTA got abused to send spam the problem is generally solved in hours, or even minutes. A one month list will generate a great problem to the hacked MTA’s clients.

The only solution is: DON’T USE SORBS AT ALL. The list is not business oriented and so is only valid for lamers, bofh sysadmins and nerds…. ok I’m a bofh, nerd sysadmin but I don’t use Sorbs anymore. Sorry.

NOTA: Tell your sysadmins to NOT USE SORBS.

Tags: blacklist, dns, dnsbl, Linux, mailserver, server, sorbs
Filed in General with 0 Comments

21 Feb 14 HOWTO generate a SAN (Subject Alternative Names) SSL CSR with OpenSSL

There is a cool SSLv3 protocol extension that’s called SAN (Subject Alternative Names). With this extension you can create a single SSL X509 certificate that is valid for several domain names, instead of a classic certificate that’s valid for one domain name only.

You can ofcourse create this kind of certificate with OpenSSL. We are now going to see how to do that.
Fist you have to create a file called openssl.cnf and put it for example into a temporary dir. The file should begin with:

[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req

This is to enable SSLv3 req extensions.
Now, you have to add your custom informations to the openssl.cnf file: those informations will be reflected on the next steps.
Add something like this to openssl.cnf:

[req_distinguished_name]
countryName = Country Name (2 letter code)
countryName_default = IT
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = Italy
localityName = Locality Name (eg, city)
localityName_default = Rome
organizationName = Organization name
organizationName_default = My company name Srl
organizationalUnitName = Organizational Unit Name (eg, section)
organizationalUnitName_default = System Techies
commonName = Common Name (eg, YOUR name)
commonName_max = 64
#commonName_default = www.myfirstdomain.it
emailAddress = Email Address
emailAddress_max = 40

The informations above are used by the “openssl req” command to ask you data to generate your certificate request.
Then, add this block of informations into the openssl.cnf file:

[v3_req]
keyUsage = nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = @alt_names

Those informations will enable some extra useful things on your certificate request that will hopefully became valid on your brand new SSLv3 certificate. For example you are requesting your Certification Authority to release a X509 SSLv3 certificate with server and client authentication purposes, plus other certificate goodies.

Now the cool part: this is where you are asking your CA to release a certificate with Alternative Names (certificate valid for several domains). Append this stuff in openssl.cnf:

[alt_names]
DNS.1   = www.myfirstdomain.it
DNS.2   = myfirstdomain.it
DNS.3   = www.myalternativedomain.it
# you could also specify IP addresses like this:
# IP.1 = 1.2.3.4

OK. You are almost ready to create your CSR, but first you have to generate your private key.
NOTE that many CA are now requesting a private key of 2048 bits or more. Warned: a key of 1024 bits is not recommended!
To generate a 2048 bits private key, as usual, execute this command:

openssl genrsa -out server.key 2048

Perfect. It’s time to create the Certificate Request (PKCS#10) with SSLv3 extensions:

openssl req -new -out server.csr -key server.key -config openssl.cnf

Now, send your new server.csr file to your Certification Authority that will hopefully accept the request and relase a valid X509 SSLv3 certificate with SAN.

Good luck and enjoy.

Tags: apache, authority, ca, cipher, dns, http, https, Linux, openssl, san, server, sysadmin
Filed in Linux OS, Open source, Sysadmin pills with 1 Comment

03 Nov 13 SSH connection is slow? Did you try to disable DNS lookups?

If your SSH connection is slow, it may depends on your SSH server that is executing reverse DNS lookups to try to identify your details.

Try setting the parameter below to your /etc/ssh/sshd_config and restart your ssh server daemon:

UseDNS no

It worked perfectly for me, it may work perfectly with you too.

Tags: debian, dns, Linux, server, ssh, sysadmin
Filed in General, Linux OS, 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

09 Ago 11 DNSBL GeoIP service at countries.nerd.dk

I recently discovered a wonderful DNSBL service reporting you where public Internet IPs are from.
The service is countries.nerd.dk: http://countries.nerd.dk/more.html

You can for example block any mail at your mailserver coming from china or russia, simply integrating this DNSBL with your MTA.
You can even get the country of your IP with dig!

Warning: You need to swap IP octets. If for example the IP to check is 192.162.132.171, you have to call 171.132.162.192.zz.countries.nerd.dk.

root@nbvirtdns1:/# dig TXT 201.65.24.151.zz.countries.nerd.dk
…
201.65.24.151.zz.countries.nerd.dk. 1047 IN TXT “it”
…

Tags: dns, Linux, mailserver, mta, server, sysadmin
Filed in Linux OS, Open source, Sysadmin pills with 1 Comment

24 Ago 10 Why do not host sites from your own home

I would not recommend you to host sites that way, you have to be sure that your ISP give you public IP(s) and setup your router to port forward ports 80, 443, 53, and so on.
There are other problems too:
1) if you want to host more than one site with SSL you must have one public IP for each SSL site or use different SSL ports for each site, because name virtualhosting with SSL is not possible;
2) dsl lines are not designed to be stable. The connection can go down and make your site not visible. This is a major problem if you make the mistake to have your own DNS server on it!! The ISP assigned public IP address can change more than one time a day and you have to sync the DNS zone each time.
3) dsl ips are putted into DNS based blacklists zones. You may not be reached from various HTTP proxy servers around the world. For the same reason you cannot send mails, for example originated from your sites.
4) adsl lines are asymmetric (unbalanced for download). You have few kbytes per second in upload, that is just what you need to publish web sites, so this can be a problem when you have just more than 3 users.
5) you probably have problems with High-Availability and Load-Balancing on domestic hardware and you may have blackouts.
6) DNS subsystem may need primary and secondary DNS servers.

The best way (imho) is to use services like slicehost where you have a HA virtual server slice running linux, public IP addresses, free primary and secondary DNS hosting service, large public bandwidth, disk space… and not last your own root password that you can use to have maintenance on your own server for your own.

https://manage.slicehost.com/customers/new?referrer=af57db3020e04bb27352e271753a7a18

Tags: apache, blacklist, dns, Linux, mailserver, server, sysadmin
Filed in Commercial news, Linux OS, Notes, Sysadmin pills with 0 Comments

26 Mar 10 Il tuo server linux personale

Se quello che hai sempre cercato e’ avere il tuo personalissimo server linux up and running 24 ore su 24, SliceHost e’ l’opzione giusta per te.

Questa meravigliosa azienda americana (in Italia purtroppo certe cose ce le sogniamo alla grande!) ha sviluppato un sistema automatico con interfaccia web in grado di fornirti in tempo reale per pochi dollari al mese una tua personalissima macchina virtuale con cui potrai realizzare e gestire il tuo server linux in tutta tranquillita’.
Banda e connettivita’ internazionale a internet non sono un problema e potrai scegliere tra vari tagli di offerte pronte per te.

Se sei interessato, dai un’occhiata al sito https://manage.slicehost.com/customers/new?referrer=af57db3020e04bb27352e271753a7a18 e affiliati anche tu.

Avrai la possibilita’ di scegliere la distribuzione linux che piu’ ti aggrada e il tuo server linux personale sara’ in piedi in pochi secondi.

Noi di TuxWeb lo stiamo utilizzando con successo per gestire i siti internet di alcuni nostri clienti.

Ciao, Dino – http://www.tuxweb.it/

Tags: apache, dns, Linux, mailserver, php, server, sysadmin
Filed in Commercial news, General news, Linux OS, Notes, Sysadmin pills, What's hot with 0 Comments

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.