msgbartop
Blog di Dino Ciuffetti (Bernardino in realtà)
msgbarbottom

07 Set 10 N4g10s monitoring system

Server Room – AD 2034

Sys techie 01A2B: Hey boss, we just had a complete network crash! It seems our main router got down 3 seconds ago, and the main network branch red blinks on our N4g10s monitoring system!!

Network Boss: Uhh… that’s strange, because it’s coupled with a network HA backup. Go upstairs to the router cabinet and check immediately!

Sys techie 01A2B: Ok boss. I’m going… …

Network Boss: what’s up?

Sys techie 01A2B: Hey boss, the two routers have been stolen!! The cables are detached and unlinked, no routers present here!!

Network Boss: mmmhhh… I’m getting there. Wait.

Sys techie 01A2B: .. Hey boss the routers are there now!! That was the cleaning lady! She thought there was time to clean the routers from dust…

Network Boss: ok ok, re create links, please. I’m going to handle angry users now… And get up and running quickly!

[A Angry User]: Hey, I am experimenting a network problem! What’s up?

Network Boss: Which network problem? There is not a network problem. Please retry.

[A Angry User]: mmhh… very strange, it now works! Sorry, that was a false negative. May be a client Winblows problem. Thank you.

Network Boss: Please double check next one. Hi man.

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

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/

13 Mar 10 DynaBlast, and your access_log give you something

If you want an apache httpd server access_log scanner written in C that check for you every IP address that exceed a given number of hits in the last given time period, then DynaBlast is a tool that make sense for you.

This tool, released as usual in GPLv2, can be spawned every minute in crontab without the risk of having two instances running: we make use of a lock mechanism.
It has a fast mode that can skip already parsed line from a consecutive scan, so each time it runs, it play very fast.

In stdout you’ll get the scanning result. Ex:

blacklisted:10.248.220.43
blacklisted:23.212.121.165

You can download DynaBlast from here: http://www.tuxweb.it/?section=progetti/dynablast

Ciao, Dino.

21 Feb 10 Scandalo, the fast and Simple clamdscan mail frontend

Hi people.
I’m now talking about a simple GPLv2, C written, small program that work as a very fast clamdscan antivirus frontend.

Scandalo can take a mail on standard input and parse it from viruses, piping it to clamdscan.
It then get the virus status from clamdscan and put a mail header called “X-Virus-Ret” returning the virus scanner status.
It also put a mail header called “X-Virus-stream” returning the first virus name found (if any).

You can then setup a rule on your (say, maildrop) mail filter to pipe the incoming mail to scandalo, and another rule to check the return scanned mail header for viruses.
If a virus was found, you can drop the mail, or put it into a .Virus maildir.

If you have any question, I’m the developer of scandalo.
Scandalo – http://www.tuxweb.it/?section=progetti/scandalo&

Write me a note at dino@tuxweb.it.

Ciao, Dino.

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.