OVH Community, your new community space.

Protezione dagli attacchi DDoS


EvolutionCrazy
27.10.2013, 02.58
grafico è strano, confermo che anche a me sembrano megabytes/sec, mentre scala è megabit...

io invece ho dovuto forzare protezione attiva su una macchina dove c'erano attacchi che duravano poco (meno di 3 minuti) causavano disservizi e protezione si attivava troppo tardi

Supr
26.10.2013, 20.48
boh, so solo che le altre volte prima che si attivasse la mitigazione il server faceva in tempo a perdere la connessione col master server e tutti i player venivano disconnessi (e mi ritrovavo le varie lamentele) mentre ieri stranamente non è successo, inoltre lato iptables non mi è arrivato praticamente nulla da filtrare, solo pochi pacchetti (udp) dove il random src/dst coincidevano con quelli reali, ma proprio pochissima roba. L'ultima volta mi avevan tirato giù con udp spoofed, lenght 0 (no payload) targhettando le porte aperte.

Inoltre devo ancora capire che razza di grafico è visto che la scala sulla sinistra dice una cosa mentre se ti posizioni sui valori sembrano non corrispondere (a casa mia la b minuscola significa ancora bit, ma se poi uno si posiziona col cursore sulla punta della spike che dovrebbe corrispondere a 80Mbps viene fuori un 8 Mb/s)....

EvolutionCrazy
26.10.2013, 01.13
da me è sempre lenta rilevazione...

udp auth non saprei, non sembra droppare il primo ancora?

Supr
25.10.2013, 23.21
mmm sbaglio o è stato implementato qualcosa di nuovo? tipo il "famoso" udp auth (lol) su cui stavano lavorando? sicuramente è migliorato il tempo di risposta per la mitigazione automatica, stavolta per accorgermi di essere sotto flood son dovuto capitare sul managerv6 perchè dovevo variare una rule.

http://oct.imghost.us/Zpj2.jpg

Considerando che la ML è ufficialmente morta, per avere news a riguardo bisogna affidarsi a loltwitter?

EvolutionCrazy
12.10.2013, 15.07
ora basta ML e tutto viene gestito sul forum Francese moderato?

http://forum.ovh.com/forumdisplay.php?f=56

torpado
11.10.2013, 09.08
Citazione Originariamente Scritto da EvolutionCrazy
Comunque ha ancora senso restare iscritti alla ML e chiedere aiuto dopo che Oles ha postato sta cosa ieri sera (as usual in francese) o tutto il supporto ora viene fatto direttamente dal supporto come i normali servizi?
Si, resta di utilità, altrimenti avremmo chiuso la ML o comunque comunicato di non scrivere più

Il "denial of service" comunicativo, ne abbiamo esempi a non finire , ma non vedo novità in merito è un'"arte" vecchia come il mondo

Supr
10.10.2013, 23.38
in effetti....


Non disperiamo, anche se ha abbandonato la ML abbiamo il supporto tramite twitter xD

EvolutionCrazy
10.10.2013, 21.16
Comunque ha ancora senso restare iscritti alla ML e chiedere aiuto dopo che Oles ha postato sta cosa ieri sera (as usual in francese) o tutto il supporto ora viene fatto direttamente dal supporto come i normali servizi?

from: oles@ovh.net
reply-to: ddos@ml.ovh.net
to: ddos@ml.ovh.net
date: Wed, Oct 9, 2013 at 10:52 PM
subject: Re: [ddos] Re: Anti-spam.
mailed-by: ml.ovh.net

"depuis 2-3 ans je me demande presque chaque jour
comment je peux continuer a faire mon metier et
travailer le feedback de mes clients, tout
en evitant ce genre de vomis qui n'a rien a avoir
avec du feedback. je n'ai pas trouve de reponse
a cette question. mais j'ai fermement decide de
ne pas servir de levier pour les indigestions.
et pourtant j'ai demande que cette ml reste centree
sur le feedback technique. les mecs ne contiennent
pas leur haine et cherchent a s'incrire la ou je
suis pour me revomir dessus. c'est triste pour eux.

Da 2-3 anni mi chiedo quasi ogni giorno come posso continuare a
svolgere il mio lavoro e lavorare sui feedback dei miei clienti, tentando di evitare
commenti spiacevoli che non hanno nulla a che vedere con i feedback.
Non ho soluzioni a questo problema. Ma sono fermamente deciso a non farmi
condizionare da tutto questo. È per questo che ho richiesto che
questa mailing list continui a trattare soltanto argomenti tecnici.
Mi dispiace che alcuni soggetti non si siano limitati nell'esprimere le
loro opinioni con la dovuta educazione e francamente non sono disposto
a sopportare queste vessazioni. Trovo piuttosto che questo sia molto
triste, per loro.
"

unsub oles@ovh.net

torpado
10.10.2013, 10.23
Citazione Originariamente Scritto da EvolutionCrazy
Sì, lo so, e riesco anche a leggere francese.
non lo metto in dubbio, ma la versione in inglese è preferibile e comprensibile da più lettori del forum : è stata creata per questo motivo

EvolutionCrazy
10.10.2013, 09.58
Sì, lo so, e riesco anche a leggere francese.

Volevo solo appunto confermare che stable per ora nell'anti ddos non è ancora tutto...

torpado
10.10.2013, 09.17
Citazione Originariamente Scritto da EvolutionCrazy
fixed

Il sistema tasks incidente è disponibile anche in lingua inglese :

http://status.ovh.it/?do=details&id=5562

EvolutionCrazy
09.10.2013, 18.27
Citazione Originariamente Scritto da torpado
Il servizio Anti-DDoS base è stabile e funzionante.
per dovere di cronaca:
http://travaux.ovh.net/?do=details&id=9483

torpado
08.10.2013, 10.35
Citazione Originariamente Scritto da EvolutionCrazy
beta? Nell'ultima fattura (da settembre in poi) stiamo tutti pagando il servizio come stabile...

http://forum.ovh.it/showthread.php?t=5550

questa storia della ML mi sembra ormai poco attuale se realmente è una cosa stabile dovrebbe funzionare bene o comunque essere supportata con i metodi tradizionali e coperta da SLA...
Il servizio Anti-DDoS base è stabile e funzionante.

Anti-DDoS PRO, ovvero personalizzazione utente del servizio è ancora in fase di sviluppo

la ML non ha messaggi o richieste non risposte, non capisco quindi la tua percezione come "poco attuale"

EvolutionCrazy
08.10.2013, 10.10
beta? Nell'ultima fattura (da settembre in poi) stiamo tutti pagando il servizio come stabile...

http://forum.ovh.it/showthread.php?t=5550

questa storia della ML mi sembra ormai poco attuale se realmente è una cosa stabile dovrebbe funzionare bene o comunque essere supportata con i metodi tradizionali e coperta da SLA...

torpado
08.10.2013, 09.06
Citazione Originariamente Scritto da Supr
...
Una cosa strana, ho aggiunto la rule:
96 Refuse UDP all fragments In creation

qualche ora fa, ma mi rimane in creationpending
mailing list : ddos@ml.ovh.net :

Hi There,
If you have a trouble with
- the Anti-DDoS
- the Firewall Network
- the Anti-Spam
please send an email with:
- the service with the trouble
- the IP source and the IP destination that
have the trouble
- the traceroute from the IP SRC to the IP DST
showing the trouble
- 2 lines' description of the trouble
- sometimes we need to connect to your serveur
and check the trouble. please setup the ovh's ssh
key on your server and give the port of the ssh,
so we can troubleshoot the issue

nothing else is needed. no "blabla" is needed.

All emails without the essential technical
informations will be ignored.

Please don't send your trouble twice. All emails
are read and will be answered.

Regards,
Octave
I feedbacks trasmessi nella fase di beta test attualmente in corso ci permettono di affinare e correggere dove richiesto il nuovo sistema VAC

Grazie per la collaborazione

EvolutionCrazy
07.10.2013, 21.34
strano :d

Supr
07.10.2013, 18.27
Sto provando il setup che mi hai consigliato, anche se ai tempi pre tilera/arbor
anche droppando tutto in raw e senza conntrack il povero atom non ce la faceva ugualmente... forse ne avevam già parlato sul forum di hostingtalk italia (vedremo al prossimo ddos)

Una cosa strana, ho aggiunto la rule:
96 Refuse UDP all fragments In creation

qualche ora fa, ma mi rimane in creationpending

torpado
07.10.2013, 16.52
Citazione Originariamente Scritto da EvolutionCrazy
confermato che per Oles l'Italia non è in Europa insomma... quindi tale funzionalità per noi ha poco senso ad ora
Non si tratta di una lacuna ma piuttosto si tratta di una fase di test

EvolutionCrazy
07.10.2013, 16.41
confermato che per Oles l'Italia non è in Europa insomma... quindi tale funzionalità per noi ha poco senso ad ora

torpado
07.10.2013, 16.34
Citazione Originariamente Scritto da EvolutionCrazy
...
Se non sbaglio Oles nella ML aveva proposto qualcosa di simile ma che eprmette solo di limitare a traffico EU (e non vorrei sbagliarmi ma italia la considerava fuori)
Si, l'idea è quella appunto di creare profili per bloccare traffico per paese di provenienza (basato su IP GEO database) :

- Europa (per il momento ci sono FR,BE,NL,ES,GB,MA,BZ,TN)
- USA
- America Sud
- Asia

potendo creare un profilo misto di 2-3 paesi

EvolutionCrazy
07.10.2013, 15.53
ah beh... 300k pps su un atom non li puoi gestire (o comunque devi lavorare molto bene su iptables... di certo non in INPUT ... e non usando conntrack!!!)

e se è spoofed recent è inutile...

io fare ratelimiting usando hashlimit in "-t raw" con un --hashlimit-htable-expire molto basso (tipo 3000) e provando a veder quanto grande puoi mettere la maschera per ridurre falsi positivi... ( --hashlimit-srcmask 13 o inferiore se riesci )

Di solito quando ci sono udp flood conviene anche farsi attivare filtri in base a geo ip... o almeno così fanno alcune volte da seflow: scegli nazioni da cui vuoi ricevere traffico e il resto viene droppato...

Se non sbaglio Oles nella ML aveva proposto qualcosa di simile ma che eprmette solo di limitare a traffico EU (e non vorrei sbagliarmi ma italia la considerava fuori)

Supr
07.10.2013, 15.45
il problema è che le porte src sarebbero anche fisse per quanto riguarda l'udp ma ho notato che con alcuni provider (eg fastweb) non vengono rispettate, quindi mi perdevo un po' di utenza e ho dovuto cambiarla.

l'iptables non riesce a stare dietro a quello che filtra da questo attacco, pur facendo rate limiting.... (è un kimsufi scheda 10/100 e atom)

stasera provo a variare qualcosa, evitando di usare il recent (in questo modo se non sbaglio dovrei non utilizzare conntrack e alleggerire il carico)

ho aggiunto la rule per l'udp fragment sul tnf, ma credevo fosse scontata scegliendo udp refuse dopo aver messo in allow quello che mi serviva.

EvolutionCrazy
07.10.2013, 15.16
guarda il ttl... se erano spoofed di solito ttl è fisso e riesci a filtrare per bene solo con quello...

poi servirebbe un tcpdump completo... "Malformed Packet" fa pensare a udp frammentato... la regola per deny udp frammentato l'hai messa su firewall?

per questo genere di cose di solito vanno messe anche regole che restringono porta sorgente se il protocollo che usi lo permette e usa porte specifiche... ti aiuta a tagliare ulteriormente il traffico

Supr
07.10.2013, 14.55
si, dopo 20 min si sono "ripresi" sia il manager che l'interfaccia api

ora sto preparando la mail per la mailing list.

allego qua un po' di tshark di quello che è riuscito a passare (ovviamente avevo in allow sul tnf la 3333/3334 sia tcp che udp per 1 game server), magari qualcuno ha qualche consiglio
Codice:
 0.298271  39.61.50.68 -> 5.135.182.99 ENTTEC Source port: 33494  Destination port: 3333[Malformed Packet]
  0.302087 58.145.200.39 -> 5.135.182.99 ENTTEC Source port: 7108  Destination port: 3333[Malformed Packet]
  0.311196 fe80::264:40ff:fe3a:fac0 -> ff02::1:ff00:1 ICMPv6 Neighbor solicitation
  0.341630 58.105.84.115 -> 5.135.182.99 ENTTEC Source port: 60472  Destination port: 3333[Malformed Packet]
  0.371166 99.213.105.86 -> 5.135.182.99 ENTTEC Source port: 5233  Destination port: 3333[Malformed Packet]
  0.402665 fe80::da24:bdff:fe90:b0c0 -> ff02::66     HSRPv2 Hello (state Active)
  0.467317   47.90.7.97 -> 5.135.182.99 ENTTEC Source port: 7227  Destination port: 3333[Malformed Packet]
  0.526865 108.251.96.43 -> 5.135.182.99 UDP Source port: 14066  Destination port: 3334
  0.604512 125.86.46.77 -> 5.135.182.99 UDP Source port: 43634  Destination port: 3334

Gracias

torpado
07.10.2013, 14.48
Citazione Originariamente Scritto da Supr
BOOM, ci risiamo

server sotto ddos, Entrata : 399720.0 packet/s

il managerv6 mi da questo strano messaggio:



l'apiv6 ha deciso che il mio ip non esiste, anche solo facendo un get/ip


la mitigazione automatica immagino non sia partita perchè la macchina risulta irraggiungibile.
Questo è quello che risulta essere attivato sull'ip riportato =>

Firewall :
State ok
Forced true
Creation 2013-10-07 14:50:37+02

Mitigation :
State ok
Enabled true
Creation 2013-07-17 16:39:07+02
--

Segnala l'errore sulla mailing list al fine di poter verificare i dettagli nei logs API : ddos@ml.ovh.net

Supr
07.10.2013, 14.15
BOOM, ci risiamo

server sotto ddos, Entrata : 399720.0 packet/s

il managerv6 mi da questo strano messaggio:

It is not possible to manage the mitigation and network firewall for this IP. For more information, please contact our support team.
l'apiv6 ha deciso che il mio ip non esiste, anche solo facendo un get/ip
/ip/{ip}
{ "message": "The requested object (ip = 5.135.182.99) does not exist" }
la mitigazione automatica immagino non sia partita perchè la macchina risulta irraggiungibile.

EvolutionCrazy
03.10.2013, 18.22
ah ok, era un problema di connettività allora.

dalle 13:30 alle 14:00 seabone era KO, ma non solo verso OVH... presumilbmente hanno avuti problemi anche altri transit mi sa ...

Supr
03.10.2013, 16.42
bene, tra un po' provo a riattivarlo, ora non posso perchè ho troppa gente collegata.

x evcz: sul tnf avevo messo icmp in allow apposta e su iptables ho in allow le related/estabilished, ergo dovrebbe andare.

forse il traceroute non era la cosa + sensata da postare, mi spiegavo meglio se dicevo che non riuscivo a fare un ssh dal kimsufi in oggetto verso un altro server non di ovh.

Probabilmente è stato un problema temporaneo.

In ogni caso aggiorno appena riattivo il tnf.
Grazie

Edit: riattivato e tutto ok.

Kaos
03.10.2013, 16.14
Citazione Originariamente Scritto da Supr
oggi mi succede una cosa strana:

con il network firewall abilitato ho dei problemi di connessione dal server verso l'esterno :

Codice:
[root@ks3288958 ~]# traceroute maya.ngi.it
traceroute to maya.ngi.it (88.149.128.3), 30 hops max, 60 byte packets
 1  vss-9a-6k.fr.eu (5.135.182.253)  0.444 ms * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *^C

se lo disabilito funziona tutto:
Codice:
[root@ks3288958 ~]# traceroute maya.ngi.it
traceroute to maya.ngi.it (88.149.128.3), 30 hops max, 60 byte packets
 1  vss-9a-6k.fr.eu (5.135.182.253)  0.771 ms * *
 2  rbx-g1-a9.fr.eu (91.121.131.155)  1.219 ms  1.429 ms  1.414 ms
 3  * * *
 4  * * *
 5  vl-3604-ve-228.csw2.London1.Level3.net (4.69.166.157)  19.410 ms vl-3602-ve-226.csw2.London1.Level3.net (4.69.166.149)  19.364 ms vl-3604-ve-228.csw2.London1.Level3.net (4.69.166.157)  19.355 ms
 6  ae-57-222.ebr2.London1.Level3.net (4.69.153.133)  19.277 ms ae-59-224.ebr2.London1.Level3.net (4.69.153.141)  19.363 ms ae-56-221.ebr2.London1.Level3.net (4.69.153.129)  19.262 ms
 7  ae-23-23.ebr2.Frankfurt1.Level3.net (4.69.148.194)  19.459 ms ae-22-22.ebr2.Frankfurt1.Level3.net (4.69.148.190)  19.409 ms  19.341 ms
 8  ae-62-62.csw1.Frankfurt1.Level3.net (4.69.140.18)  19.309 ms ae-92-92.csw4.Frankfurt1.Level3.net (4.69.140.30)  19.538 ms ae-82-82.csw3.Frankfurt1.Level3.net (4.69.140.26)  19.247 ms
 9  ae-91-91.ebr1.Frankfurt1.Level3.net (4.69.140.13)  19.386 ms ae-61-61.ebr1.Frankfurt1.Level3.net (4.69.140.1)  30.078 ms  21.101 ms
10  ae-1-14.bar2.Milan1.Level3.net (4.69.142.193)  19.524 ms  19.491 ms  19.462 ms
11  ae-0-11.bar1.Milan1.Level3.net (4.69.142.189)  19.399 ms  19.269 ms  19.301 ms
12  212.73.241.14 (212.73.241.14)  19.713 ms  19.684 ms  19.675 ms
...
per il momento ho disattivato il TNF, a qualcun'altro succede?
È successo anche a me improvvisamente oggi pomeriggio, l'ho disabilitato e vaff ahah. Ora riabilitandolo sembra ok.

EvolutionCrazy
03.10.2013, 14.12
credo sia normalissimo se non hai in allow gli ICMP entranti... hai configurato tu il firewall? posta lista completa delle regole in caso.....

Supr
03.10.2013, 13.33
oggi mi succede una cosa strana:

con il network firewall abilitato ho dei problemi di connessione dal server verso l'esterno :

Codice:
[root@ks3288958 ~]# traceroute maya.ngi.it
traceroute to maya.ngi.it (88.149.128.3), 30 hops max, 60 byte packets
 1  vss-9a-6k.fr.eu (5.135.182.253)  0.444 ms * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *^C

se lo disabilito funziona tutto:
Codice:
[root@ks3288958 ~]# traceroute maya.ngi.it
traceroute to maya.ngi.it (88.149.128.3), 30 hops max, 60 byte packets
 1  vss-9a-6k.fr.eu (5.135.182.253)  0.771 ms * *
 2  rbx-g1-a9.fr.eu (91.121.131.155)  1.219 ms  1.429 ms  1.414 ms
 3  * * *
 4  * * *
 5  vl-3604-ve-228.csw2.London1.Level3.net (4.69.166.157)  19.410 ms vl-3602-ve-226.csw2.London1.Level3.net (4.69.166.149)  19.364 ms vl-3604-ve-228.csw2.London1.Level3.net (4.69.166.157)  19.355 ms
 6  ae-57-222.ebr2.London1.Level3.net (4.69.153.133)  19.277 ms ae-59-224.ebr2.London1.Level3.net (4.69.153.141)  19.363 ms ae-56-221.ebr2.London1.Level3.net (4.69.153.129)  19.262 ms
 7  ae-23-23.ebr2.Frankfurt1.Level3.net (4.69.148.194)  19.459 ms ae-22-22.ebr2.Frankfurt1.Level3.net (4.69.148.190)  19.409 ms  19.341 ms
 8  ae-62-62.csw1.Frankfurt1.Level3.net (4.69.140.18)  19.309 ms ae-92-92.csw4.Frankfurt1.Level3.net (4.69.140.30)  19.538 ms ae-82-82.csw3.Frankfurt1.Level3.net (4.69.140.26)  19.247 ms
 9  ae-91-91.ebr1.Frankfurt1.Level3.net (4.69.140.13)  19.386 ms ae-61-61.ebr1.Frankfurt1.Level3.net (4.69.140.1)  30.078 ms  21.101 ms
10  ae-1-14.bar2.Milan1.Level3.net (4.69.142.193)  19.524 ms  19.491 ms  19.462 ms
11  ae-0-11.bar1.Milan1.Level3.net (4.69.142.189)  19.399 ms  19.269 ms  19.301 ms
12  212.73.241.14 (212.73.241.14)  19.713 ms  19.684 ms  19.675 ms
...
per il momento ho disattivato il TNF, a qualcun'altro succede?

MrWorldWide
13.09.2013, 16.21
Messaggio eliminato.

torpado
13.09.2013, 11.45
Citazione Originariamente Scritto da MrWorldWide
Il firewall configurabile dalle API entra anche quello in funzione solo in seguito ad attacchi DDoS?
Altra domanda: perchè pur essendo attiva la mitigazione, nel traceroute non compaiono le righe del VAC ma compaiono solo effettivamente quando avviene l'attacco?
Grazie
Il VAC è composto di numerose strutture. Ognuna realizza un'azione specifica.

Il firewall entra in funzione in base alle regole impostate.
E' inoltre ora possibile gestire il firewall direttamente dallo spazio cliente e non più solo via API

Per quanto riguarda mitigazione : dipende dal profilo server in uso, dall'utilizzo professionale e dall'impostazione assegnata alla mitigazione (forzata o automatica)

Inoltra un traceroute di esempio al supporto per verificare. grazie

dprima
13.09.2013, 11.44
Ti consiglio di consultare quest'altra discussione,
dove ci sono ulteriori informazioni a tal proposito

MrWorldWide
12.09.2013, 20.52
Il firewall configurabile dalle API entra anche quello in funzione solo in seguito ad attacchi DDoS?
Altra domanda: perchè pur essendo attiva la mitigazione, nel traceroute non compaiono le righe del VAC ma compaiono solo effettivamente quando avviene l'attacco?
Grazie

azrael666x
09.09.2013, 16.06
Se avete problemi nel funzionamento dell'antiddos, dovete inviare un traceroute al supporto in modo da verificare se è attivo o no.

Se avete problemi nel funzionamento delle API invece, dovete iscrivervi alla mailing list apposita e chiedere informazioni, fornendo dati dettagliati sul malfunzionamento.

MrWorldWide
09.09.2013, 11.02
Da me no, con un vecchio 8G...

EvolutionCrazy
09.09.2013, 00.10
sì *per ora* mi funzionano ancora anche sui kimsufi e anche senza utilizzo professionale (appena messo un kimsufi2g da 2.99euro/mese sotto mitigazione permanente)

MrWorldWide
08.09.2013, 21.11
Citazione Originariamente Scritto da EvolutionCrazy
il server va offline quando non c'è l'antidos (i primi 2 minuti), se non vuoi che vada offline basta che forzi l'antidos (mitigation) sempre attivo
Ciao,
se hai dei Kimsufi, sai dirmi se ti vanno le API per la mitigazione con questi?
Grazie

EvolutionCrazy
08.09.2013, 20.39
il server va offline quando non c'è l'antidos (i primi 2 minuti), se non vuoi che vada offline basta che forzi l'antidos (mitigation) sempre attivo

Swordself
08.09.2013, 20.04
Citazione Originariamente Scritto da EvolutionCrazy
è illimitata nel senso che dura per tutta la durata dell'attacco...

il problema è che viene staccata dopo 15 minuti che è terminato l'attacco... quindi "basta" che facciano tanti attacchi piccoli e ti possono tenere offline 2 minuti ogni 15
sono un pò ignorante in materia
fatemi capire, se uno ti attacca il server, lo manda offline..
anche con l'antidos, il server va offline per bloccare l'attacco.
Quindi, a cosa serve il vac?

EvolutionCrazy
08.09.2013, 19.02
è illimitata nel senso che dura per tutta la durata dell'attacco...

il problema è che viene staccata dopo 15 minuti che è terminato l'attacco... quindi "basta" che facciano tanti attacchi piccoli e ti possono tenere offline 2 minuti ogni 15

Swordself
08.09.2013, 18.58
Citazione Originariamente Scritto da EvolutionCrazy
una volta mitigazione veniva staccata dopo 26ore, ora invece dopo 15minuti.

rilevamento sicuramente è molto più lento rispetto ad altre realtà.
Confermo che in meno di 120 secondi qua non succede nulla... da seflow per sempio invece bastano 5 secondi e i filtri si attivano... Oles diceva che con il tempo miglioreranno anche i tempi di invervento anche su ovh... vedremo

Vedremo se le cose cambiano... nel frattempo ti serve l'opzione pro se vuoi mitigazione sempre attiva
ma la durata della protezione non dovrebbe essere illimitata anche con l'opzione di mitigazione di default?

EvolutionCrazy
08.09.2013, 17.39
una volta mitigazione veniva staccata dopo 26ore, ora invece dopo 15minuti.

rilevamento sicuramente è molto più lento rispetto ad altre realtà.
Confermo che in meno di 120 secondi qua non succede nulla... da seflow per sempio invece bastano 5 secondi e i filtri si attivano... Oles diceva che con il tempo miglioreranno anche i tempi di invervento anche su ovh... vedremo

Vedremo se le cose cambiano... nel frattempo ti serve l'opzione pro se vuoi mitigazione sempre attiva

MrWorldWide
08.09.2013, 13.28
Capisco che per la mitigazione permanente ci vuole l'opzione PRO, ma dagli ultimi attacchi ricevuti ho potuto constatare dal traceroute che si attiva solo 2 minuti dopo gli attacchi e che si disattiva troppo presto quindi basta distanziarli un po' nel tempo gli attacchi, per rendere inaccessibile il server.
Tra l'altro non si possono manco usare le API con i Kimsufi perchè non me lo riconoscono come server dedicato :S

Acidflame
07.09.2013, 23.28
Non sono solo 1 o 2 euro,

Come annunciato in precedenza, il prezzo dell'opzione "Utilizzo Professionale" sugli EG e sugli MG passa da 15€ al mese a 30 € al mese.
Sono 17 euro al mese + iva in più praticamente è come se noleggiassi un server in più.

devilrox
02.08.2013, 10.47
Grazie mille Octave per la chiarezza delle informazioni e per il servizio che state e che offrirete in futuro.

Lasciamo perdere i commenti di quelli che si lamentano per un 1 euro extra in cambio di un servizio così, sono persone probabilmente che non hanno la benché minima idea di cosa voglia dire dal punto di vista sistemistico affrontare un attacco dosnet e cosa comporta in termini di costi avere il proprio sito commerciale down.

GRAZIE OVH!

azrael666x
08.07.2013, 11.28
Citazione Originariamente Scritto da Analytic
Mi pare che abbiano detto che per chi ha già pagato l'aumento non verrà applicato fino alla fine del periodo, se sei in quel caso sei "protetto", altrimenti puoi decidere di non rinnovare.
Confermo.

Analytic
08.07.2013, 11.04
Citazione Originariamente Scritto da ardyp
Abbiate pazienza, ma il rispetto del cliente viene prima di ogni cosa e voi non sapete proprio cosa sia, sinceramente non ordinerò mai più nulla da ovh data la bassissima considerazione che mostrate.
.
Mi pare che abbiano detto che per chi ha già pagato l'aumento non verrà applicato fino alla fine del periodo, se sei in quel caso sei "protetto", altrimenti puoi decidere di non rinnovare.

Il fatto di non essere vincolati per un periodo prefissato permette di cambiare facilmente fornitore se trovi delle tariffe migliori o un servizio migliore, sugli eventuali aumenti giustamente fanno quello che ritengono opportuno.

azrael666x
08.07.2013, 09.26
Potrei anche essere d'accordo con ardyp se l'aumento fosse stato dell'ordine dei 10 € minimi, ma vista la variazione ti chiedo: preferisci lasciare che OVH si occupi della protezione dei tuoi server pagando qualche euro in più, oppure preferisci che il tuo (o i tuoi) server possa essere bersaglio di attacchi e rischiarne la chiusura?
Dal mio punto di vista, preferisco non dovermi preoccupare del secondo aspetto e pagare qualche euro in più a server.

Acidflame
05.07.2013, 18.26
Diciamo che a differenza degli IP failover dove tutti i provider hanno marciato. La protezione DDOS aumenta di un minimo il costo del server, ma almeno stai tranquillo e i tuoi clienti stanno tranquilli. C'è stato un investimento in infrastruttura e sinceramente per davvero così poco non c'è da fare troppa polemica anzi è un servizi in più utile e molto ben accetto

ardyp
25.06.2013, 18.04
Prima l'aumento per gli ip failover, ora per la protezione, nell'ultimo anno avete arbitrariamente modificato le condizioni economiche per ben 2 volte (di pochi spicci ok, ma è il concetto che conta), sapendo che per i clienti è una rottura enorme di @@ dover disdire/spostare una macchina in produzione magari attiva da anni...magari tra 2 mesi aumenterete ancora perchè avete avuto un rincaro sulla bolletta elettrica...

Abbiate pazienza, ma il rispetto del cliente viene prima di ogni cosa e voi non sapete proprio cosa sia, sinceramente non ordinerò mai più nulla da ovh data la bassissima considerazione che mostrate.

Buon proseguimento.

oles@ovh.net
25.06.2013, 11.56
Ciao a tutti!

In quanto fornitore di infrastrutture internet, OVH si confronta da sempre con attacchi informatici di tipo DDoS,
sia sulle sue infrastrutture che su quelle dei clienti. Dalla fine del 2010 con l'affare Wikileaks, i DDoS sono saliti agli onori
della cronaca e, considerata la diffusione del DNS AMP dall'inizio del 2013, qualsiasi ragazzino può lanciare in rete decine
di Giga e mettere in pericolo un'attività.
Dal canto nostro, nel tempo abbiamo sviluppato degli strumenti di protezione con uno scopo molto semplice:
il servizio di protezione anti-DDoS non può essere opzionale.
Al contrario, i clienti devono approfittare di questo servizio offerto di default!

Da 3-4 mesi lavoriamo su un nuovo tipo di infrastruttura di protezione contro i DDoS che abbiamo chiamato "VAC".
VAC come "vacuum", come il vacuum cleaner, l'aspirapolvere. Mettiamoci un po' di fantasia e immaginiamo di
passare l'aspirapolvere sul traffico proveniente da internet verso i vostri servizi e di aspirare i pacchetti "cattivi"
conservando solo quelli "buoni". :-)
Il VAC1, attualmente in versione Alpha, è stato installato a Roubaix.
Ormai funziona abbastanza bene da consentirci di spiegare quello che OVH proporrà a proposito delle protezioni dai DDoS.
Abbiamo pianificato l'aggiornamento alla versione Beta questa settimana.
Il 16 luglio il servizio VAC verrà descritto sul nostro sito e sarà disponibile un nuovo contratto
concernente questo servizio.
L'obiettivo è di essere chiari e di fornire tutte le garanzie possibili.

Hardware
--------
Il VAC è un'unità di mitigazione che può filtrare fino a 160Gbps / 160Gpps di traffico.

E' composto da due router, un Cisco ASR 9001 e un Cisco Nexus 7009. In totale, su un VAC,
sono presenti 114 porte da 10GB per 1.14 Tbps di capacità di switching/routing. Per la pulizia del traffico
utilizziamo due tipi di hardware: 4 Tilera da 20 Gbps ciascuno (80 Gbps tot) e un TMS 4000 da 30 Gbps.

Lo sviluppo software sui Tilera è assicurato dalle nostre squadre interne. Si tratta di un codice C/C++ a basso livello,
con gestione delle code e degli algoritmi che determina se un pacchetto è legittimo o se non lo è. TMS 4000 è un contenitore di
algoritmi sviluppati da Arbor.
Il traffico viene aspirato all'ingresso di un datacenter, filtrato e poi indirizzato verso i router delle varie sale.
Nel caso di VAC1, aspiriamo il traffico al livello dei due principali router di Roubaix e poi lo facciamo passare attraverso
5 step di pulizia. Ogni step pulisce un tipo di attacco con lo scopo di diminuirne la portata e passare poi allo step successivo.
E' grazie a questi 5 step che siamo in grado di trattare fino a 160Gbps di materiale laddove i nostri concorrenti utilizzano invece
un TMS 4000 Arbor con una scheda da 10 Giga e riescono a filtrare al massimo 10 Giga in totale.
Se ricevete attacchi troppo consistenti il contratto viene sciolto e siete costretti a cercare un altro provider di hosting.
E' in questo momento che interveniamo noi, non essendoci limiti nella dimensione degli attacchi che riusciamo a gestire.

Funzionalità
---------------
Con un VAC, possiamo fornirvi questi servizi:
- firewall di rete
- mitigazione degli attacchi DDoS
- scelta del tipo di mitigazione
- mitigazione permanente
- detection di un attacco e attivazione della mitigazione
- supporto per aiutarvi in caso di attacco

Un VAC si occupa anche dell'aspirazione degli attacchi che il nostro sistema può generare. Infatti, a volte i clienti vengono
infettati dai server utilizzati per lanciare attacchi. Nel momento in cui scopriamo un attacco, li aspiriamo comunque sul VAC,
in modo da pulire tutto nell'attesa di scoprire quali sono i server hackerati, che poi verranno messi in modalità rescue.

Il VAC è utile anche nella lotta contro lo spam.
Il VAC, infatti, aspira e duplica il "traffico email uscente" di un datacenter per farlo analizzare da un anti-spam e da un anti-virus.
Possiamo avere le statistiche del numero di spam da IP SRC nei nostri datacenter e poi bloccare il flusso SMTP
di un IP se sospettato di essere spammer. Un VAC non archivia i dati, è un analizzatore di traffico:
non ci sono delle email archiviate ma soltanto l'analisi in tempo reale di un campione di email che escono dai nostri datacenter.

E in più, oltre a aspirare, il VAC vi stira anche le camicie! ahah... sto scherzando ;-)

Ridondanza
----------
La ridondanza di un VAC è realizzata da un altro VAC. Prima della fine di agosto,
installeremo 3 unità di mitigazione VAC in 3 datacenter:
- a Strasburgo (SBG)
- a Roubaix (RBX)
- a Beauharnois (BHS)

I 3 VAC funzioneranno in parallelo e ogni VAC aspirerà il traffico più vicino per filtrarlo e poi reindirizzarlo sulla rete
interna che abbiamo installato fra tutti i datacenter.
Così, un attacco che arriva da Miami (in Florida) verrà intercettato da Beauharnois, filtrato dal VAC3 e poi il traffico
entrerà nella rete interna per poi passare da Gravelines, Roubaix e arrivare per esempio a Strasburgo verso il server
vittima dell'attacco DDoS.

La capacità totale dei nostri 3 VAC è di 3x160Gbps cioè 480Gbps/480Mpps. E' la più imponente infrastruttura di mitigazione
conosciuta che un fornitore mette a disposizione dei suoi clienti.

Conseguenze
-----------
Il servizio di protezione non è limitato né in termini di taglia, di durata che di tipo di attacco.
Possiamo gestire qualsiasi attacco, il nostro obiettivo è di fornirvi un servizio che vi protegge davvero,
nel caso in cui foste vittima di un attacco.

La questione non è "Ne ho davvero bisogno?" ma, piuttosto, "Mi proteggerà in caso di attacco?"

La settimana scorsa un cliente mi ha contattato d'urgenza perché il suo sito era stato attaccato da un ragazzino.
3 clic più più tardi, l'attacco passava attraverso il VAC1 e il suo sito http://www.prestashop.com tornava disponibile. Ogni giorno riceviamo fino a 1200 attacchi e proteggiamo in media 700 di voi, ovviamente non
sempre gli stessi...

Servizi
-------
Offriremo 3 livelli di servizio:

- di default, incluso nel prezzo, il cui scopo è di proteggere la nostra infrastruttura e il servizio del cliente in modalità "best effort"

Infatti, per proteggere in modo adeguato un'infrastruttura da un attacco, è necessario sapere quali servizi svolge il server per
scegliere la giusta configurazione della mitigazione.
Senza contatto umano con il cliente, non possiamo che attenerci al "best effort". E' il livello di servizio che offriamo di default

- con l'opzione PRO potrete fare un po' di "bricolage" adattando voi stessi la protezione con il vostro manager o l'APIv6.
Vi offriamo questi strumenti:

- firewall di rete da 480Gbps con la possibilità di attivare 100 linee ACL per IP DST, un'innovazione OVH

- scelta tra diverse decine di tipi di mitigazione tra web, smtp, game, teamspeak, streaming etc.

- la mitigazione permanente o l'attivazione della detection di un attacco con passaggio automatico sul VAC

- supporto su mailing list ddos@ml.ovh.net

- con il supporto VIP, avrete a disposizione 24h/24 l'aiuto di una persona sulla configurazione + qualcuno con cui parlare
durante un attacco, per farvi aiutare a configurare rapidamente ed efficacemente la giusta protezione per bloccare l'attacco.
Il team VIP assicura il monitoring dell'attacco 24h/24 e adatta la protezione se l'attacco cambia.

Prezzo
----
Nel periodo in cui sarà disponibile la versione Alpha, abbiamo comunicato che una protezione contro gli attacchi DDoS deve essere un servizio
incluso nel prezzo di un server, di un VPS, di un pCI, di un pCC o di una connessione ADSL.

Siamo stati molto sorpresi nel leggere la domanda "Quanto costa?"

Questo ci ha fatto riflettere... molto.

Dopo aver riflettuto abbiamo avuto 3 scelte:

- fare come tutti, quindi proporre un servizio di mitigazione a un prezzo abbastanza alto,
stabilendo che la capacità della mitigazione dipende dal prezzo e che in tutti i casi c'è un limite di 10 o 20 Gbps (!!!)
Limitare il tutto alla durata dell'attacco (!!!) e far pagare di più se si vuole di più (!!!)
In sostanza un servizio à la carte, non incluso nel prezzo e abbastanza limitato: il modello di business standard dei
nostri concorrenti e dei fornitori di soluzioni di mitigazione.

- fare "il minimo sindacale", investire cioè in una infrastruttura (si parla di 3 milioni di euro) e poi non includere il costo della mitigazione
nel prezzo di ogni servizio. Semplicemente offrire il servizio ma non le infrastrutture che lo sostengono, non mettendo a disposizione
squadre disponibili 24h/24, sperando che sia abbastanza se arrivasse il giorno X

- abbiamo scelto una terza strada: suddividere i costi dei VAC e delle squadre di supporto su tutti i clienti presenti e futuri che ospitiamo
sulle nostre infrastrutture. In questo caso si parla di un'azione obbligatoria per tutti i server dedicati esistenti, tutti i VPS e tutti i pCC.
Ma come spesso capita si tratta di numerosi clienti, quindi l'aumento di prezzo è decisamente limitato:
- VPS: +0.5€/mese
- KS: +1€/mese
- SP: +1€/mese
- EG: +2€/mese
- MG: +2€/mese
- HG: +3€/mese
- pCC: +5€/mese
- housing: +10€/mese

Questo aumento di prezzo di tutti i server esistenti e futuri ci permetterà di continuare a investire nell'infrastruttura e di migliorare
per poter far fronte ai nuovi attacchi.
Sarà applicato a partire dal primo settembre 2013. per i server già in uso. Tuttavia, in caso di pagamento annuale, OVH offrirà la
protezione anti-DDoS, mantenendo il prezzo invariato.

Si va da +0.5€/mese a +10€/mese. Può sembrare poco rispetto ai costi del servizio anti-DDoS che i nostri concorrenti propongono.
Potete anche dire che non possiamo proporre un servizio di protezione contro i DDoS di qualità a un prezzo così basso.
Con il numero di clienti che abbiamo e grazie alla suddivisione dei costi e degli investimenti, ci sentiamo totalmente a nostro agio nel proporci
come punto di riferimento nella lotta agli attacchi e di potervi proteggere se arriverà il fatidico giorno X.

Un saluto da amico,
Octave