Newsgroup: it.comp.os.linux.sys
Titolo: Connessioni postfix

Ciao a tutti.
come si fa a vedere le connessioni simultanee che sta gestendo postfix 
in un dato momento ed il rispettivo limite?
Per il limite, dovrebbe essere se non erro 100 (il default di 
'default_process_limit')
per le connessioni io do un
netstat -na | grep ":25" | grep ESTABLISHED | wc -l
ma non so se è il metodo corretto.


Stai prima a contare il numero di processi per-tipo in esecuzione.
Conta il numero di processi "smtpd" e saprai le connessioni "entranti"
in corso.
Conta il numero di "smtp" e saprai le uscenti...
Se vuoi mantenere un monitoraggio costante dell'andazzo, puoi usare in
tal senso l'apposito plugin ps_
Se stai indagando per il motivo che penso io, cmq, la risposta è:
Sì, lì fuori c'è una tempesta di BOT che -secondo me introducendo
latenze nelle comunicazioni, ma non ne ho evidenze- stanno creando
grossi problemi di concorrenzialità dei processi a un sacco di gente,
per quanto si vede. Dal mio monitoraggio, il problema ha iniziato a
porsi lunedì attorno a mezzogiorno...

 tal senso l'apposito plugin ps_
dimenticato un pezzo: il plugin è di munin...
Bye

 porsi lunedì attorno a mezzogiorno...
Sicuramente è collegato.
Io mi sono accorto del problema perchè thunderbird spesso e volentieri
non mi fa inviare posta.
Sta li in attesa 30 secondi poi dice: "NO! questa mail non la mandi
perchè il server non va!"
Ed il server funziona. Allora mi è venuta voglia di controllare se per
caso postfix iniziasse a droppare connessioni perchè sono troppe.
Ma:
1) il limite di postfix di default è 100 vero? Dovrebbe essere questa
direttiva:
 default_process_limit = 10
Mi sembra un po bassina. Ho incrementato di MOLTO tale direttiva ed
adesso sto a vedere cosa succede.
2) Per risolvere sto problema dell'invio (che ripeto, secondo me è
collegato anche ai bot di questi giorni) come si può fare? Qui:
http://www.postfix.org/TUNING_README.html
 parla solo di connessioni
per client. Io devo aumentare (credo) quelle globali del mio server.
(Eventualmente ti scrivo in privato ulteriori dettagli, tanto qualcuno
avrà trovato una soluzione no?)

 avrà trovato una soluzione no?)
Neanche troppo :-\

 porsi lunedì attorno a mezzogiorno...
Invio anche qui, qualora la cosa sia utile a qualcun altro...
Di fatto, pare che le ultime versioni di codice da botnet, dopo aver
ricevuto notifica di reject, anzichè chiudere la connessione la tengano
aperta fino a timeout. Questo aumenta la durata delle connessioni, che
aumenta la concorrenza dei processi, ecc.
Il problema giunge da qui.
Per gli utenti postfix, è sufficiente abbassare il valore di
smtpd_timeout, portandolo dai 300 sec usati di default (e previsti da
RFC) a qualcosa di più modesto ma non eccessivamente basso.
[Gli utenti di altri MTA che dovessero incorrere in analoghi problemi
avranno presumibilmente possibilità di configurazione analoghe]
Io l'ho portato attorno ai 60 sec, altri sono scesi a valori più bassi;
fonti autorevoli suggeriscono tuttavia i 45s come limite sotto il quale
non è il caso di scendere...

 non è il caso di scendere...
Bo, sta cosa mi fa strano.
Son passato da 300 connessioni in ESTABLISHED a 98 processi (i
processi e le connessioni in ESTABLISHED son state conteggiate in
tempi differenti quindi non son paragonabili) ad una media di circa
15-20 processi.
Sarà, ma i 45s di timeout che ho messo non penso abbiano portato ad un
cambiamento così radicale. O no?
Che sia finito il 'bot-run' ?
In concomitanza, non ho più riscontrato ulteriori problemi in invio
(come da oggetto di questo post).
Probabilemente i miei problemi di invio erano causati dallo spamrun/
botrun in corso, e -forse- dopo aver abbassato il timeout buona parte
dei problemi son passati.
Purtroppo, al momento, non posso monitorare costantemente i processi
pertanto devo farlo a manina e non riesco a 'vedere' i picchi. Però mi
sembra tutto regolare, almeno per ora...
A te come butta? (scrivimi in privato se vuoi)

 A te come butta? (scrivimi in privato se vuoi)
Tutto tranquillo: ogni tanto capita un picco durante il quale i processi
tornano a saturare, ma dura al più qualche minuto.

 ...
Uhm... non so a quale punto della conversazione SMTP dai un reject - io, 
per esempio, lo faccio solo dopo l' RCPT TO.
Purtroppo, pero', molti di questi BOT-tini [1], dopo aver aperto qualche 
decina di connessioni, restano in stand-by senza *neanche arrivare* ad 
inviare un RCPT TO (non so in quale punto si fermano di preciso). 
Ovviamente l'attesa, come hai detto, si interrompe solo con il timeout 
del server.
Tra l'altro, quelle che ho tracciato manualmente sui log, sono tutte 
connessioni provenienti da IP in blacklist su SpamHaus. Se arrivassero 
ad inviare un RCPT TO [2], essendo appunto in blacklist, si troverebbero 
a ricevere non solo un 550, ma anche un'immediata chiusura della 
connessione (cosi' le tratto). E il problema (almeno per me) non ci sarebbe.
In questi giorni, poi, e' una vera e propria tragedia: 4 o 5 DoS al 
giorno di 1 o 2 minuti che, sporadicamente, arrivano anche a 3 o 4 minuti.
Abbassando i timeout dei server da 120 a 90 sec (che, se non erro, per 
RFC /dovrebbe/ essere addirittura di 300 o + sec) ed aumentando un po' 
il numero di connessioni contemporanee, non ho risolto moltissimo.
Quindi, ieri, ho impostato per prova su un server (dopo una patch) il 
numero max di connessioni contemporanee *per IP* [3], quando queste 
*provengono da fuori* (ie.: NON per connessioni LAN o provenienti da IP 
in relay).
Per ora gli ho dato un valore arbitrario di max 8 x IP, che ad occhio mi 
sembrerebbe ragionevole (che dite?) per dei server da 400/500 utenti...
Al momento parrebbe risolvere il problema. Vediamo...
Nei log mi appaiono gia' qualche centinaio di connessioni stoppate con 
un 451 - tutte apparentemente "colpevoli" (e so' soddisfazioni!) ;-)
HTH
Note:
1) Qualcuno dice che si tratti di trojan (o maialate simili) bug-gati. 
Altri pensano che gli spammer usino macchine trojanizzate, ormai in 
blacklist, allo scopo di fare -solo o anche- del casino (ma a che pro?).
2) Qui si potrebbe risolvere chiudendo la connessione immediatamente 
senza aspettare l'RCPT TO, visto che sono IP in blacklist. Ma per una 
serie di ragioni, tra cui anche quella di poter permettere sempre 
l'invio a postmaster, eviterei di farlo (facendosi meno scrupoli, pero', 
puo' essere un'ottima soluzione).
3) Uso Qmail, non so se esista una configurazione del genere anche per 
Postfix
Ciao
-- 
Cybertoldo
Per rispondermi via email, sostituisci moc.liamg con 
gmail.com

 Postfix
Il rate/connection limit per-IP? Sicuro: anvil.

 contro gli interessi stessi degli spammer :-D
F/uppiamo l'ultima ipotesi su IDLM :) (oddio, pensa se fosse vero...!)
