OVH Community, your new community space.

Server IRC


Takel
02.05.2011, 13.15
Citazione Originariamente Scritto da torpado
Un riferimento per verificare la situazione che riporti ? grazie
Salve,
quale tipo di riferimento necessita??
nickhandle?? ip server?? numero ticket?? o cosaltro??

Se son questi li debbo dare qui?? o gli servono in pm??
mi dica lei

Cordiali Saluti

torpado
02.05.2011, 10.12
Citazione Originariamente Scritto da Takel
Salve,
leggendo nel forum ho visto questo post e nn posso fare a meno di dire la mia per altro poi che la cosa è recente accaduta circa ieri..

...
cordiali saluti
Un riferimento per verificare la situazione che riporti ? grazie

Takel
01.05.2011, 15.41
Citazione Originariamente Scritto da torpado
Ho chiesto di indicarmi qualche dettaglio (es: nome server, ticket, nic-handle) per poter verificare l'errore e comunicarlo a chi di dovere per evitare in assoluto che riaccada.
edited:

Sono riuscito a verificare la situazione per il server di cui parli: è stato messo in hack state, per gli scan effettuati verso l'esterno (i logs ti sono stati forniti nel ticket #344678). Gli scan sulla rete Ovh sono proibiti, quindi:

- ti hanno bucato la machina -> ovh richiede reinstallazione obbligatoria
- dipendono da un tuo errore di configurazione/scripts/stc. -> lo dimostri all'interno del ticket, Ovh ti riapre il server in rescue mode in modo da applicare le correzioni
Salve,
leggendo nel forum ho visto questo post e nn posso fare a meno di dire la mia per altro poi che la cosa è recente accaduta circa ieri..
a me è successa la stessa cosa.. identica son stato vittima di un attacco ddos forte con punte di 988mb/s, ho chiesto al supporto se era possibile bloccare tutto il traffico UDp perche da log vedevo iptables droppare tutti i pacchetti udp, dopo il non aver risposta mi vedo il server in rescuemode e da OVH mi viene detto che tale situazione è quando un server è sotto attacco, per altro nel post è aggiunta l voce server hakc, quando di hack nn era proprio almeno da cio che ho potuto vedere con i miei mezzi..
quindi il recuemode se nn sbaglio è solo per farti recuperare i dati dal server per poi procedere al format che secondo me è inutile nel mio caso perche oggi ho il server nella stessa condizione di come era prima.. iptables, ecc ecc ma guarda caso l'attacco nn c'è piu nn per il format ma perche son riuscito a capire chi attaccava e per vie traverse hanno smesso..

la risposta dal team ovh era questa e unica:
Dear Customer,

Following the issue of hacking, I invite you to correct the

problem in rescue mode to be able to start normally.
Otherwise it is also possible to make a backup of your
data and reinstall the OS.
Following several monitoring alerts that have been
launched, we found that your server has undergone a
very important incoming attack.

For security reasons of our installations we have been
obliged
to add the server in the router protect.

So an ip protection is enabled on 188.xxx.xxx.xxx

Best Regards,
Cxxxxx S

Da cio che leggo (mi scusassero se interpreto male ma io parlo poco inglese giusto quello spicciolo)
si dice che devo trovare il problema (grazie) per poi far ripartire il server in modalita normale (che nn partiva perche bloccato)
o di procedere con un format ( era l'unica opzione disponibile)

INfine posso anche dire che nn è che ho preso il server e fatto partire cosi alla ceca, mi son fatto notti in bianco per settarlo a dovere, cambiato porte ai miei servizi da quelle standard, (ssh, ftp, ecc), uso password da 40 a 54 caratteri alfanumeriche, le cambio a random ogni 30/40gg, credo di aver settato iptables discretamente, ho dato l'accesso ai servizi di cui sopra solo al mio rangeip, bloccato i ping, portscan, tcp scan, udp scan, fin scan ecc ecc ecc...
l'unico problema nel mio server è stato quello di subire attacchi che saturavano la banda.

quindi la domanda è questa: se nell'ipotetico caso che una mattina uno si sveglia e voglia attaccarmi di nuovo che fa Ovh??'
mi chiude il sever o mi tutela??

che poi alla mia richiesta di poter chiudere tutto il traffico udp mi viene proposto che si puo fare a patto di acquistare pure il cisco asa con la piccola differenza di un setup di 180 euro piu 22 fisse al mese..
ottimo -.-

cordiali saluti

gio01
27.02.2010, 17.58
no comment

Marco
27.02.2010, 15.54
ekko ci mancava solo la spammata finale !
xo noto che la voglia di spammare si è spinta fino a farti registrare al forum !

velocità ?
mmmm meglio non approfondire la cosa
huahuahuhauhahuahuahuhuahu

GIOVY752
20.02.2010, 21.22
::edit::

torpado
26.01.2010, 19.02
Citazione Originariamente Scritto da Farfuglio
Bhe, ammetto la lentezza di OVH ma dopo 8 mesi si sarebbero notati gli scan, no?
non ho i dettagli del tuo caso, mi trovo in difficoltà a darti una spiegazione.
Comunque salvo oggi non significa salvo anche domani.
La preoccupazione di un bravo admin arriva fino all'indomani ed oltre.
Poi vorrei sapere come fa OVH ad essere tanto convinta che sul mio dedicato debba esserci per forza qualcosa di anomalo (per far valere i propri diritti a volte bisogna mentire).
Da Ovh eseguire uno scan verso un proprio server, interno od esterno che sia, non è anomalo, è vietato.
Poi tanto per chiarire OVH invece di mostrare i soliti log di presunti scan, dovrebbe dimostrare al cliente in che modo il dedicato risulta hackerato.
presunti? i logs loggano i dati di fatto non i presunti dati di fatto
Oltretutto molti dedicati effettuano scans verso l'utenza per verificare che non si tratti proxy, onde evitare fiumi di floddate.
eseguire scan può essere utile, ma è vietato nella rete Ovh. Per questo se lo scan è generato da chi lavora sul server lasciamo la possibilità di correggere.
Torpado, alla fine è OVH che pretende la menzogna, se nel mio dedicato non esiste nessun fantomatioco script, sono costretto ad inventarne uno per farmi restituire il dedicato.
Ovh non pretende la menzogna. E' chi la dice che non si preoccupa dell'eventuale conseguenza o non la capisce completamente e di questo certo non possiamo preoccuparci.

Farfuglio
26.01.2010, 18.22
Citazione Originariamente Scritto da torpado
il rischio di confermare ad Ovh: ok ho verificato e corretto, senza poi averlo fatto è di ripetersi nell'errore e avere il contratto chiuso definitivamente.
Bhe, ammetto la lentezza di OVH ma dopo 8 mesi si sarebbero notati gli scan, no?
Poi vorrei sapere come fa OVH ad essere tanto convinta che sul mio dedicato debba esserci per forza qualcosa di anomalo (per far valere i propri diritti a volte bisogna mentire).

Poi tanto per chiarire OVH invece di mostrare i soliti log di presunti scan, dovrebbe dimostrare al cliente in che modo il dedicato risulta hackerato.

Oltretutto molti dedicati effettuano scans verso l'utenza per verificare che non si tratti proxy, onde evitare fiumi di floddate.

Torpado, alla fine è OVH che pretende la menzogna, se nel mio dedicato non esiste nessun fantomatioco script, sono costretto ad inventarne uno per farmi restituire il dedicato.

torpado
26.01.2010, 18.10
Citazione Originariamente Scritto da Farfuglio
Stessa cosa successa a me circa 8 mesi fa...
sarò stato furbo io (o meno furbi quelli di OVH), ho controllato da cima a fondo il mio dedicato, nessun hackeraggio.
Quindi per levarmi dalle rogne ho fatto finta di aver trovato uno script in php sul mio server che prontamente ho provveduto ad eliminare (manco avevo un server web installato ).
Come per magia OVH mi ha restituito il dedicato così come lo aveva bloccato, dedicato che ho ancora e fa egregiamente il suo lavoro.
il rischio di confermare ad Ovh: ok ho verificato e corretto, senza poi averlo fatto è di ripetersi nell'errore e avere il contratto chiuso definitivamente.

Detto questo, mi pare evidente che qualcosa nel sistema di monitoring di OVH non funziona come dovrebbe.

Ora allacciandomi al discorso di cui sopra, resta il dubbio di come uno scan possa raggiungere quei picchi
Non ho detto che gli scan hanno raggiunto i picchi indicati da Marco (picchi di traffico in ingresso, ovvero il monitoring dell'attacco in ingresso).

Ho solo riportato una regola presente sul contratto per i server dedicati:
Non sono ammessi scan di nessun genere

Cercando di spiegare la motivazione della richiesta di reinstallazione (hack state):
è dovuta agli scan eseguiti a partire dal server di Marco verso l'esterno (come i logs che ho postato).

La situazione a questo punto direi che è chiara, no?

Farfuglio
26.01.2010, 18.00
Citazione Originariamente Scritto da torpado
Al momento stiamo offrendo questo tipo di protezioni hardware, contro attacchi:

- protezione router ovh => quando un attacco incoming arriva alla soglia dei 100Mbs la comunicazione del server viene filtrata fino a termine dell'attacco. La protezione viene rimossa automaticamente.

- protezione firewall Cisco ASA 5505 => a questo link i dettagli del servizio

Stiamo lavorando per offrire una protezione antiddos maggiore, ma non ho ancora i dettagli da pubblicare.
Scusami torpado, ma dai grafici postati da Marco, i picchi in ingresso mi sembrano ben superiori, quindi mi chiedo.... OVH cosa filtra?

Farfuglio
26.01.2010, 17.53
Stessa cosa successa a me circa 8 mesi fa...
sarò stato furbo io (o meno furbi quelli di OVH), ho controllato da cima a fondo il mio dedicato, nessun hackeraggio.
Quindi per levarmi dalle rogne ho fatto finta di aver trovato uno script in php sul mio server che prontamente ho provveduto ad eliminare (manco avevo un server web installato ).
Come per magia OVH mi ha restituito il dedicato così come lo aveva bloccato, dedicato che ho ancora e fa egregiamente il suo lavoro.

Detto questo, mi pare evidente che qualcosa nel sistema di monitoring di OVH non funziona come dovrebbe.

Ora allacciandomi al discorso di cui sopra, resta il dubbio di come uno scan possa raggiungere quei picchi

torpado
26.01.2010, 17.28
Citazione Originariamente Scritto da Marco
scusa e ,
ma prima dovete fare pace tra di voi
e fino a qui siamo d'accordo.
Ma cerca di capire ciò che ti scrivo =>

questi sono i logs degli scan partiti dalla tua macchina verso un altro server :

Start time End time src IP src hostname src port
dst IP dst port proto flags pkts bytes

2010-01-09 16:34:48 2010-01-09 16:34:51
94.23.** ns20***2.ovh.net 48424
94.161.144.102 4480 TCP 2 120

2010-01-09 16:34:49 2010-01-09 16:34:49
94.23.** ns20***2.ovh.net 33704
109.114.41.85 4480 TCP 1 60

2010-01-09 16:34:49 2010-01-09 16:34:49
94.23.** ns20***2.ovh.net 37535 93.68.34.57
4480 TCP 1 60

2010-01-09 16:34:56 2010-01-09 16:34:56
94.23.** ns20***2.ovh.net 33381
94.163.204.212 4480 TCP 1 60

2010-01-09 16:34:59 2010-01-09 16:34:59
94.23.** ns20***2.ovh.net 47403
93.48.86.180 4480 TCP 1 60

2010-01-09 16:35:03 2010-01-09 16:35:03
94.23.** ns20***2.ovh.net 40918
151.16.109.142 4480 TCP 1 60

2010-01-09 16:35:11 2010-01-09 16:35:14
94.23.** ns20***2.ovh.net 57651
109.114.19.128 4480 TCP 2 120

2010-01-09 16:35:22 2010-01-09 16:35:25
94.23.** ns20***2.ovh.net 34554 91.80.60.97
4480 TCP 2 120

2010-01-09 16:35:23 2010-01-09 16:35:26
94.23.** ns20***2.ovh.net 37769
94.163.158.135 4480 TCP 2 120

2010-01-09 16:35:27 2010-01-09 16:35:27
94.23.** ns20***2.ovh.net 48459
151.23.106.0 4480 TCP 1 60

2010-01-09 16:35:31 2010-01-09 16:35:31
94.23.** ns20***2.ovh.net 34008
151.23.87.122 4480 TCP 1 60

2010-01-09 16:35:30 2010-01-09 16:35:30
94.23.** ns20***2.ovh.net 54095 217.194.3.5
4480 TCP 1 60

2010-01-09 16:35:28 2010-01-09 16:35:31
94.23.** ns20***2.ovh.net 35110
94.161.119.228 4480 TCP 2 120

2010-01-09 16:35:28 2010-01-09 16:35:31
94.23.** ns20***2.ovh.net 60424
109.112.71.131 4480 TCP 2 120

2010-01-09 16:35:31 2010-01-09 16:35:31
94.23.** ns20***2.ovh.net 35270
94.163.48.71 4480 TCP 1 60

2010-01-09 16:35:29 2010-01-09 16:35:29
94.23.** ns20***2.ovh.net 37215
151.13.106.5 4480 TCP 1 60

2010-01-09 16:35:33 2010-01-09 16:35:33
94.23.** ns20***2.ovh.net 39408
151.95.174.169 4480 TCP 1 60

2010-01-09 16:35:32 2010-01-09 16:35:35
94.23.** ns20***2.ovh.net 58351
94.163.194.83 4480 TCP 2 120

2010-01-09 16:35:37 2010-01-09 16:35:40
94.23.** ns20***2.ovh.net 42539
94.161.131.180 4480 TCP 2 120

2010-01-09 16:35:37 2010-01-09 16:35:40
94.23.** ns20***2.ovh.net 48518
93.48.138.155 4480 TCP 2 120

2010-01-09 16:35:38 2010-01-09 16:35:41
94.23.** ns20***2.ovh.net 38279
151.16.84.61 4480 TCP 2 120

2010-01-09 16:35:40 2010-01-09 16:35:43
94.23.** ns20***2.ovh.net 51364
94.160.137.155 4480 TCP 2 120

2010-01-09 16:35:45 2010-01-09 16:35:48
94.23.** ns20***2.ovh.net 45131
151.95.253.172 4480 TCP 2 120

2010-01-09 16:35:46 2010-01-09 16:35:49
94.23.** ns20***2.ovh.net 39752
94.160.179.241 4480 TCP 2 120

2010-01-09 16:35:47 2010-01-09 16:35:50
94.23.** ns20***2.ovh.net 43935
94.163.138.12 4480 TCP 2 120

2010-01-09 16:35:47 2010-01-09 16:35:50
94.23.** ns20***2.ovh.net 44424
151.23.40.218 4480 TCP 2 120

2010-01-09 16:35:48 2010-01-09 16:35:51
94.23.** ns20***2.ovh.net 55774
93.69.49.201 4480 TCP 2 120

2010-01-09 16:35:49 2010-01-09 16:35:52
94.23.** ns20***2.ovh.net 54707
94.163.147.218 4480 TCP 2 120

2010-01-09 16:35:52 2010-01-09 16:35:52
94.23.** ns20***2.ovh.net 49848
81.29.187.179 4480 TCP 1 60

2010-01-09 16:35:59 2010-01-09 16:35:59
94.23.** ns20***2.ovh.net 60181
151.83.158.202 4480 TCP 1 60

Scan since 09/01 to 18/01
--------
Se da l tuo server parte uno scan: o ti hanno bucato o hai una configurazione sbagliata.

Il fatto che sei stato dossato non causa la chiusura della macchina, ma solo la sua protezione IP tramite router hardware ovh.

A causa degli scan Ovh, da contratto, può chiudere definitivamente il tuo server.
E' anche ovvio però che gli errori si fanno e le possibilità di correggere danno, da Ovh funziona così.

Marco
26.01.2010, 17.05
scusa e ,
ma prima dovete fare pace tra di voi,
prima erano gli altri che scannavano me adesso è il mio server che scanna gli altri ?
da ticket mi furono esposti dei log che non rappresentavano niente
mio ip, orario, data, porta, nomedel mio server
tt cio non rappresenta niente,
i log reali del accaduto sono stati incollati a tempo dovuto ed evidenziavano un dDoS
Spaccato del log che ho inviato sul ticket:

----------
Jan 16 11:58:19 ns208xxx kernel: FIREWALL logDrop: IN=eth0 OUT= MAC=00:1c:c0:1a:9a:0d:00:24:c3:84:04:00:08:00 SRC=70.32.79.67 DST=94.23.xxx.xxx LEN=8220 TOS=0x00 PREC=0x00 TTL=55 ID=17042 PROTO=UDP SPT=44630 DPT=5923 LEN=8200
----------
Jan 16 11:58:31 ns208xxx kernel: FIREWALL logDrop: IN=eth0 OUT= MAC=00:1c:c0:1a:9a:0d:00:24:c3:84:04:00:08:00 SRC=212.58.5.194 DST=94.23.xxx.xxx LEN=7684 TOS=0x00 PREC=0x00 TTL=56 ID=15664 PROTO=UDP SPT=59044 DPT=1744 LEN=7664
-----------
Jan 16 12:01:08 ns208xxx kernel: FIREWALL logDrop: IN=eth0 OUT= MAC=00:1c:c0:1a:9a:0d:00:24:c3:84:04:00:08:00 SRC=122.116.140.238 DST=94.23.xxx.xxx LEN=8220 TOS=0x00 PREC=0x00 TTL=115 ID=26548 PROTO=UDP SPT=59540 DPT=289 LEN=8200
-----------
Jan 16 12:11:34 ns208xxx kernel: FIREWALL logDrop: IN=eth0 OUT= MAC=00:1c:c0:1a:9a:0d:00:24:c3:84:04:00:08:00 SRC=85.13.135.12 DST=94.23.xxx.xxx LEN=8220 TOS=0x00 PREC=0x00 TTL=61 ID=28416 PROTO=UDP SPT=51856 DPT=4175 LEN=8200
-----------
pikkola parentesi il server e stato staccato proprio in questo lasso di tempo volendo andar di precisione il giorno 16 alle 12:16 mentre il log mostratomi sul ticket riguardava il giono 9 ben 7 giorni prima e devo dire che er trovarlo ci è voluto del tempo ! difatti ho aspettato 4 giorni per averlo forse si stava cercando un motivo diverso dalla realta a tutti i costi chissa



sarebbe bene imparare prima a leggere un log fatto con i iptables
e poi esprimere giudizi tanto fantasiosi (quello con le xxx è l'ip del mio server e non viceversa|)

... e non dimentichiamo che non sono l'unico ad essersi trovato in questa situazione!
poi però mi resta una curiosità, come fanno gli scan a generare picchi di traffico in ingresso fino a 500MB

diciamocela tutta, OVH non era in grado di mitigare 1 attacco ddos di quelle dimensioni, quindi ha preferito staccare il server e trovare una scusa.

il mio server non è stato bucato poi possiamo sempre dire che ''il papa è un gatto''
cmq storia chiusa non mi interessa avere ragione ne dimostrarlo ulteriormente, dato che so perfettamente come sono andate le cose, controllavo i log quotidianamente x bannare gli ip che dossavano la mia macchina e se ci fosse stato un hackeraggio lo avrei visto

torpado
26.01.2010, 14.48
Citazione Originariamente Scritto da Marco
si tratta di un errore, accertato, ma mi è stato detto: rivuoi il server? formattalo
Ho chiesto di indicarmi qualche dettaglio (es: nome server, ticket, nic-handle) per poter verificare l'errore e comunicarlo a chi di dovere per evitare in assoluto che riaccada.
edited:
Da foto si vede che il traffico e tutto in entrata se fosse stato bucato per logica sarebbe tt in uscita
evito di incollare anke i log una foto vale piu di mille parole !
Sono riuscito a verificare la situazione per il server di cui parli: è stato messo in hack state, per gli scan effettuati verso l'esterno (i logs ti sono stati forniti nel ticket #344678). Gli scan sulla rete Ovh sono proibiti, quindi:

- ti hanno bucato la machina -> ovh richiede reinstallazione obbligatoria
- dipendono da un tuo errore di configurazione/scripts/stc. -> lo dimostri all'interno del ticket, Ovh ti riapre il server in rescue mode in modo da applicare le correzioni

Marco
26.01.2010, 13.28
si tratta di un errore, accertato, ma mi è stato detto: rivuoi il server? formattalo

poi dato che ho speso 20 euro di telefono x chiamarvi 2 volte al giorno x una settimana credo che il server sia gia noto ! non credo sia necessario scrivere il nome del serv e del tiket !

x la cronaca ho chiesto rimborso
non è possibile perdere una settimana a spiegare il problema x poi sentirsi dire o si formatta o resta cosi ... si parlava di ''politiche aziendali'' ma come si dice?? la politica e solo un modo x fregare il prossimo!
se incollo il ticket mi sa che dovete ingrandire il forum sembra un romanzo a puntate senza contare le email mandate al supporto,
e avete fatto scarica barile a vicenda fra il supporto italiano e quello francese
per poi dirmi alla fine che se rivolevo il server, il supporto francese mi imponeva di formattare
voi del supporto italiano a parole mi avete confermato che non condividete la scelta del suporto francese
e qui pure ci sarebbe da ridire
in una stessa compagnia esistono 2 modi diversi di pensare/agire/operare
e questo disorienta il cliente..
morale della favola, ho perso una settimana di tempo (e di server inutilmente pagato) per farmi una bella chiacchierata con l'operatore di turno al supporto OVH

infine volevo fare un commento: a mio giudizio l'operatore che mi ha bloccato il dedicato in rescue-pro dopo un attacco dDoS e mi ha obbligato a reinstallare il server è un perfetto ignorante; un attacco dDoS non intacca minimamente la sicurezza del server l'uniko danno che crea e il saturare la banda x pochi secondi , poi in un log mi dice il server è stato scannato x noi quindi è ritenuto hackato, bhe anke su questoavrei da ridire allora mi basta aprire nmap e fare uno scan x far bloccare tt i server di ovh ?
scannare è un conto, il DoS ne è un altro , ma entrambe le cose di certo non sono prova che il server sia stato bucato !
un dos satura banda inviando pakketti sballati al ip del server se formatto mi cambia l'ip ? no, quindi l'attacco continua
poi x gli scan tt cio che si trova in rete viene scannato, uno scan si esegue mediante ip se formatto l'ip cambia ? no, quindi lo scan continua e poi, vorrei far presente che scannare non porta al bucaggio del dedicato, scanni vedi che ho la porta22 aperta e che te ne fai ? se non hai le pass non entri e se le sbagli 3 volte ti banno

in sintesi che qualkuno a sferrato attachi dDoS, e magari ha effetuato qualche scan nel tenatativo di bucarlo non lo metto in dubbio, ma ci è riuscito ? NO, xche non esistono log a riguardo ne anomalie varie, ne impieghi di banda anomali. Quindi il blocco del server non aveva senso, tt ciò che si trova sulla rete e sogetto a tentativi di hackeraggio ma se non vanno in porto non si perde di sicurezza, e bloccare un server costringendomi alla rienstallazione solo xche un pirla ci ha provato senza riuscirci mi sembra dare manforte all'attacante che cercava di bloccare i miei servizi in fine concludendo i servizi non li ha interrotti l'hacker ma OVH !

http://img718.imageshack.us/img718/7830/ddos.png
da foto si vede che il traffico e tutto in entrata se fosse stato bucato per logica sarebbe tt in uscita
evito di incollare anke i log una foto vale piu di mille parole !

non voglio dilungarmi troppo ma potrei continuare x ore

torpado
26.01.2010, 12.24
Citazione Originariamente Scritto da Marco
il mio tanto che è stato protetto che è stato bloccato x hack! bel modo di proteggere! di certo sta che quello protetto non so stato io
poi dopo il danno la beffa, sono stato obbligato ad una reinstallazione un attacco DoS non costituisce un bucaggio del server ''nei fatti reali '' poi se si vuol parlare di politiche possiamo dire anche che ''il papa è un gatto'' ma la realta restà sempre la stessa
Se così fosse c'è stato un errore, enorme. I server dossati vengono solo impostati sotto protezione router e non è richiesta reinstallazione.

Indica il nome del server oppure il numero del ticket, in modo da poterti dare la giusta motivazione, grazie.

Marco
26.01.2010, 12.01
il mio tanto che è stato protetto che è stato bloccato x hack! bel modo di proteggere! di certo sta che quello protetto non so stato io
poi dopo il danno la beffa, sono stato obbligato ad una reinstallazione un attacco DoS non costituisce un bucaggio del server ''nei fatti reali '' poi se si vuol parlare di politiche possiamo dire anche che ''il papa è un gatto'' ma la realta restà sempre la stessa

torpado
22.01.2010, 11.05
Citazione Originariamente Scritto da Marco
poi volevo approfittare della discussione x fare presente una cosa i server ovh non sono adatti a questo tipo d impiego x un semplice motivo non sono antidos ... spero che un giorno inventino qualkosa
vedo e molte farm hanno protezioni antidos una cosa simile su ovh non guasterebbe e la metterebbe sopra le altre come rapporto qualita prezzo e servizio offerto
Al momento stiamo offrendo questo tipo di protezioni hardware, contro attacchi:

- protezione router ovh => quando un attacco incoming arriva alla soglia dei 100Mbs la comunicazione del server viene filtrata fino a termine dell'attacco. La protezione viene rimossa automaticamente.

- protezione firewall Cisco ASA 5505 => a questo link i dettagli del servizio

Stiamo lavorando per offrire una protezione antiddos maggiore, ma non ho ancora i dettagli da pubblicare.

gio01
16.01.2010, 12.05
Citazione Originariamente Scritto da Marco
poi volevo approfittare della discussione x fare presente una cosa i server ovh non sono adatti a questo tipo d impiego x un semplice motivo non sono antidos ... spero che un giorno inventino qualkosa
vedo e molte farm hanno protezioni antidos una cosa simile su ovh non guasterebbe e la metterebbe sopra le altre come rapporto qualita prezzo e servizio offerto
queste cose le mettono a pagamento

Marco
16.01.2010, 11.59
poi volevo approfittare della discussione x fare presente una cosa i server ovh non sono adatti a questo tipo d impiego x un semplice motivo non sono antidos ... spero che un giorno inventino qualkosa
vedo e molte farm hanno protezioni antidos una cosa simile su ovh non guasterebbe e la metterebbe sopra le altre come rapporto qualita prezzo e servizio offerto

Marco
16.01.2010, 11.54
per creare un server irc ti serve anope per i servizi ed unreal ircd x tenere l'utenza cmq ti consiglio di installare anope ed unreal su una distribuzione nuda tipo debian x un server irc serve stabilita e la gui del desktop e un fronzolo inutile che va a discapito del affidabilità e della stabilita del network irc ...

user
14.01.2010, 17.04
apoc4l1pt0, hai risolto?
non e' facile installare e configurare sopratutto se non sei pratico di linux

vedi questa guida se ti e' utile:
https://help.ubuntu.com/community/IrcServer

apoc4l1pt0
31.12.2009, 14.30
Mi serveirebbe un aiutino per aprire un server IRc su ubuntu desktop, che programi devo usare? con linux mi trovo male lo sto usando da poco.... se mi date una mano ve ne sono grato