Bekijk Volledige Versie : RedUnix down (again)?
Is het weer zover? We hebben daar nog een server staan (wel alle echt belangrijke zaken gelukkig weggehaald na de laatste keer), maar deze is nu onbereikbaar. Geldt ook voor redunix.nl zelf.
Iemand info?
ResellerPlanet
16/09/10, 15:41
Hier hetzelfde. Net naar Fred proberen te bellen, bezettoon...
Wij hebben in ieder geval niets afgesloten, ligt dus niet aan ons.
Kippenijzer
16/09/10, 15:47
Lijkt erop dat ATN-Networks en Kronos hun AS-sen op het moment niet routeren? (Traceroute naar redunix.nl, ip-phone.nl geven geen route)
Even voor de goede orde toch met het Qweb Webhostingtalk account.
Wij hebben Redunix niet afgesloten, dus ligt niet aan ons.
Ons a.u.b. niet bellen, alvast bedankt.
Blijkbaar verbruiken enkele server ATM erg veel dataverkeer waardoor de routers en switches het niet bij kunnen benen. Zou zsm opgelost moeten zijn.
robvanderpol
16/09/10, 15:52
inderdaad, net fred aan de lijn gehad. Blijkbaar was er iets gehackt daardoor het dataverkeer enorm toegenomen is. Echter vertelde fred mij dat het alweer onder controle was aan die kant, en dat nu enkel de buffers weer leeg moesten lopen. Dit zou minder als 15 minuten moeten duren (5 min geleden)
Even voor de goede orde toch met het Qweb Webhostingtalk account.
Wij hebben Redunix niet afgesloten, dus ligt niet aan ons.
Ons a.u.b. niet bellen, alvast bedankt.
Dit is ff nieuw voor mij, is RedUnix nu van jullie afhankelijk?
ResellerPlanet
16/09/10, 15:54
inderdaad, net fred aan de lijn gehad. Blijkbaar was er iets gehackt daardoor het dataverkeer enorm toegenomen is. Echter vertelde fred mij dat het alweer onder controle was aan die kant, en dat nu enkel de buffers weer leeg moesten lopen. Dit zou minder als 15 minuten moeten duren (5 min geleden)
Is het normaal dat een datacenter daar volledig van down gaat?
Ik wil maar zeggen, Fred heeft het altijd over z'n kasten van switches die je niet alleen van de grond heft. Ik kan me voorstellen dat als 1 servertje gehacked is en een outgoing packet flood doet dat dit geen volledige downtime mag bezorgen...
Is het normaal dat een datacenter daar volledig van down gaat?
Een goed datacenter? Nee. RedUnix? Blijkbaar wel.
Wellicht dat deze man er meer van weet?? Aangezien er weer een bericht op zijn site staat...
http://www.produtch.nl/
robvanderpol
16/09/10, 15:57
Is het normaal dat een datacenter daar volledig van down gaat?
Ik wil maar zeggen, Fred heeft het altijd over z'n kasten van switches die je niet alleen van de grond heft. Ik kan me voorstellen dat als 1 servertje gehacked is en een outgoing packet flood doet dat dit geen volledige downtime mag bezorgen...
geen idee, ik heb er verder weinig verstand van, maar dit is wat hij mij vertelde.
Wellicht dat deze man er meer van weet?? Aangezien er weer een bericht op zijn site staat...
http://www.produtch.nl/
Zonder al te veel aandacht aan die man te willen besteden, zou hij nou zelf ook niet doorhebben dat het een beetje triest is om op die manier klanten te werven en ten twee who in his right mind zou als hij weggaat bij RedUnix naar hem overstappen, dan kom je toch ook van de regen in de drup.
Wel opvallend dat hij zo snel een bericht heeft staan inderdaad.
Dit is ff nieuw voor mij, is RedUnix nu van jullie afhankelijk?
Redunix heeft een aantal colocated racks bij ons, ik heb het heel snel gepost omdat wij plat gebeld worden als er iets (ook al iets kleins) aan de hand is.
Nee, ze zijn niet afhankelijk van ons behalve de colocated racks.
ResellerPlanet
16/09/10, 16:10
Redunix heeft een aantal colocated racks bij ons, ik heb het heel snel gepost omdat wij plat gebeld worden als er iets (ook al iets kleins) aan de hand is.
Nee, ze zijn niet afhankelijk van ons behalve de colocated racks.
Het gaat dan over racks in Grafix?
cool4cools
16/09/10, 16:12
fred gesproken naar zijn zegge is het een d-dos attack die de boel heeft plat gelegt in zoverre durf ik niks te bevestigen aangezien al mijn trace routes naar ip-phone of redunix in de aorta blijven hangen....:oops:
inderdaad, net fred aan de lijn gehad. Blijkbaar was er iets gehackt daardoor het dataverkeer enorm toegenomen is. Echter vertelde fred mij dat het alweer onder controle was aan die kant, en dat nu enkel de buffers weer leeg moesten lopen. Dit zou minder als 15 minuten moeten duren (5 min geleden)
15 minuten zijn wel voorbij nu. Ben benieuwd hoe lang dit weer gaat duren.
cool4cools
16/09/10, 16:32
fred nog maals gesproken zijn porten zijn bij inter route dicht gezet heeft een storings melding aangegeven dus gaat nog even duren :eek:
Stijlle hammer trouwens wil dat truukje ook is weten nog nooit gehoord of meegemaakt op deze schaal....
ResellerPlanet
16/09/10, 17:19
Is het alleen de kubus (Rotterdam) waar problemen zijn? Iemand die in Grafix zit en ook downtime heeft?
robvanderpol
16/09/10, 17:23
Onze server staat in de kubus en is ondertussen weer online! gelukkig!
Blijkbaar kon het netwerk van interoute het ook niet meer aan, e.e.a. schijnt nu via Frankfurt te lopen.
Yep, alles back zo te zien.
Meer als 1mil packets per seconden. We zijn nog bezig een aantal racks online te brengen. Het grootste deel is weer goed bereikbaar!
Hallo allemaal,
Ja, dit was een aardige binnenkomende service attack.
Terwijl wij bezig waren om de poorten te sluiten van naar schatting 20 servers, ging er uiteindelijk bij interoute - mogelijk gecontroleerd - het e.e.a. onderuit.
Dat er zoveel servers tegelijk werden aangevallen lijkt op een georganiseerde bende... Ik vind het wel verdacht... Op elke poort die ik sloot liep dik 60 mbps...
Als gevolg daarvan vormde de BGP router de bottleneck in het geheel. De switches liepen gewoon door...
Toen ik merkte dat het er zoveel waren, ben ik naar de betrokken switch gerend en heb ik de blades waarop de attack zich concentreerde er onmiddellijk uitgetrokken.
Inmiddels was dus bij Interoute ook de boel door de knieen gezakt...
Via telnet kon ik niet meer bij de BGP router. Toen ik via de console op de BGP router keek, zag ik dat ik dat de BGP session was verdwenen. Ik heb toen gelijk een ticket bij Interoute aangemaakt.
Op dat moment ben ik gaan kloppen om het verkeer via onze BGP koppeling in Frankfurt om te leiden.
Tegelijk heb ik ongeveer elke 5 minuten Interoute gebeld. Uiteindelijk hebben ze de poort weer opgebracht toen ik hen had verzekerd dat de service attack beslist was uitgeroeid.
Ik heb hen om een rapport gevraagd.
Maatregelen:
1. Wij gaan de redundancy uitbreiden. Ons oudste AS loopt wel via NL en DE. Wij gaan dus de routes van de andere AS ook via Frankfurt adverteren;
2. Wij hebben de poorten van de switches nu allemaal nog beter tegen dit soort service attacks geconfigureerd;
3. In de beide 6509's gaan firewall blades.
Wij zijn uiteraard op zoek naar de oorsprong van deze attack... Daarbij onderzoeken we ook externe logs..
Sorry dat ik het moet zeggen fred, maar deze berichten zou je dus beter naar je klanten rechtstreeks meedelen, het lijkt hier wel het redunix support forum te worden. Maar nu moet je me toch ook eens een paar dingen uitleggen met je kick-ass netwerk. Hoe kan dat nu onderuit gaan met 1.2Gbit (20x 60mbps) terwijl je volgens je marketing praatjes over een uitgebreid 10Gbit netwerk beschikt. Naast het feit om nog maar te zwijgen over redundantie en meerdere transit providers. Als interroute de poort toe draaid mag dat toch geen probleem geven, dan gaat alles toch lekker via een andere transit.
Ik zal het je uitleggen...
Kom gerust even kijken als je dat wil. je hoeft me namelijk niet op mijn woord te geloven...
Ik zit met 1 ding wat door alle commotie nog niet was geregeld: verhuizing van diverse MPLS routers en fiber patches.
Ik ben ooit in de kubus gekomen in 2002.
Begonnen in ruimte 4.05 van 100 m2. Voor die ruimte heb ik infra aangelegd en is er een STM-16 node geplaatst door Colt direct op het LDN van hen.
Daarna ben ik in 2007 begonnen aan de ruimte ernaast, in dit geval 4.03 en 4.04. Infra verplaatst naar die ruimte die 300 m2 is.
Vervolgens hebben we de ruimte van Infopact op 6.01 overgenomen. Dit is zo'n beetje het oudste DC in het pand, gebouwd in 2001. Vele nodes staan hier en er ligt fiber naar iedereen in het gebouw. Ik tel een stuk of 17 providers.
Alle huidige verbindingen vanaf de 4e etage gaan via de carrier room van Tele-2. Ooit wel eens geprobeerd een cross connect aan te vragen bij die mannen?
Ik wens je veel suc6...
Wij hebben er via T2 een aantal liggen. Ook zijn er een paar die nu dat het netwerk van RedUnix feitelijk is omgebouwd en omgenummerd vrij gekomen. Die moeten worden omgepatched.
Daarnaast hebben we twee MDF's in de Infopact ruimte die direct bij Interoute uitkomen. Deze patches, die nu dus vanaf de carrier room van T2 naar de 4e etage lopen, zijn tot op heden nog niet omgezet.
Natuurlijk zat ik niet te wachten op de problemen van de afgelopen weken, maar had ik me liever geconcentreerd op het uitvoeren van aanleg nieuwe fiber cq cross connects.
Als gevolg daarvan staat mijn core aggregatie switch waaraan ook de 10G naar Frankfurt hangt nu nog in een ketting tussen de 4e etage, 7e etage en de 6e etage en niet op de centrale positie tussen de overige switches.
Voor dit verhaal hoef je dus geen netwerk architect te zijn, maar iemand die wat minder hard lopende organisaties even op de juiste plek weet te kietelen.
En voordat je weer verder kritiek gaat uiten, de beste stuurlui staan natuurlijk altijd aan de wal...
Hoe kan dat nu onderuit gaan met 1.2Gbit (20x 60mbps) terwijl je volgens je marketing praatjes over een uitgebreid 10Gbit netwerk beschikt. Naast het feit om nog maar te zwijgen over redundantie en meerdere transit providers. Als interroute de poort toe draaid mag dat toch geen probleem geven, dan gaat alles toch lekker via een andere transit.
Ik ga niet in op de marketing praatjes maar puur op de techniek, een ddos van 1.2 gigabit kan een cisco 6509 wel op zijn knieen krijgen, als je ip's offline haalt waar een ddos heen gaat, gaat dit door een bepaalde processor en heeft de 6509 hier weinig moeite mee, maar ga je alle hosts offline halen (wat bij een verkeerde config niet kan!) dan gaat de cisco staan antwoorden voor al die hosts die offline zijn. (icmp host down iets kan even niet op de naam komen).
Het beste is om niet een firewall kaart te halen (die zuigen best wel en helpen er niet tegen), maar een discard te maken op unreachable hosts ipv een reply te geven. Dan kan je elke host die een attack heeft gewoon eruit trekken en alle gemene pakketjes vliegen in linux taal zeggende naar /dev/null. Ik weet in ieder geval dat je ook met een REJECT rule ipv DROP/DISCARD met een goede ddos (1.2 gigabit en heeeeeeeeel veel pps), je iedere machine / router dood kan krijgen.
Dus hoe groot je netwerk ook is, en vliegt 1 provider eruit dan komt het wel via de andere binnen, dus blijf je het houden, en natuurlijk je configuratie op zulk soort attacks heeft een grote invloed. Dus bij een volgende attack en je kan geen pakketen droppen, dan gewoon de hosts online houden. Dat kan de boel vertragen maar het gaat iig niet voor iedereen stuk.
Sorry dat ik het moet zeggen fred, maar deze berichten zou je dus beter naar je klanten rechtstreeks meedelen, het lijkt hier wel het redunix support forum te worden.
Misschien zijn daar de middelen nog niet voor? Vroeger regelde Sam dit via een of ander zelf geschreven systeem
Waarom zet je porten dicht bij zoiets? Dan is het al snel afgelopen..
Vind het hoe dan ook wel vreemd dat Interoute je gewoon afsluit, dat heb ik nog nooit eerder mee gemaakt bij een carrier...
Sterkte in ieder geval!
Edit:// zie dat Dennis me reeds voor was..
Swiftway-UK
17/09/10, 22:57
Het beste is om niet een firewall kaart te halen (die zuigen best wel en helpen er niet tegen),
Ligt eraan wat de man met een Firewall kaart zou bedoelen. Ik neem aan dat hij het hier over Cisco GUARD heeft. Dat is toch best aardig speeldgoed;) http://www.cisco.com/en/US/products/ps5888/
Zo niet, dan helpt het niet tegen een DDOS. Hij zou eventueel nog Riorey of Intruguard kunnen overwegen om DDOS te filteren.
Overigens werkt de server uitzetten niet, ook de switch disconnecten werkt niet. De DDOS komt net zo goed je netwerk binnen. Ik zou starten met een Nullroute.
Het is ook best van belang welke lijnkaarten je gebruikt in je Cisco 6509.
Ik ga niet in op de marketing praatjes maar puur op de techniek, een ddos van 1.2 gigabit kan een cisco 6509 wel op zijn knieen krijgen, als je ip's offline haalt waar een ddos heen gaat, gaat dit door een bepaalde processor en heeft de 6509 hier weinig moeite mee, maar ga je alle hosts offline halen (wat bij een verkeerde config niet kan!) dan gaat de cisco staan antwoorden voor al die hosts die offline zijn. (icmp host down iets kan even niet op de naam komen).
Het beste is om niet een firewall kaart te halen (die zuigen best wel en helpen er niet tegen), maar een discard te maken op unreachable hosts ipv een reply te geven. Dan kan je elke host die een attack heeft gewoon eruit trekken en alle gemene pakketjes vliegen in linux taal zeggende naar /dev/null. Ik weet in ieder geval dat je ook met een REJECT rule ipv DROP/DISCARD met een goede ddos (1.2 gigabit en heeeeeeeeel veel pps), je iedere machine / router dood kan krijgen.
Dus hoe groot je netwerk ook is, en vliegt 1 provider eruit dan komt het wel via de andere binnen, dus blijf je het houden, en natuurlijk je configuratie op zulk soort attacks heeft een grote invloed. Dus bij een volgende attack en je kan geen pakketen droppen, dan gewoon de hosts online houden. Dat kan de boel vertragen maar het gaat iig niet voor iedereen stuk.
Seconded.
Paar kanttekeningen en aanvullingen:
1.2Gb en worst case pps rate kan een 6509 met juiste sup (en config) wel aan.
Inderdaad moet je het genereren van ICMP Host/network unreachable (wat de connected router moet doen als er geen antwoord komt op z'n arp omdat de server poort is dichtgezet) limiteren of uit zetten.
Uitzetten is het simpelst :
"no ip unreachables" onder de interface(s).
Ook Int Null0 , als je een heel subnet uitzet.
Int Null0
no ip unreachables
Verder ook inlezen over control plane policing.
Als je op een wat groter netwerk snel een "drop verkeer voor deze destinations" en/of "drop verkeer van deze sources" op alle border routers wilt uitrollen moet je kijken naar RTBH (remotely triggered black hole). Leuke manier om via BGP informatie te verspreiden over source/dests verkeer wat ge-nullroute moet worden.
Als je upstream het aanbiedt kun je ook bestemmingen binnen jouw netwerk door de upstream al laten null routen, door (host)prefixen met een speciale community te announcen.
Het is nog steeds een Denial of Service van de betrokken hosts, maar het DoS verkeer is weg van de link met je upstream.
Verder is het belangrijkste wat je moet hebben bij dit soort dingen goede instrumentatie, dat je weet wat er aan de hand is.
Richt dus een netflow collector in, en zet netflow + exports aan op je apparatuur.
En zorgen dat management access altijd mogelijk blijft. Een inbel of DSL'etje (van een andere partij dan je normale upstream..) is dan goed om te hebben.
Ondanks de last voor klanten, en de voorafgaande soap rond RedUnix, vind ik het als buitenstaander erg interessant om dit soort (praktische/technische) verhalen te lezen. :lovewht:
Kippenijzer
18/09/10, 10:56
Ik denk dat hij de 6500 serie FWSM module bedoeld. Verder heeft hij als ik vorige berichten goed gelezen heb Sup32's, en dus enkel support voor classic line-cards die middels de shared bus communiceren.
Slotje erop! Jullie kunnen in het juiste forum verder discusseren over cisco routers/network equipment.