FAQ |
Kalender |
![]() |
#41 | |||
|
||||
Klarade millennium-buggen
|
||||
![]() |
![]() |
![]() |
#42 | |||
|
||||
Flitig postare
|
Eller så kanske det var någon som roade sig med att sno utrustning från ene telestation..
|
|||
![]() |
![]() |
![]() |
#43 | ||
|
|||
Klarade millennium-buggen
|
Allt är snöns fel!
|
||
![]() |
![]() |
![]() |
#44 | ||
|
|||
Mycket flitig postare
|
En till artikel om händelsen, med en del detaljer:
http://www.idg.se/2.1085/1.298347/sa...-cyberattacken |
||
![]() |
![]() |
![]() |
#45 | ||
|
|||
Klarade millennium-buggen
|
Just en anledning varför man inte ska köra vanliga brandväggar, för dom klarar inte av så många PPS. Åt andra sidan är 100.000 paket inte alls mycket, normalt brukar man få upp till MILJONER PPS.
Men i vilket fall så skulle denna typen av attack kunnat lösas på 5min utan problem om man har kunskap och lite vettiga saker. 1) Blockera målet till attacken helt 2) QoS och ratelimit antal SYN paket till en fungerande nivå 3) Om varje paket hade samma dst port eller src port kunde man skapat en ACL för matcha på det. 4) Om det var flertal paket från samma src IP kunde man satt en microflow policy för limit antal SYN per IP. 5) Analyserat paketen i raw format för se om dom följer ett mönster, i ipoptions eller TTL värde. Om dom genererades ifrån samma burk eller samma botnät "mjukvara" så är risken rätt stor att allt är samma. Så skulle man kunnat sätta ett L7 filter för matcha på den TTL. Om det skulle vara ett mindre vanligt TTL värde så skulle det inte stört legetim trafik till det IP. 6) Möjligen blockera från det hållen trafiken kommer ifrån bara. Samt 100.000 PPS är ju inget i trafik mängd ens, om vi räknat ett SYN paket är 62 byte med ethernetramen. Vilket borde motsvara 45-60Mbit, orkade inte räkna helt exakt. Alltså ingen trafik att prata om alls. Att det ska ta 45min att ens fatta det är en DDoS är ju bara komiskt. För mig är det fortfarande ett dåligt skämt hos dom. |
||
![]() |
![]() |
![]() |
#46 | |||
|
||||
Klarade millennium-buggen
|
Jag hade ofta problem med dos eller ddos där gamla brandväggen inte kunde köra ratelimit. Nu har jag redundanta brandväggar som klarar av synproxy state (spoofed TCP SYN floods) och där man kan sätta max nya state per sekund och totalt, och sedan dess inte haft några problem alls när ddos i denna omfattning kommer, men självklart tror jag inte ens bra brandväggar klarar av flera gbit ddos och mer, men denna ddos känns inte som större än de största jag själv råkat ut för.
|
|||
![]() |
![]() |
![]() |
#47 | |||
|
||||
Klarade millennium-buggen
|
||||
![]() |
![]() |
![]() |
#48 | |||
|
||||
Klarade millennium-buggen
|
Det vill jag av olika skäl inte gå ut med, men det finns många brandväggslösningar där brandväggen stöder failover till en andre samt som är "stateful", dvs hanterar states och som klarar av synproxy state (spoofed TCP SYN floods) samt där man tex kan sätta 200 nya states per ip på en 5 sek intervall samt tex. max 1000 states på ett IP.
|
|||
![]() |
![]() |
![]() |
#49 | ||
|
|||
Medlem
|
Om man jämför dessa attacker med de som tex Google,Facebook och Twitter råkade ut för förra året? Är dessa större eller mindre?
Med tanke på att dessa gick ner och de borde väl ha fullgott skydd ala patrikweb? Eller är det så att Patrickweb och Danielos sitter på utrustning och kunnande vida övertigande teknikerna och hårdvaran hos dessa företag? |
||
![]() |
![]() |
![]() |
#50 | |||
|
||||
Klarade millennium-buggen
|
Jag tror inte denna attacken var större, men frågan tror jag bara fs-data själva kan svara på, jag känner iaf till många som har brandväggar som inte stöder att begränsa states och synproxy state, den vi hade tidigare kostade runt 60 000 och hade noll stöd.
Senast redigerad av Danielos den 2010-02-28 klockan 11:29 |
|||
![]() |
![]() |
Svara |
|
|