We are in the process of migrating this forum. A new space will be available soon. We are sorry for the inconvenience.

SPAM e blocco porta 25


albert
19.12.2013, 12.45
Ciao a tutti,

@mac: quoto quanto dici

@emanuelebruno ... se puo' esserti di aiuto ti parlo della mia eperienza:

la mia macchina faceva effettivamente un quantita' industriale di spam.
il problema e' stato creato da un c...,, beh diciamo cliente che aveva uppato il suo sito via ftp. Sito che prima era su un altro hoster. I contenuti erano hackati (joomla).

Questo hack andava a creare file batch pieni di bella roba (wget di contenuti, creazione di report che venivano usati per l'attacco successivo ...insomma un bel po di roba). Questa roba veniva veniva immagazzinata in file txt e chiamata all'occorrenza tramite jpeg hackate (php). Le cartelle colpite ... images stories

I file di lavoro dell'hack venivano storati in /tmp (controllala e ripuliscila subito)

Controlla che il sistema non sia compromesso (io ho usato rkhunter)

Anche se ho scoperto l'acqua fredda ... penso che forse posso aver dato un piccolo contributo

Alberto

bago
18.12.2013, 09.10
Se ho capito bene come funziona il sistema temo non sia possibile: loro possono "spiare" il contenuto della conversazione SMTP ma non "alterarlo". Per questo possono dire "l'email che è appena passata ERA un virus" e tenere in considerazione questo fatto al fine di bloccare successive connessioni uscenti sulla porta 25.

Non riescono tecnologicamente a bloccare una specifica email.

Quello che DOVREBBERO fare è fare un rapporto tra email VIRUS/MALWARE, email SOSPETTE, ed email VALIDE e poi
- se il rapporto virus sale sopra l'X% ti avvisano, se sta sopra l'X% per più di X giorni ti bloccano.
- se il rapporto SOSPETTE sale sopra l'Y% ti avvisano, se sale sopra l'Y% per più di X giorni ti bloccano.

Eventualmente gli avvisi per virus potrebbero partire comunque anche se ce ne è uno solo, per dare modo ai clienti di intervenire il prima possibile.

Io credo che questo potrebbero farlo con la tecnologia attuale e funzionerebbe molto meglio.

emanuelebruno
18.12.2013, 08.39
Citazione Originariamente Scritto da bago
[...]Condivido la proposta di @mac come gestione dei virus/malware ma non come gestione dello spam.[...]Se proprio volete bloccare gli IP spammosi dovete farvi un sistema di gestione della reputazione ma è estremamente complicato costruirne uno stando dalla parte del mittente[...]
Quindi per concludere, se invece di bloccare l'ip venisse bloccata semplicemente l'email *RITENUTA* spam (oltre a quelle contenenti virus) non sarebbe meglio ?

bago
17.12.2013, 22.44
In ogni caso secondo me andrebbe fatta una gestione diversa a seconda se si rileva malware/virus (che sono cose *oggettive*) o se invece viene rilevato spam (che è *soggettivo*). I software antispam possono solo ipotizzare se una email è spam o meno, non possono saperlo con certezza: l'unico che lo sa con certezza è chi lo riceve (spam = posta indesiderata e l'unico che sa se è desiderata o meno è il ricevente.. ciò che è spam per te può non esserlo per me).

Bloccare un IP che invia milioni di email solo perchè 100 email sono *FORSE* spam è sempre e comunque sbagliato, anche se permetti di sbloccarlo immediatamente.

Condivido la proposta di @mac come gestione dei virus/malware ma non come gestione dello spam.

Il software antispam usato da OVH non è nato per bloccare degli IP ma solo di identificare email potenzialmente di spam assegnando loro un punteggio.

Quindi il sistema attuale è profondamente fallato SECONDO ME e vedendo che OVH non ammette che c'è un problema grave ed evidente non si tratta certo di un problema trascurabile col quale si può convivere intanto che si convice OVH del problema o intanto che OVH mette a punto i suoi sistemi sulla nostra pelle.

Se proprio volete bloccare gli IP spammosi dovete farvi un sistema di gestione della reputazione ma è estremamente complicato costruirne uno stando dalla parte del mittente (io lo faccio per evitare che i miei clienti facciano spam e non è completamente automatizzabile, purtroppo): gli unici che riescono a farlo sono quelli che possono vedere cosa fa il ricevente con l'email che ha ricevuto. Per lo meno date una occhiata a senderbase o senderscore per vedere se l'ipotesi che avete fatto voi sull'IP è confermata anche da servizi di gestione della reputazione pubblici.

emanuelebruno
17.12.2013, 19.39
Citazione Originariamente Scritto da mac
[...]Io direi: bloccate a tempo indeterminato ma con la possibilità da parte del cliente di sbloccare una volta trovato e risolto il problema.[...]
Non ho sentito l'applauso ma direi che è meritato.

PS Anche io avevo fatto la mia proposta:
Citazione Originariamente Scritto da emanuelebruno
[...]Da qui la mia domanda: se il sistema VAD è in grado di identificare lo spam perché semplicemente non lo blocca invece di bloccare gli ip dei clienti?[...]

mac
17.12.2013, 18.02
Io non ho ancora avuto un blocco della porta 25 su nessuno dei miei server, quindi parlo da "osservatore" esterno. Un po' preoccupato.

Capisco e mi auguro che il compito di OVH sia quello di "vendere servizi e garantire che funzionino correttamente" come è stato detto giustamente da torpado, ma OVH dovrebbe anche capire che chi acquista un server per "utilizzo professionale" e magari rivende dei servizi, non lo fa di certo con il fine di spammare.

Certo, sicuramente tra i migliaia di clienti onesti e in buonafede di OVH ci sarà anche una certa percentuale che usa di proposito il servizio in modo fraudolento e illegale... e quelli vanno fermati! È interesse di tutti! Su questo penso che si sia tutti d'accordo.

La cosa che non mi piace di questa politica di OVH è che fa presto a dire: mail_di_spam_inviate ->> cattivo_cliente_da_punire

IMHO invece è essenziale DISTINGUERE: distinguere chi invia spam di proposito e solo con quello scopo, da quelli che si sono trovati uno script buggato sul sito di un qualche cliente e nemmeno si sono resi conto.
Perché, lo sappiamo tutti, per quanto attenti si possa essere e per quanto si possano attuare tutte le misure per limitare i danni, è tecnicamente impossibile proteggersi al 100% da questo tipo di problemi (a meno di non spegnere il server o castrarlo a tal punto da renderlo inutile).
Sfido chiunque a provare il contrario.

Faccio una proposta. Potenzialmente applicabile almeno a chi acquista un server "-ovh"
OVH potrebbe mettere in atto una politica di MITIGAZIONE diversa dal segare direttamente la porta 25 per X giorni, senza possibilità di appello.
Se è vero che queste email vengono filtrate (e qui si potrebbe aprire un thread a parte), perché bloccare per 1h? poi 24h e poi 30gg?
Io direi: bloccate a tempo indeterminato ma con la possibilità da parte del cliente di sbloccare una volta trovato e risolto il problema.
Uno strumento di questo tipo in mano ad un professionista serio è la risposta giusta, secondo me. Perché gli lascia il controllo, senza sentirsi sempre con la spada di Damocle dietro le orecchie e col terrore di vedersi un server con migliaia di utenti fermo per colpa di uno solo.

Saluti

P.S. Perché questo "bellissimo" servizio di anti-spam a costo zero non viene pubblicizzato nel sito ed esposto in chiaro nei contratti?
P.P.S. Domanda volutamente provocatoria: Perché tanta sollecitudine nel filtrare non viene usata anche per le mail in entrata? ;-)

bago
17.12.2013, 17.35
OVH potrebbe avere un qualche scan tool che trova il software che ha la falla che permette l'invio di quelle email.

Purtroppo qualunque software con buchi di sicurezza potrebbe essere potenzialmente essere usato per mandare email e quindi è difficile stabilire da dove partire.

Io comincerei con il controllare i log di apache per vedere se ci sono richieste strane nel periodo in cui OVH ha rilevato quei messaggi: se c'è un buco in una tua pagina PHP (o altro linguaggio usato dai tuoi server web) allora dovresti vedere quasi sicuramente delle GET con un sacco di strani parametri o delle POST in quantità tale da giustificare il blocco di OVH (centinaia, probabilmente, ma puoi verificarlo nel manager dove ti viene dato l'elenco completo pre-blocco).
Se noti il Message-ID ha una stringa con l'orario: cerca corrispondenze di quegli orari nei log apache (o di altri servizi esposti al pubblico che girano sul tuo server).

/var/log/mail.log tiene traccia SOLO ESCLUSIVAMENTE delle email inviate con il comando "mail" di linux: se le email vengono inviate con un sistema differente (ad esempio con un programma che si connette direttamente ai server remoti in TCP) allora non rimane alcuna traccia su /var/log.

emanuelebruno
17.12.2013, 14.31
Citazione Originariamente Scritto da webdep
[...]Ci tengo inoltre a precisare che OVH non blocca arbitrariamente e senza motivo i server per 30 giorni. Il blocco di 30 giorni è il 3°, dopo che è stato ignorato il blocco di 1 ora e di 24 ore.[...]
Ciao Assistenza OVH, approfitto del vostro intervento per chiarire una volta per tutte anche quest'altro aspetto della vicenda:

premetto che fino a 20 giorni fa non avevo mai avuto problemi di questo tipo e che per tanto la mia esperienza sull'argomento era limitata al "modo in cui combattere lo spam" (ovvero "come evitare che i propri clienti ricevano lo spam sulle loro caselle di posta elettronica");

giorno 22 novembre alle ore 22:35 ricevo la prima email di ovh che dice che mando spam con virus:

Destination IP: 143.215.130.225 - Message-ID: 1106548742.20131123012914@mediaone.net - Spam score: 9999
Destination IP: 143.215.130.121 - Message-ID: 751389587.20131123012922@mediaone.net - Spam score: 9999
Destination IP: 64.136.44.45 - Message-ID: 110030771.20131123012924@juno.com - Spam score: 9999
Destination IP: 64.98.36.5 - Message-ID: 738399797.20131123012925@buckeyeexpress.com - Spam score: 9999
Destination IP: 64.136.52.45 - Message-ID: 1063782885.20131123012928@juno.com - Spam score: 9999

Quindi procedo come mi viene suggerito :
- blocco l'invio di mail (anche se in realtà è già così dato che le email sono tutte in coda in quanto la porta 25 è bloccata da OVH)
- verifico la coda di mail (elimino qualcosa come 600 messaggi della newsletter di un mio cliente)
- sblocco l'invio di mail tramite API di OVH
- riavvio il servizio postfix

Purtroppo però alla mezzanotte (ovvero dopo circa 2 ore) ricevo la seconda email con ban per un giorno che dice che mando spam con virus:

Destination IP: 207.162.160.12 - Message-ID: 332718890.20131123031950@vci.net - Spam score: 9999
Destination IP: 64.136.52.45 - Message-ID: 605420811.20131123013558@juno.com - Spam score: 9999
Destination IP: 64.98.36.139 - Message-ID: 845139318.20131123013559@lycos.com - Spam score: 9999
Destination IP: 64.136.44.45 - Message-ID: 1283839443.20131123025104@juno.com - Spam score: 9999
Destination IP: 64.8.71.112 - Message-ID: 697858387.20131123025108@Knology.net - Spam score: 9999

A questo punto mi fermo e comincio a fare il punto della situazione; da dove arriva questo spam ? quale è stata l'ultima modifica che ho fatto al mio sistema (dato che sono più di due anni che ho questo server e che non ho mai avuto di questi problemi?)

Verifico i file log e noto una certa attività frenetica sulla porta 1143 di imap-proxy che, guarda caso, è il programma che avevo installato un mese fa per velocizzare roundcube... vuoi vedere che avevo dimenticato di indicare ad imap-proxy di funzionare solo sulla porta 127.0.0.1 ?

Felice e contento stoppo il servizio, modifico il file di configurazione di imapproxy, e riavvio il servizio.

Problema risolto.

Dopo 13 giorni ovvero il 05/12/2013 alle ore 3:12 ricevo la terza e questa volta la più temuta delle email di OVH: rilevato traffico spam, blocco per 30 gg!

Nel racconto vorrei che emergesse però un fatto che magari potrebbe sembrare scontato: per tutto quel tempo ho creduto e pensato che dato che OVH aveva rilevato lo spam con virus allora doveva essere per forza così e per tanto non ho fatto un riscontro dei message-ID o degli indirizzi IP che venivano citati nelle email (brutta cosa l'inesperienza)... semplicemente stavo cercando nei log il servizio incriminato che poteva aver mandato lo spam:

Il controllo incrociato della email di OVH e i miei file log è cominciato dopo la terza email...

Quindi per concludere: nei file log non ho mai trovato corrispondenza tra i messageID/indirizzi ip citati da ovh e i file log in mio possesso; con l'occasione però ho potuto constatare che c'erano stati numerosissimi tentativi di accesso sulla porta sasl del mio server (ora bloccati da fail2ban) e numerosi tentativi di accesso sulla porta di imapproxy (che da giorno 23/11 risulta bloccata da tutti gli ip esterni al server) ...

Il mio server è basato su UBUNTU 12.04 e la guida per l'installazione di ISPConfig è documentata su questo post:

http://www.howtoforge.com/perfect-se...ot-ispconfig-3

Spero di aver chiarito una volta per tutte la vicenda.

PS Quando OVH dice di essere in grado di trovare le prove dell'avvenuto invio di queste email dentro il mio server mi viene da pensare : dato che OVH ci ha abituato a trovare tutte le risposte sui loro siti / forum / wiki / ecc... perché giusto nel mio caso non dovrebbe essere così? perché in un sistema ubuntu 12.04 il file /var/log/mail.log non dovrebbe aver memorizzato alcuna prova di questo avvenuto invio? e soprattutto: quali altri file avrebbero in qualche modo conservato queste tracce di cui evidentemente solo il sistemista di OVH è a conoscenza ?

"...io non so quali altri file andrebbero controllati perché io non sono un sistemista, quindi se non sei in grado il nostro sistemista può fare un controllo al posto tuo aprendo un ticket a pagamento..."

emanuelebruno
17.12.2013, 13.40
Citazione Originariamente Scritto da bago
se hai selinux puoi impedire a PHP di aprire socket.
Altrimenti se nessuno dei tuoi siti php le usa puoi disabilitare le funzioni socket_create e fsockopen.
Ciao Bago e ringrazio tutti i partecipanti alla discussione perché con il loro interventi contribuiscono a chiarire alcuni aspetti della vicenda che per me sono diventati un'ossessione;

Innanzitutto vorrei precisare ciò che mi sta mandando in paranoia : se qualcuno mi dice che ho mandando spam con virus e che per questo motivo il servizio viene bloccato per 30 giorni io vado in tilt perché penso che mi possono aver hackerato il server oppure che c'è una falla nel sistema tramite cui è possibile inviare spam, virus ecc...

E poiché spostare l'ip bloccato del server mi costa una nottata di lavoro (l'ultima è stata dall'1 alle 5 del mattino) mi rendo conto che devo trovare subito una soluzione affinché non debba succedere di nuovo (e dato che ad oggi nessuna modifica è stata fatta al server devo presumere che succederà ancora ed è questione di giorni...)

Per chi fosse interessato all'argomento potrà dare un'occhiata a quest'altro post che ho aperto presso il sito di ISPCONFIG : http://www.howtoforge.com/forums/sho...d.php?p=307297

bago
17.12.2013, 13.16
Citazione Originariamente Scritto da webdep
Ci tengo inoltre a precisare che OVH non blocca arbitrariamente e senza motivo i server per 30 giorni. Il blocco di 30 giorni è il 3°, dopo che è stato ignorato il blocco di 1 ora e di 24 ore.

Non diciamo che OVH blocca per 30 giorni e senza motivo i servizi ai clienti.

Il fatto che il blocco di 30 giorni avvenga solamente dopo 3 volte non significa che i motivi che hanno portato i 3 blocchi siano motivi che per noi siano considerabili validi. Io ho esperienza di un blocco di 1 ora totalmente campato in aria. Se si fosse ripetuto 3 volte mi avreste bloccato 30 giorni senza motivi (o per lo meno senza motivi che io considero validi, motivo per cui ho migrato il grosso dell'invio su altro provider).

bago
17.12.2013, 13.14
Citazione Originariamente Scritto da webdep
@Bago, Oltre a intraprendere un'azione legale o cambiare fornitore c'è la soluzione numero 3: Muoversi per risolvere il problema.

Vedo che hai fatto delle ipotesi che già di per se non includono tutte le possibilità tramite le quali l'invio poteva essere effettuato.
LOL: dici a me che bisogna muoversi per risolvere il problema e che non ho fatto tutte le ipotesi plausibili: tu quali ipotesi hai fatto? come hai aiutato il cliente più di quanto abbia fatto io??

Se hai voglia di aiutarlo fallo pubblicamente così che ne possano trarre giovamento tutti, altrimenti evita di criticare quel po' di aiuto che io ho saputo dargli e voi no, da quello che mi risulta.

bago
17.12.2013, 13.09
Citazione Originariamente Scritto da torpado
Ho seguito personalmente questo caso e posso assicurare a chi legge questo thread che non hai riportato i fatti "super partes".
Hai fatto bene a linkare il thread! Così ognuno si fa l'idea che vuole. Secondo me il mio riassunto è estremamente superpartes e chi lo legge potrà rendersene conto: poi comunque tutto sta nel fatto che OVH non ha mai dismostrato che io ho fatto un "L2 tunnels utilizzati tra i servers per joinare 2 networks nei nostri DC," come ha sostenuto (alcune volte) essere la causa del blocco e io sono CERTO di non averlo fatto, quindi la mia posizione è super partes.

Detto questo, questi avvenimenti sono realmente accaduti su servizi non base di OVH e ogni volta ho avuto rscontri spiacevoli e quindi visto che non ho avuto voglia di farvi causa almeno diffondo la mia esperienza così che altri non debbano trovarsi nella stessa situazione. Uno user-to-user forum serve a questo e chi ha aperto il thread ha dichiarato il mio messaggio come utile.

webdep
17.12.2013, 12.21
Ciao emanuelebruno, come ti è stato spiegato al telefono, tramite ticket e tramite mail, il nostro sistema antispam ha rilevato che dal tuo server sono state inviate le mail di spam che ti sono state segnalate.

Tu hai presentato dei log a dimostrazione del fatto che la mail non è partita dal tuo mail server, ma il punto è che la rilevazione del problema non si effettua semplicemente guardando quel log ma è molto più complessa.

@Bago, Oltre a intraprendere un'azione legale o cambiare fornitore c'è la soluzione numero 3: Muoversi per risolvere il problema.

Vedo che hai fatto delle ipotesi che già di per se non includono tutte le possibilità tramite le quali l'invio poteva essere effettuato.

OVH, oltre a segnalarti il problema ti offre anche la possibilità di eseguire un'analisi. Dato che questo servizio non è incluso nei contratti ha il costo di 80 euro +IVA.

Puoi scegliere di far eseguire l'analisi a OVH o di affidarti ad un tecnico esterno, come ti è stato suggerito da Bago.

Ci tengo inoltre a precisare che OVH non blocca arbitrariamente e senza motivo i server per 30 giorni. Il blocco di 30 giorni è il 3°, dopo che è stato ignorato il blocco di 1 ora e di 24 ore.

Non diciamo che OVH blocca per 30 giorni e senza motivo i servizi ai clienti.

torpado
17.12.2013, 11.26
Citazione Originariamente Scritto da bago
Anche se non trova nulla non cambia niente.
Gli 80€ li paghi non perchè loro possano provare che è colpa tua, ma perchè ti aiutino a trovare il problema (e anche se non ci riescono): è una consulenza che puoi chiedere ad OVH ma anche ad altri (e probabilmente è meglio che ti rivolgi ad altri se vuoi una risposta super partes).

Il nostro business è vendere servizi e garantire che funzionino correttamente, non chiuderli in maniera casuale/random (ovvero non "super partes") come viene fatto trasparire da questa considerazione.

A me una volta, come motivazione di un blocco, hanno inviato un log di un loro router che non includeva nessun mio IP e nessun mio MacAddress che secondo loro dimostrava che il mio server aveva fatto un tunneling layer 2 tra 2 vlan rompendo la rete di OVH... i log non dicevano questo ovviamente, ma cosa potevo fare? Ha senso iniziare una causa legale per cose simili o è più semplice cambiare fornitore?
Non ha senso mescolare problemi completamente diversi :
diversi come origine, diversi come ripercussioni sulla stabilità dell'infrastruttura di rete e diversi per la modalità di gestione sia nostra che del diretto interessato.

Ho seguito personalmente questo caso e posso assicurare a chi legge questo thread che non hai riportato i fatti "super partes".

bago
17.12.2013, 09.03
se hai selinux puoi impedire a PHP di aprire socket.
Altrimenti se nessuno dei tuoi siti php le usa puoi disabilitare le funzioni socket_create e fsockopen.

bago
17.12.2013, 09.00
Anche se non trova nulla non cambia niente.
Gli 80€ li paghi non perchè loro possano provare che è colpa tua, ma perchè ti aiutino a trovare il problema (e anche se non ci riescono): è una consulenza che puoi chiedere ad OVH ma anche ad altri (e probabilmente è meglio che ti rivolgi ad altri se vuoi una risposta super partes).

A me una volta, come motivazione di un blocco, hanno inviato un log di un loro router che non includeva nessun mio IP e nessun mio MacAddress che secondo loro dimostrava che il mio server aveva fatto un tunneling layer 2 tra 2 vlan rompendo la rete di OVH... i log non dicevano questo ovviamente, ma cosa potevo fare? Ha senso iniziare una causa legale per cose simili o è più semplice cambiare fornitore?

emanuelebruno
17.12.2013, 08.35
Citazione Originariamente Scritto da bago
Uno script php (o altro che giri sui tuoi server) può aprire socket verso i server destinatari senza bisogno di usare il comando mail e in quel caso non vedi niente nei log. [...]
Se però fosse così, anche pagando €80,00 il tecnico come farebbe a trovare traccia dell'invio oppure si limiterebbe a suppore? lo script potrebbe non esistere sul mio server e dato che tutti i CMS come joomla o wordpress possono inviare tramite socket non ci sarebbe cmq traccia qualora fosse stato usato un socket non del mio server (anche se questa cosa vorrei prima verificarla perché non ne sono del tutto sicuro...)

L'unica cosa certa sarebbe di loggare tutto il traffico scambiato dalla porta 25 (SMTP) e della porta 465 (SMTPS) ... è corretto il mio pensiero?

Inoltre poiché mi è stato detto di aver inviato virus (SPAM 9999) dovrei verificare se Clamav fa già questo tipo di verifica sulla porta SMTP / SMTPs .

PS Ho trovato un documento su questo sito risalente al Marzo 2011 riguardante la possibilità di attivare l'antispam e l'antivirus per la posta in uscita : http://www200.pair.com/mecham/spam/

bago
16.12.2013, 21.39
Uno script php (o altro che giri sui tuoi server) può aprire socket verso i server destinatari senza bisogno di usare il comando mail e in quel caso non vedi niente nei log. Ovviamente potresti aver bloccato l'uso di socket su php, in questo caso effettivamente diventerebbe più improbabile un abuso del server.

emanuelebruno
16.12.2013, 12.18
Purtroppo è un braccio di ferro... loro sono convinti che io abbia mandato queste email:

64.136.44.45 - 853982599.20131205055733@juno.com
64.136.44.45 - 658060373.20131205055736@juno.com
64.136.52.45 - 577762165.20131205055736@juno.com
64.8.71.119 -132641392.20131205055741@wideopenwest.com
64.136.44.45 - 991568770.20131205055743@juno.com

Il problema è che io non ne ho traccia;

ipotesi 1: forse sono state mandate da un sito web (CMS) o attraverso un script in php hanno usato phpmail o sendmail... Cosa *IMPOSSIBILE* perché ne avrei avuta traccia nei log su /var/log/mail.log;
ipotesi 2: forse mi hanno hackerat l'email di qualche cliente con un brute-force sasl... anche in questo caso è *IMPOSSIBILE* perché io non gestisco i domini/dns di juno e wideopenwest e non sono comunque presenti/configurati nel mio sistema (utilizzo ispconfig):
ipotesi 3: forse c'è un account tipo root con cui qualcuno è entrato, ha inviato la mail con virus, ha alterato i file log e poi si è scollegato... anche in questo caso però facendo una lista degli utenti c'è solo 1 utente root che sono io...
ipotesi 4: forse il mio server fa da relay per lo spam ? credo proprio di no, almeno da questa analisi non è venuto fuori nulla: http://mxtoolbox.com/SuperTool.aspx?...4&run=toolpage
ipotesi 5: forse nel mio sistema è presente un qualche root-kit? sembrerebbe di no, almeno secondo RKHunter ...

quale altra ipotesi è possibile fare? perché OVH è convinta che io abbia mandato queste dannate email?
e se anche pagando €80,00 può OVH dire : purtroppo non è stato trovato nulla sul suo server ma il VAD non può sbagliare quindi mi dispiace ma dobbiamo così bloccarti l'ip?

Secondo me c'è qualcosa che non torna...

albert
16.12.2013, 09.14
,, la cosa grottesca e' che noi veniamo bloccati senza avere nessuna responsabilita' ...... ma tutte le nostre macchine ricevono una quantita' industriale di spam quotidiano che ovh fa' entrare tranquillamente ... qualcuno puo' svelarmi l'arcano'?

albert
13.12.2013, 18.55
ciao emanuele, anche noi siamo incappati in questo problema causato da codice malevolo presente in uno dei siti ospitati. Pensavamo di aver risolto ma ahime' e' risuccesso ed ovh ci ha segato la porta 25 per 30 giorni (!). Posso capire che un cliente ovh sia poco attento e fa poso o nulla per risolvere il problema .. ma noi che abbiamo fatto tutto il possibile (e lo stiamo facendo tutt'ora) per evitare questi problemi ... ci sanzionano con un blocco di 30 giorni. Praticamente tutti i clienti che ho su quella macchina smettono di lavorare. Non e' eccessivo 30 giorni? Sa' di squalifica. Sarebbe opinabile il blocco della porta per 1 ora e basta in modo tale di dare la possibilita' di curare il problema senza dover perdere i clienti.

Alberto

emanuelebruno
13.12.2013, 13.49
Purtroppo l'odissea continua: OVH è certa che ho mandato spam (pagando €80,00 un tecnico è disponibile ad entrare nel mio server e a dimostrare che un virus/trojan/exploit/ecc.. si è impossessato del mio sistema e che quindi le email spam con virus sono uscite dal mio server senza che i log abbiano potuto tenere traccia della cosa anche perché sicuramente c'è stato un hacker che magari ha potuto cancellare i log);

A questo punto sono più convinto che mai che la cosa non può fermarsi qui... Vi terrò informati su quanto sta accadendo.

matteoweb
13.12.2013, 10.13
Offerta Flash OVH - Speciale Natale
Spam
x


OVH.IT pagalba@ovh.lt tramite bnc.mailjet.com
18:21 (15 ore fa)

a info

Fai attenzione a questo messaggio. Diverse persone hanno contrassegnato messaggi simili come spam. Ulteriori informazioni

Le immagini non sono visualizzate. Visualizza immagini sottostanti


-----------------------------------------


Chissà se si autobloccano i server. pure loro..... che idiozia!

emanuelebruno
12.12.2013, 17.39
Ciao a tutti,
non avevo ancora letto tutte queste email riguardo l'argomento... Anche io sono vittima del blocco della porta 25 su di un mio indirizzo IP; peccato che contrariamente a quanto riportato da quelli che hanno partecipato alla discussione, nei miei file /var/log/mail.log non ho trovato traccia dei Message-ID che il sistema VAD ha identificato come spam (la ricerca è stata fatta nei file log che precedevano le 24 ore dalla segnalazione);

Da qui la mia domanda: se il sistema VAD è in grado di identificare lo spam perché semplicemente non lo blocca invece di bloccare gli ip dei clienti?

Questione più importante: dato che questo problema sembrerebbe *IRRISOLVIBILE* l'unica è soluzione è quella di cambiare gestore oppure è plausibile spostare il server mail su una propria linea ADSL?

Utilizzo ISPConfig da diversi anni e so per certo che è possibile gestire solo la parte relativa al server mail in un altro server; quindi ho pensato: dato che possiedo un contratto ADSL 15 MBPS in download e 1 MBPS in upload con IP statico, sarebbe auspicabile spostare solo il traffico mail sulla mia ADSL?

Al momento non supero le 3000 email al giorno.

Ringrazio anticipatamente per le risposte.