[bago]

per google conta il dominio e non l'IP.. quindi dipende da cosa hai messo nel record IN A del dominio che viene indicizzato da google.

Per il pagerank l'IP non conta niente.

Non c'è niente di dimostrato ma sembra che google tenga in considerazione l'IP nel momento in cui la lingua è equivocabile. Ad esempio l'inglese è usato negli stati uniti, in inghilterra e in australia. Google dovrebbe usare l'IP per stabilire la vicinanza dei contenuti ad un certo paese. La maggior parte degli esperti SEO sostiene che per un sito in italiano su dominio .it l'appartenenza di un IP ad una certa nazione non conta assolutamente nulla. Alcuni sostengono che quello che conta è la latenza dai datacenter vicini alla nazione di riferimento.

Il fatto è che non c'è nulla di certo, di certo però c'è che esistono siti indicizzati benissimo in italiano con IP straniero e hosting americano e sono primi in classifica.. quindi se *veramente* conta sicuramente è solo uno di tanti fattori.

[ibanez89]

Ah, e quindi fammi capire bene: google tiene conto di dove si trova l'ip per il pagerank? Questo è buono a sapersi cazzo!

e sopratutto se hai due ip, quello del server francese e il failover italiano che puntano entrambi sul server web, google quale usa quello a cui è intestato il dominio con il record A o dico una cantonata?

[j0t]

Si, al cliente servivono ip italiani per il positionamento su Google.

Ah, e quindi fammi capire bene: google tiene conto di dove si trova l'ip per il pagerank? Questo è buono a sapersi cazzo!

[torpado]

Li ho sotto controllo io. Uno è un mailserver che gira su Win2003SRV2 con firewall attivo, l'altro un debian (con firewall iptables attivo) con 2 webserver statici.. tutto quà.

Al momento non riesco però ad accedere a questi guest, perchè si trovano sul disco 2 del server, che non è leggibile tramite il FTP Rescue Mode.

Non appena contattati abbiamo attivato il rescue mode sulla macchina per non bloccare l'accesso ai dati secondari. Hai prontamente rimesso la macchina in produzione e lo scan si è ripetuto, questa volta verso la porat 53.

Sto aspettando che OVH mi ridà il server. Così potrò fare il backup dei guest vmware .. poi reinstallo l'host.. e attivo il logging di iptables, almeno se poi succede un'altra volta che OVH mi mette in offline, avrò dei logfiles anch'io.

Dai log di OVH non si vede niente:
non si vede quanti pacchetti sono stati inviati, nè di che genere: UDP o TCP.

startime endtime scr-port dst-port => vengono inseriti nella email di hack inviata

Poi non riesco a capire come il mio server dovrebbe creare un DOS faccendo partire pacchetti di 46bytes ogni 2-3 secondi.

OVH dovrebbe rivedere queste cose.

Stiamo cercando una soluzione che ci permetta di bloccare i contenitori virtuali senza bloccare l'accesso principale. Non sempre abbiamo l'accesso alla macchina perchè la chiave OVH può essere disabilitata dall'utente.

Ho avuto parecchi problemi con OVH:
- per poter utilizzare gli ip aggiuntivi (fail over) in un guest vmware devi farti un bel pò di workaround finchè ti funziona, documentazione da OVH: non si trova, supporto da OVH: scarso
- poi mi hanno cambiato gli IP da "italiano" in "portoghese", ho perso un fatturato di 3.000eur annuale per questo... neanche una SCUSA da OVH mi è arrivato
- poi adesso mi buttono giù il server, dicendo che faccio DDOS (caso mai un DOS, visto che il src-ip è sempre lo stesso, e non vari distributed)

Può anche essere che il host o un guest è stato bucato, ma se è così OVH deve anche collaborare a rimettere su il server.

Abbiamo collaborato per rimettere la macchina a tua disposizione, nonostante i 3 hack consecutivi

Ho una decina di vmware hosts in giro. Fino ad adesso ho perso tanto tempo quà con OVH, avuto tante rogne.
L'unica cosa per la quale sono ancora cliente, è l'IP italiano che ho (di nuovo).

Spero che domani OVH mi ridà il server.

[sdi]

Sono curioso: in che modo il fatto che l'IP sia italiano o portoghese fa perdere o meno 3000 euro di fatturato? Problemi di immagine?

Si, al cliente servivono ip italiani per il positionamento su Google. OVH senza preavviso ha cambiato l'ip attribuitomi da italiano in portoghese. Il cliente mi ha mandato disdetta e una lettera dal suo avvocato con richiesta danni, visto che esplicitamente ha richiesto hosting su IP italiano.

Solo per questo motivo ho perso un server con OVH, altrimenti potrei essere rimasto dove stavo già benissimo con tutti gli altri server.

[ibanez89]

Sono curioso: in che modo il fatto che l'IP sia italiano o portoghese fa perdere o meno 3000 euro di fatturato? Problemi di immagine?

Posizionamento in google immagino

[j0t]

- poi mi hanno cambiato gli IP da "italiano" in "portoghese", ho perso un fatturato di 3.000eur annuale per questo... neanche una SCUSA da OVH mi è arrivato

Sono curioso: in che modo il fatto che l'IP sia italiano o portoghese fa perdere o meno 3000 euro di fatturato? Problemi di immagine?

[gio01]

invito l'utente a moderarsi o lo farò bannare ... garzie

[bago]

Il fatto che configurare bene il failover con vmware sia complicato mi sembra offtopic. Il server è unmanaged e quindi è normale che su queste cose OVH sia inesistente.

Piuttosto mi sembra interessante approfondire quali strumenti abbiano i clienti OVH per verificare per quale motivo sono stati tagliati fuori dalla rete e per assicurarsi di essere rimessi online in fretta. Al momento non ho capito molto di quello che è successo ma se effettivamente sdi ha un vmare come rilasciato da OVH ed ha su delle vmware e OVH l'ha "spento" e dato l'accesso FTP e basta allora direi che sdi non è che possa fare molto visto che da ftp non vede nemmeno i dischi delle macchine virtuali e non può fare altri controlli... però dprima ha scritto che ti è anche stata data la rescue-pro: con quella non sei riuscito a vedere qualcosa di più?

Certo che se effettivamente la macchina la gestisci tu e basta e dalla macchina sono partiti pacchetti "strani" verso la porta 80 di un server russo forse qualcosa di strano c'è. Un mailserver windows e 2 webserver statici non fanno nulla di tutto ciò...

[sdi]

ma mettere una password hai gust no vero?

traduzione?

Che vuoi sapere?
Se ho messo una password? Dove?

[sdi]

@Sdi: hai tu il controllo dei guest o sono nelle mani di altri?

Li ho sotto controllo io. Uno è un mailserver che gira su Win2003SRV2 con firewall attivo, l'altro un debian (con firewall iptables attivo) con 2 webserver statici.. tutto quà.

Al momento non riesco però ad accedere a questi guest, perchè si trovano sul disco 2 del server, che non è leggibile tramite il FTP Rescue Mode.

Sto aspettando che OVH mi ridà il server. Così potrò fare il backup dei guest vmware .. poi reinstallo l'host.. e attivo il logging di iptables, almeno se poi succede un'altra volta che OVH mi mette in offline, avrò dei logfiles anch'io.

Dai log di OVH non si vede niente:
non si vede quanti pacchetti sono stati inviati, nè di che genere: UDP o TCP.

Poi non riesco a capire come il mio server dovrebbe creare un DOS faccendo partire pacchetti di 46bytes ogni 2-3 secondi.

OVH dovrebbe rivedere queste cose.

Effettivamente questo apre un bel campanello d'allarme per chi pensa di fare una infrastruttura con dedicati di OVH per rivendere macchine virtuali...

Ho avuto parecchi problemi con OVH:
- per poter utilizzare gli ip aggiuntivi (fail over) in un guest vmware devi farti un bel pò di workaround finchè ti funziona, documentazione da OVH: non si trova, supporto da OVH: scarso
- poi mi hanno cambiato gli IP da "italiano" in "portoghese", ho perso un fatturato di 3.000eur annuale per questo... neanche una SCUSA da OVH mi è arrivato
- poi adesso mi buttono giù il server, dicendo che faccio DDOS (caso mai un DOS, visto che il src-ip è sempre lo stesso, e non vari distributed)

Può anche essere che il host o un guest è stato bucato, ma se è così OVH deve anche collaborare a rimettere su il server.

Ho una decina di vmware hosts in giro. Fino ad adesso ho perso tanto tempo quà con OVH, avuto tante rogne.
L'unica cosa per la quale sono ancora cliente, è l'IP italiano che ho (di nuovo).

Spero che domani OVH mi ridà il server.

[sdi]

c'è fai ddos e nn te ne rendi conto?

furbetto: sai la differenza tra "DDOS" e "DOS"?

[gio01]

ma mettere una password hai gust no vero?

[bago]

@gio01: le botnet sono costituite di milioni di computer che fanno DDOS e dei quali i legittimi proprietari/amministratori non sono a conoscenza. E' molto più frequente che un DDOS parta da macchine "hackate" che da macchine di proprietà.

Non ho idea di come funzioni il monitoring di OVH, ma non credo che si basi su un singolo pacchetto "sospetto": più probabilmente avranno delle soglie.

Comunque se la macchina di sdi ha un vmware consegnato da OVH senza modifiche è più probabile che i pacchetti in questione siano partiti dai guest.

@Sdi: hai tu il controllo dei guest o sono nelle mani di altri?

Effettivamente questo apre un bel campanello d'allarme per chi pensa di fare una infrastruttura con dedicati di OVH per rivendere macchine virtuali...

[gio01]

c'è fai ddos e nn te ne rendi conto?

[bago]

sì, sicuramente OVH vede solo i pacchetti, non sa se poi son partiti dall'host o dai guest, e in fondo non credo faccia alcuna differenza.

escluderei anche che syslogd possa aver creato quei pacchetti diretti al server russo.

[sdi]

I casi sono due:
- sai che cosa è successo alle 4.37 di quel giorno perchè eri tu che facevi prove (magari provavi un programma senza renderti conto di cos'era?)
- sei all'oscuro di tutto: un server configurato come OVH te lo da non crea quei pacchetti e quindi la cosa più probabile è che il tuo server sia stato hackato e che venga usato per fare DDOS verso il mondo o per far parte di botnet...

beh, nei logs non trovo niente di strano, unica cosa che vedo è che è attivo syslogd. Io non l'ho installato, ma forse viene preinstallato da OVH insieme all' image vmware? Visto che non è documentato da OVH cosa viene installato con quell'image, adesso non saprei dire.

Su questo server girano 2 vmware guests su un installazione standard dell' immage OVH Vmware. Se è davvero partito qualcosa da questo server (come dice OVH), potrebbe essere partito anche da un'ip failover = da un guest vmware. Questi al momento non li posso controllare, perchè il server è offline e non riesco ad accedere ai miei dati.

[j0t]

j0t: se sei così furbo, cosa ti dice questo?

startime endtime scr port dst port:
2009-03-25 04:37:19 2009-03-25 04:37:26 91.121x.x:35792 86.125.252.17:80
2009-03-25 04:37:26 2009-03-25 04:37:29 91.121.x.x:35792 86.125.252.17:80
2009-03-25 04:37:29 2009-03-25 04:37:30 91.121.x.x:35792 86.125.252.17:80
2009-03-25 04:37:30 2009-03-25 04:37:49 91.121.x.x:35792 86.125.252.17:80

spiegami un po':

SCR PORT = source e port, e come puoi vedere l'host SORGENTE è il tuo

[bago]

la mail parla di DDOS con pacchetti da 46bytes. Immagico che il 91.121.x.x sia l'IP del tuo server e che loro abbiano individuato dei pacchetti "anomali" (tipicamente usati per fare DDOS o portscan) che partivano dalla tua macchina ed erano indirizzati ad un server web (86.125.252.17).

In pratica OVH non solo ti segna se fai portscan/dos verso loro macchine ma più in generale se lo fai verso qualunque indirizzo internet.

I casi sono due:
- sai che cosa è successo alle 4.37 di quel giorno perchè eri tu che facevi prove (magari provavi un programma senza renderti conto di cos'era?)
- sei all'oscuro di tutto: un server configurato come OVH te lo da non crea quei pacchetti e quindi la cosa più probabile è che il tuo server sia stato hackato e che venga usato per fare DDOS verso il mondo o per far parte di botnet...

Io inizierei col guardare /var/log/messages per vedere cosa dice nell'intorno di quella data...

[sdi]

j0t: se sei così furbo, cosa ti dice questo?

startime endtime scr port dst port:
2009-03-25 04:37:19 2009-03-25 04:37:26 91.121x.x:35792 86.125.252.17:80
2009-03-25 04:37:26 2009-03-25 04:37:29 91.121.x.x:35792 86.125.252.17:80
2009-03-25 04:37:29 2009-03-25 04:37:30 91.121.x.x:35792 86.125.252.17:80
2009-03-25 04:37:30 2009-03-25 04:37:49 91.121.x.x:35792 86.125.252.17:80

spiegami un po':

[j0t]

ormai su internet basta aprire un servizio su qualunque porta che prima o poi entro qualche ora ti arriva qualche programmino che tenta di connettersi anche senza mai aver condiviso le info di connessione con qualcuno; ma questo non vuol dire assolutamente che un sistema sia stato hackato (ovvero che un utente che non sia amministratore legittimo ha ottenuto l'accesso come admin).

Guarda che dprima ha detto che lo scan è partito DALLA tua macchina... È normale che uno scan parta da fuori, ma che parta dalla tua macchina no...

[flavio]

Dato che per noi, uno scan, è motivo di sospettare che la macchina può esser stata attaccata,
a maggior ragione se Lei non ne è a conoscenza
e/o se non ha neanche la capacità di trovare le motivazioni del perchè è stato fatto questo scan,
non credo che ci sia niente di strano nel sospendere temporaneamente il server in via preventiva.

...e secondo voi 4 accessi in 11 secondi, come da log, sono uno scan? e, cosa ancor più importante, vi sembra normale sospendere il servizio senza neanche comunicarlo PREVENTIVAMENTE all'amministratore?
Ma poi, da quando in quà uno scan di porte e motivo sufficente per dire che un sistema è hackato? ormai su internet basta aprire un servizio su qualunque porta che prima o poi entro qualche ora ti arriva qualche programmino che tenta di connettersi anche senza mai aver condiviso le info di connessione con qualcuno; ma questo non vuol dire assolutamente che un sistema sia stato hackato (ovvero che un utente che non sia amministratore legittimo ha ottenuto l'accesso come admin).

[dprima]

RicordandoLe che nella prima email che Le abbiamo inviato,
Le è stato fatto presente che, dalla modalità rescue-ftp,
non è possibile accedere al proprio spazio di backup-ftp

Le confermo che, in modalità rescue-ftp, effettivamente non ha accesso al secondo disco
(disco che ha partizionato dopo aver smontato la configurazione RAID
con cui Le è stato consegnato il server).

Le ricordo però, che una volta che Le abbiamo riavviato il server in modalità rescue-pro,
(per la quale Le sono state inoltrate tramite email le nuove credenziali per accedervi)

potrà Lei stesso montare il secondo disco ( http://guida.ovh.it/ModeRescue )
e recuperare i dati di cui ha bisogno direttamente dalla modalità rescue-pro.


Dato che per noi, uno scan, è motivo di sospettare che la macchina può esser stata attaccata,
a maggior ragione se Lei non ne è a conoscenza
e/o se non ha neanche la capacità di trovare le motivazioni del perchè è stato fatto questo scan,
non credo che ci sia niente di strano nel sospendere temporaneamente il server in via preventiva.

In ogni caso, una volta montato il secondo disco,
avrà sicuramente a disposizione tutti i suoi log,

potrà così verificare se dalla sua macchina è partito o meno lo scan in questione,
potrà altresì dimostrare la sua capacità di mettere in sicurezza la macchina.

[sdi]

mai ho detto che su questo server è collegato un disco in USB.

Vi ho detto da subito che non riesco accedere al secondo disco (sdb1) tramite l'account ftp che mi avete dato o allo spazio ftp-backup su ftp5backup.ovh.net

Reinstallerò il server (che mi chiede ca. 2 gg. di tempo), e attiverò il logging con iptables, almeno avrò `poi la possibilità di controllare quello che mi state dicendo, avendo dei logfiles a disposizione.

4 righe di logfiles (verso lo stesso IP, verso la porta 80): non mi sembra il caso di disattivare un srv operativo di un vs. cliente per questo.

Che il server è stato hackato lo state dicendo Voi .. da questo log.
Come Vi permettete di dire questo?

A me non risulta.

[dprima]

Premesso che non è la prima volta che questo server viene segnalato come HACKED,

voglio precisare che la disattivazione temporanea del server,
è garanzia del fatto che sulla nostra rete è costantemente attivo un sistema di monitoraggio
utile ad individuare quelle macchine che possono potenzialmente presentare delle falle di sicurezza.

Tuttavia, Le è stato comunque notificato tramite email,
il perchè la sua macchina è risultata come potenzialmente pericolosa (HACKED),
altresì Le è stata comunque data la possibilità di chiarire il tutto
al fine di ripristinare il server.

In ogni caso, al primo contatto telefonico Le è stato fatto presente che,
nella modalità in cui era stato inizialmente riavviato il server (rescue-ftp),
avrebbe avuto di sicuro la possibilità di recuperare i dati di cui non aveva creato un backup
prima di procedere ad un'eventuale reinstallazione del server.

Ma, vista la sua impossibilità di accedere ad un disco USB,
a seguito ulteriori verifiche, Le è stato fatto presente che dai nostri sistemi
non risultava ci fossero dischi USB aggiuntivi installati.

Una volta chiarito che il disco USB a cui si riferiva in prima battuta,
non era altro che il secondo disco partizionato in seguito all'aver smontato la configurazione RAID
con cui il server Le è stato consegnato di default,

abbiamo provveduto a riavviare il server in rescue-pro, al fine di darle la possibilità
di montare il disco a cui si riferiva e recuperare i dati di cui aveva bisogno.

http://guida.ovh.it/ModeRescue

Ricordando che il servizio da noi offerto è un servizio UNMANAGED
e che è comunque nostro interesse dare la possibiltà di risolvere qualsiasi tipo di problema,

ricordo che da questa modalità, l'utente stesso, può comunque provare a risolvere il problema.

Se il cliente riesce quindi a dimostrarci che il problema è stato risolto,
comunicandoci i dettagli tramite ticket-incidente, potremo riavviare il server in modalità normale
senza l'obbligo di dover reinstallare il sistema operativo.

[sdi]

Salve,

oggi mi trovo un email da OVH:

Disattivazione del Vostro server ns12345.ovh.net causa SCAN

Notre support vous a envoyé un message.
Vous pouvez en prendre connaissance ci-dessous.
Utilisez ce lien pour y répondre, n'utilisez pas la fonction "répondre"
de votre logiciel de messagerie.

Cordialement, l'équipe Ovh

http://www.ovh.com/fr/support/suppor...2&level=answer

------------
http://www.ovh.it
OVH Srl Via Trieste 25, 20097 San Donato Milanese Supporto tecnico e commerciale: +39.02.5271784 (costo a seconda dell'operatore)
Fax: +39.02.5272584
supporto@ovh.it



Buongiorno,

Abbiamo dovuto disattivare in urgenza il Vostro server dedicato ns352815.ovh.net al fine di bloccare un attacco. Sembra che il Vostro server presenti una falla di sicurezza oppure che un utente male intenzionato abbia ottenunto l'accesso.

Il Vostro server è attualmente in una modalità che permette di accedere ai Vostri dati tramite FTP (i codici di accesso Vi saranno inviati per email).
Potete richiedere la reinstallazione completa del sistema dal Vostro manager.

Se desiderate riprendere possesso sul Vostro server al fine di eliminare l'origine dello SCAN, dovete contattare i nostri servizi.


--------------------------- LOGS DE SCAN ---------------------------

DDOS attacks with 46bytes pkts

startime endtime scrort dstort
----------------------------------------------------------------------------------------------
2009-03-25 04:37:19 2009-03-25 04:37:26 91.121x.x:35792 86.125.252.17:80
2009-03-25 04:37:26 2009-03-25 04:37:29 91.121.x.x:35792 86.125.252.17:80
2009-03-25 04:37:29 2009-03-25 04:37:30 91.121.x.x:35792 86.125.252.17:80
2009-03-25 04:37:30 2009-03-25 04:37:49 91.121.x.x:35792 86.125.252.17:80


--------------------------- FIN DES LOGS ---------------------------



Supporto Cliente OVH
Dal lunedì al venerdì: dalle 9.30 alle 13 e dalle 14 alle 18.30


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

Poi secondo email:

[ns12345.ovh.net] Accesso ai dati del Vostro server

http://www.ovh.it
OVH Srl Via Trieste 25, 20097 San Donato Milanese Supporto tecnico e commerciale: +39.02.5271784 (costo a seconda dell'operatore)
Fax: +39.02.5272584
supporto@ovh.it



Buon giorno,

il Vostro server è riavviato in modalità speciale al fine di permetterVi di recuperare i Vostri dati.

Disponete di un accesso FTP in sola lettura ed ecco i parametri per l'utilizzo:
- nome utente : rootftp
- password : xxxx
Supporto Cliente OVH
Dal lunedì al venerdì: dalle 9.30 alle 13 e dalle 14 alle 18.30

Quindi OVH mi butta giù un server operativo con 3! Vmware guests su, specificando solamente che entro 11 secondi ci sono stati 4 accessi dalla mia port 35792 alla porta 80 (=HTTP / WEB) di un singolo IP?

Ma che motivazione è questa?

Ho già parlato 2 volte con OVH italia. Domenico mi diceva che devo riformattare il server e che mi invia documentazione -- che però dopo 80 minuti non mi è arrivato niente. Il secondo operatore mi diceva che stanno facendo controlli in francia, e che devo aspettare..

Non mi possono dire, ne quanto devo aspettare, ne cosa stanno controllando etc..

Mi dicono che devo provare io perchè il mio server ha fatto questi 4 accessi verso quell'ip! Ma come si fa?

Con questo account FTP NON RIESCO ad accedere ai dati che stanno sul hd2 del mio server, visto che viene soltanto montato durante il boot del server.
Quindi i dati che stanno sul disco2 sono persi (sono 400GB disco virtuale vmware).

Devo proprio dire che in tutti i 12 anni da quando gestico server non ho mai avuto a fare con una società come OVH. Mai con un' altro gestore mi è successo che mi è stato messo offline un server, senza spiegazioni, e senza possibilità di accedere ai dati.