Nets havde ikke ventet voldsomme DDoS-angreb mod NemID

Man kunne også alliere sig med en partner som kan hjælpe med at beskytte mod ddos angreb, f.eks tdc hosting eller google.

Jeg tror også at de efterfølgende har taget kontakt med eksperter etc. for at imødegå DDOS-angreb.

Det er mere i begyndelsen, planlægningen og designet af hardware omkring NemID, at man ikke har planlagt for DDOS-angreb.

El_Coyote (1) skrev:

Man kunne også alliere sig med en partner som kan hjælpe med at beskytte mod ddos angreb, f.eks tdc hosting eller google.

Det har de allerede gjort.

Er jeg den eneste der finder det morsomt, at de indkalder 3 stk. IT-mongoler (intet ondt om mongoler) fra folketinget, til at diskutere nødplanen.

Er man helt sikre på at de ikke blot blev inviteret til orientering om nødplanerne. Forhåbentlig får ingen folketingspolitikere indflydelse på professionelle menneskers arbejde...

For tænk hvis man nu blot bestilte en løsning af en opgave og så ellers LOD VÆRRE med at blande sig?

#4
Har du undersøgt hvad deres kvalifikationer er inden du kalder dem IT mongoler?

Jeg gik i klasse med Dennis som datamatiker og han er ikke IT mongol, uanset om man så er enig i DF politik eller ej.

Det er vel det samme som at sige at du ikke burde poste på internettet fordi du ikke kan stave til "VÆRE".

De tvinger folk til at bruge systemet og så forventer de ingen modstand. LOL

Tror jeg vil tillade mig at kalde Nets for N ordet. Naive / n00bs, vælg selv :-)

Fact: man kan ALDRIG beskytte sig 100% mod DDoS på forhånd - det kan kun gøres løbende som forskellige typer DDoS angreb foretages mod infrastrukturen. Og selv da kan det være svært at stoppe helt - uanset investering, ekspertviden og muligheder...

Altså, denne type situationer i et digitaliseret samfund må man vende sig til - eller gå tilbage til stenalderen - pick your poison.

Et andet kedeligt faktum er desværre at for hver $1 dollar hacktivisterne investerer i at lægge en service ned, så skal den ramte virksomhed investere $10 eller mere bare for at begrænse betydningen af et angreb - og det er altså svært at følge med...

#3, #8, #9:

Artiklen er bare skrevet med en ordlyd så man får opfattelsen af at der intet er gjort for at beskytte mod den type angreb.

Jeg syntes også det er det mest tåbelige staten nogen sinde har gjort at digitalisere alt ting.. Som det så fint siges i bunden af artiklen.. Det er meget nemt at sætte det offentlige ud af spil når det hele afhænger af et system.. Hvem var den idiot der opfandt Nemid.. jeg ved godt det måske er billigere i længden for staten med Nemid.. men det er ikke blevet nemmere for alle og samtidig har der efterhånden været en del problemer med systemet..

og så nytter det ikke, at man kan få det hele til at bryde sammen for en halvtredser.

Det bør nok understreges at det angiveligt kostede en halvtredser at udføre angrebet. Det har vi kun nogle anonyme kilders ord for.

El_Coyote (5) skrev:

#4
Har du undersøgt hvad deres kvalifikationer er inden du kalder dem IT mongoler?

Jeg gik i klasse med Dennis som datamatiker og han er ikke IT mongol, uanset om man så er enig i DF politik eller ej.

Det er vel det samme som at sige at du ikke burde poste på internettet fordi du ikke kan stave til "VÆRE".

Det er vældig interessant, at du belejligt nævner den eneste af dem, der er i kontakt med IT.

- Michael Aastrup Jensen er sælger
- Trine Bramsen er cand.scient.soc. og var seniorkonsulent hos Deloitte.

Så hvis en datamatiker, der har arbejdet som IT-supporter er tung IT viden, så ser det måske lidt trist ud.

#13
Men du mener at en datamatiker er dårlig til it. Bolden er på din banehalvdel. MAJ og TB har ikke, på papiret, kvalifikationer, men kan du komme på en mindre IT-mongol-agtig person end en datamatiker?

#14

Datamatikeruddannelse var i min tid en meget bred uddannelse med fokus på både database, projektopbygning, scripting, programmering m.m. Dette er jo meget smart da man så bedre kan finde sin egen niche og videreuddanne sig, men hvis man kun er datamatiker er ens viden sandsynligvis for overfladisk.

Hvis han havde et par stykker af disse, så ville det være mere relevant at benytte ham.

cruzifixion (8) skrev:

Fact: man kan ALDRIG beskytte sig 100% mod DDoS på forhånd - det kan kun gøres løbende som forskellige typer DDoS angreb foretages mod infrastrukturen. Og selv da kan det være svært at stoppe helt - uanset investering, ekspertviden og muligheder...

Der tager du fejl - når det gælder denne slags service - den behøver nemlig slet ikke at være en centraliseret webservice - se f.ex. min kommentar (nr.1 i link nedenfor.) - og se i øvrigt PHKs glimrende forklaring på hvordan man kan fikse den slags ting generelt - vha. design.
http://ing.dk/blog/denial-service-begyndere-157963

Og mht. ens kompetancer, bare fordi man er datamatiker - så kan jeg afsløre at jeg selv er datamatiker og det i sig selv, gør mig bestemt ikke topkompetent til at vurdere NemIDs infrastruktur og design. Mine 15 års erfaring i netop store setups, hjælper da, men gør mig ikke til ekspert IMHO - men så er der altid guru'er som PHK - jeg rent faktisk har tillid til, ved en del om emnet. - se link til hans indlæg ovenfor, for en bedre forklaring :)

cryo (12) skrev:

Det bør nok understreges at det angiveligt kostede en halvtredser at udføre angrebet. Det har vi kun nogle anonyme kilders ord for.

Om det koster 50,-kr eller 500,-kr eller 5000,-kr er jo ligegyldigt.

Konklutionen er, at det er muligt for 99% at betale sig til at lægge NemId ned med mere eller mindre uoverskuelige følger.

#16: Nej, jeg tager ikke fejl.

Lad os lige tage argumentationen fra PHK først. Premissen han stiller op er at NemID blot skal decentraliseres. Dvs. (som han selv skriver) at vi ikke længere vil kunne bruge den noget mere brugervenlige metode med papkortet der anvendes i dag, men istedet kræve en HW token (et smartcard med Private Key). Og det er noget der under designet af NemID var svært at få til at fungere på tværs at OS platforme.
Det er langt lettere i dag, men altså ikke dengang.
Forstå mig ret, jeg bryder mig heller ikke om at min Private Key ligger på en server hos en privat virksomhed.

Men nu er det engang sådan af historiske årsager.
Dvs. at service'en ikke kan beskyttes som PHK beskriver som det er pt.

Dernæst, HVIS nu NemID var bygget op som en ægte PKI hvor alle brugere havde deres egen Private Key, så skal signaturen der skabes vha. Private Key stadig verificeres centralt. Dette vil foregå vha. en offentlig tilgængelig webservice (OCSP) eller et offentligt tilgængeligt website (traditionelle CRL'er).
OCSP'en kan IKKE distribueres som PHK gerne vil have da det sikkerhedsmæssigt ikke er muligt.
CRL'er derimod kan reelt godt, men det vil kræve nogle ret så komplicerede metoder at destribuere CRL'erne, og de vil STADIG komme et central sted fra og fra et website skal være offentligt tilgængeligt og det vil hacktivisterne stadig have mulighed for at ramme. Så længe de holder den centrale service nede længe nok, så vil det betyde et total nedbrud ligesom nu (læs lidt om PKI og CRL/CDP'er og du vil forstå hvorfor).

Og så længe dette site er offentligt tilgængeligt, så er vi tilbage ved at det er ligeså centralt som NemID er i dag. Faktisk fungerer den gamle digitale signatur på denne måde, men den er altså ligeså følsomt som NemID - hvis hacktivisterne går efter den...

Næste argumentation er at vi blot skal have nok kapacitet at lægge under den pågældende webservice/site for at fjerne truslen. Den holder heller ikke rigtig.

A) Firewalls: Vi kan ALDRIG nogensinde begrænse betydningen af SYN DDoS attacks (det der lægger en FW ned) i en grad så DDoS er ineffektivt. Vi kan reducere betydningen, men aldrig fjerne den. Det skyldes ganske enkelt at TCP/IP bare er fyldt med fejl på dette område. Der eksisterer teknologier der kan reducere (SYN Cookies, SYN Thresholds m.m.) men de kan kun begrænse i et vist omfang.

B) Båndbredde: Hvis en relativ "god" gruppe ønsker at lægge en sådan service ned vha. båndbredde attacks, så vil de gennem deres tilgængelige botnetværk have så meget båndbredde til rådighed at ingen provider i DK vil kunne håndtere det (heller ikke selvom de slog sig sammen). Dette skyldes ikke mindst antallet af bots, men også anvendelsen af DNS UDP Bounce som er meget anvendt i disse henseender - og det er MASSIVE mængder data der kan sendes mod en given service (vi snakker +60 Gbit/sec).

C) Internationale Anti DDoS providers: Ja, de vil næsten med garanti kunne praktisk talt stoppe det, MEN det vil kræve at personfølsomme oplysninger skal "flyde" igennem deres systemer, distribueret på tværs af deres datacentre over hele verden, og det kan vi ikke tillade pga. persondatalovgivningen. Samme problemstilling som med Cloud tjenester i offentligt regi.

PHK skriver bla. også en "analogi" hvor han sammenligner en indgang til et hus, og at man blot skal have "skjulte" alternative indgange og skifte til efter behov. Men nu er det jo således at man IKKE kan have "skjulte" indgange i dette setup, da de SKAL kendes af klienter og services på forhånd eller lige efter "skiftet" - og det opfanger hacktivisterne jo med det samme som "skiftet" foretages. Premissen holder bare ikke...

Altså, jeg er DYBT uenig i fremstillingen og simplificeringen - jeg er dog ikke uenig i at vi alle burde have kontrol over vores egen Private Key, men det hjælper ikke på DDoS og er en hel anden diskussion...

Baggrund omkring SYN attacks.
DDoS SYN attacks kan i praksis kun lade sig gøre fordi det kan lade sig gøre at spoof'e en tilfældig adresse på nettet - dette kan ikke lade sig gøre at forhindre med IPv4 i dag, med mindre at ALLE ISP'ere i hele verden havde Ingress Filtering på alle ind/udgange fra deres netværk. Og det har de desværre ikke.
Der er teknologier i FW's der kan reducere betydningen, men ikke fjerne truslen helt fra SYN spoofs.


Baggrund omkring DNS Bounce.
Rundt omkring på nettet står der en masse "åbne" DNS servere der er meget ringe beskyttet. Disse åbne DNS servere kan man sende en DNS query imod hvor besvarelsen fra DNS serveren er meget stor (f.eks. en total zone transfer). Og her spoofer man IP'en man kommer fra, med den IP som man ønsker at angribe. I det tilfælde vil DNS serveren sende massevise af store besvarelser mod IP'en i for af UDP (som bare er noget skidt sikkerhedsmæssigt). Da DNS servere som regel sidder på meget kraftige linier, så vil relativt få DNS servere af denne type meget let kunne lægge særdeles krafige linier ned - specielt når det kombineres med et gedignt botnetværk.
Igen kunne denne metode kraftigt begrænses effekten af hvis ISP'erne verden over anvendte Ingress Filtering.

vil forskellige midlertidige begrænsninger ikke kunne afværge et DDoS og lign? (har ikke meget forstand på dette)

Eksempelvis hvis man aktiverede midlertidige filtre der afviste udlandske ip'er indtil DDoS er slut?

Kun tilladte tidligere ip adresser som har haft "succesfuld" login inden for en måned/halvt år?

og mange andre lign regler som altså kun skulle aktiveres midlertidigt når trafikken blvier for høj.

#15, #16
Vil I dermed forsvare #4s udtalelse, at en datamatiker er en IT-mongol?

#20: Altså, når IP'erne spoof'es så er IP filtre nærmest ligegyldige da hacktivisterne blot spoof'er danske IP.
At lave et IP filter baseret på applikationens sessions historik ligeledes ret ubrugeligt da samme problemematik vil eksistere.

Som jeg har forsøgt at illustrere med tidligere posts, så er DDoS relativt trivielt at foretage men kan være ret komplekst at forhindre - sådan er det bare.

Som jeg ser det, så er eneste mulighed en national centraliseret DDoS beskyttelse etableret og drevet af staten der er distribueret på tværs af flere ASP'ere i DK, hvor alle samfundskritiske services skal ligge bag. Problememet er blot at en sådan service vil have tæt på astronomiske omkostninger at bygge og vedligeholde da den skal have en international standard.

@cruzifixion:
en CRL service er AFAIK IKKE personfølsomme data, da det KUN er en liste af certifikater-signaturer der er tilbagetrukket før deres udløb. Den kan man snildt lade en anti-DDOS provider servicere - eller distribuere, således at DDOS kan beskyttes imod, vha. design.

Og tro mig - jeg har erfaring med DDOS i stor skala (ihvertfald a la den slags der kom efter muhammedkrisen) - hvor trafik mængden var stor nok (fordi kundens servere lås hos denne) til at ISP'en måtte gå ind og håndtere DDOS'en.

Hvis ens servere er placeret hos de rette, kan man beskytte sig imod alle DDOS'er.

Se f.ex. seneste DDOS mod spamhaus - hvor de nåede op over 300gbit/s - men lagde ikke spamhaus ned (dele af internettet blev så generet af det, men spamhaus kørte videre).

Og den slags DDOS størrelser, er bestemt ikke billige at udføre - så antallet af personer der kan udføre den er MEGET mindre, end den slags til 10 USD - som der er tale om her - der ligger NemID ned.

Temmeligt ringe.

Så jo - designet i den gamle løsning, ville have løst problemet.

#23:
At det kan lade sig gøre i visse tilfælde gør ikke mine udsagn forkerte, men det gør dine udsagn tvivlsomme. Det skyldes primært at du i dit eksempel kun overvejer båndbredde baserede angreb, og ikke alle de andre former (SYN, L7 App, L7 båndbredde, osv.).

Mht. til CRL har du til dels ret (og CRL'er kan iøvrigt ikke "fakes"), MEN min forklaring var primært henvendt til nuv. opsætning som jo af historiske årsager ikke bare kan laves om.
Og stadigvæk, så selv med den gamle løsning (og dermed CRL'er) vil det være meget svært at få stablet på benene i en distribueret løsning der vil kunne modstå DDoS. Specielt når man begynder at regne på konsekvenserne ved at lave en SÅ distribueret CRL struktur i latency henseende - altså hvor lang tid vil det tage før et certifikat er betragtet som værende inaktivt (revoked).
Den eneste grund til at at den gamle løsning ikke i samme omfang er blevet lagt ned er grundet mediefokus på det (som har været noget mindre) - hvis de virkelig vil lægge den gamle løsning ned, så har den nøjagtig samme arketektoniske svagheder som NemID.

Så uanset hvad erfaring du påstår du har, så bliver jeg ikke enig med dig.
Længere er den ikke.

Kunne man ikke bare vælge en decentral løsning, f.eks. med private/public keys distribueret til brugeren/service-indehaveren? Så kan der DDOS'es på fuld smadder det ene sted, mens det andet sted fungerer fint...

Gid den slags allerede eksisterede...