Der er omkring 150 domæner som har aktiveret buggen, som har haft potentialet til at eksponere informationer omkring de millioner af domæner som bruger Cloudflare. Det er måske de to forskellige tal som har skabt lidt forvirring?
Der er kommet en blog post op omkring hvad vi så fra CloudFlare i går omkring dette: https://blog.cloudflare.com/a-post-mortem-on-this-mornings-incident/
(Jeg har været bagud med min RSS reader, så det er lidt sent jeg får kommenteret på dette.)
Først: Jeg arbejder ved CloudFlare, men meningerne er mine egne.
Mht. Tor trafik, så har det som sådan ikke noget med DDoS at gøre, båndbredden på Tor er generelt for lav til at det giver nogen mening at forsøge at "floode" nogle i gennem det. Problemet med Tor er i stedet for mængden af folk der forsøger at hacke sig ind på sider via sårbarheder, spammer via kommentar systemer, og lignende. Det er i disse tilfælde besøgende oftere vil blive bedt om at bevise de er reelle besøgende, f.eks. ved at udfylde en CAPTCHA, på grund af IP adresser fra Tor exit nodes ofte har et dårligere ry/reputation. Dette er ikke noget Project Shield beskytter imod, det fremgår af første spørgsmål i deres FAQ.
I forhold til hvilke lande trafikken bliver sendt i gennem, og dataen bliver opbevaret i, så er det klart at der vil være trafik der går i gennem USA og bliver opbevaret der. Det er nødvendigt for at tilbyde produktet. Den bedste måde at håndtere DDoS angreb på, er ved at få angrebet til at ramme så mange forskellige steder som muligt, ved at have datacentre rundt omkring i verden, da effekten i hvert datacenter så bliver mindre, og dermed langt lettere at håndtere. Det er også årsagen til at vi har knap 80 PoPs rundt omkring i verden. Det med at opbevare data i de forskellige lande, kommer af at produktet også virker som et CDN, hvor data bliver cachet i på servere i datacentrene så de ikke behøver spørge upstream serveren om dem hver gang, ellers vil man blot kunne ligge upstream serveren ned ved at f.eks. sende mange forespørgsler til en "tung" side, og så er man lige vidt.
/Jeppe
Browsere sender en Accept-Encoding header med hver request, der indeholder en liste af de forskellige komprimeringsalgoritmer som browseren understøtter. Det kan serveren så bruge til at vælge en algoritme som den selv understøtter, og sende dataen komprimeret eller ej.
Dermed behøver der ikke være en bred understøttelse for nye komprimeringsalgoritmer før de kan tages i brug, da det blot kræver at browser og server er enige.
Til Python specifikt er der også PEP257 som kan være god at følge, det er en standard for hvordan dokumentation skal skrives. Derudover er jeg også glad for Pylint som også kan hjælpe med at skrive bedre kode.
For at sørge for at man ikke kommer til at committe kode med fejl i, kan man gøre brug af pre-commit der kan installere sig selv som et pre-commit hook i Git. Den kan så lave nogle checks på den del af koden du har rettet i og stoppe dig fra at lave et commit hvis det ikke overholder de regler man nu har sat op.
Jeg er ret sikker på det kun er en knap der siger "Jeg har stemt!" og ikke noget om hvem man har stemt på. Det passer jo også udmærket med formålet fra Facebooks side - at få flere til at stemme. Hvis man nu ser at en stor del af sine venner har sat at de har stemt, så kan man måske også selv lettere lokkes til at gøre det.
Om det så øger chancen for at folk offentliggør hvad de har stemt på, skal jeg så ikke kunne sige.
I stedet for at forsøge at lytte på en port i den stump test kode I har skrevet, så er det her et lidt simplere eksempel. Hvis der bliver outputtet "Vulnerable" så bør Bash blive opdateret hurtigst muligt:
I nyheden står der:
Hvordan hænger det sammen? Bare fordi man benytter hosting hos Amazon, betyder det ikke at den har hverken flere eller færre kapacitetsproblemer end ved at bruge en server man har stående hjemme i kælderen.Og siden blev lagt i Amazons sky, så der ikke var kapacitetsproblemer [...]
I tilfældet med Navnehjulet er hjemmesiden lavet som en primært statisk side, som bliver hostet på Amazon's S3 service. I og med datamængden er begrænset (27,7 KB navneliste + 1,7 KB per personopslag + HTML og billeder) så tror jeg ikke det ville have været noget problem at hoste på en simple webserver, så længe den havde en ordenlig internet forbindelse. Så kunne man også have serveren til at stå i Danmark, i stedet for at alle besøgende (i dette tilfælde) skal til USA for at hente data'en. Det virker i øvrigt ret absurd når man må forvente de besøgende kommer fra Danmark, og Amazon har data center i Irland.
Jeg syntes det er interessant at de har valgt at bruge Akamai som CDN. Jeg forventer at langt størstedelen af deres brugere befinder sig i Danmark, og så tænker jeg at et traditionelt CDN ikke hjælper så meget - det plejer primært at blive brugt for at få filerne tættere på brugerne, når man har brugere fra et stort geografisk område.
Efter at have læst nyheden på TorrentFreak, så har jeg nu fået et andet indtryk af hvad historien drejer sig om.
BPI har lavet et takedown request, hvor de beder Google fjerne 2.056 adresser fra sine søge resultater, 171 af disse adresser peger på The Pirate Bay. Google har fjernet alle de anmodede adresser fra søgeresultater, med undtagelse af "http://thepiratebay.sx/" - altså forsiden på The Pirate Bay, hvilket er grunden til at TorrentFreak har lavet en nyhed omkring det. Altså, er de 170 andre adresser i forespørgslen som peger på undersider på The Pirate Bay blevet fjernet fra fremtidige søgeresultater på Google.
Forøvrigt mener jeg heller ikke at The Pirate Bay har torrent filer liggende længere, de er vidst gået over til kun at have Magnet links: https://en.wikipedia.org/wiki/Magnet_URI_scheme
Det ser ikke ud til at København's Lufthavn, Kastrup er enige med den udtalelse, men det er måske et spørgsmål om hvordan man måler det.http://www.cph.dk/CPH/DK/OmCPH/Strategi+og+fakta/Fakta.htm:
På Wikipedia siden for lufthavnen står der dog i stedet for:Danmarks største arbejdsplads
Københavns Lufthavn er daglig arbejdsplads for flere end 22.000 mennesker.
Med sine 22.000 ansatte på én adresse er lufthavnen Danmarks største arbejdsplads.
I stedet for et alternativ til JPEG, så er det vel ret beset GIF de diskuterer om WebP kan være et alternativ til?
Jeg er ikke helt med på det output du poster. Du prøver tilsyneladende at pinge 192.168.224.144 som er en intern LAN adresse, måske fra dit eget netværk? Det kan selvfølgelig ikke lade sig gøre, fordi serveren - der står placeret i et datacenter - ikke har nogen måde at finde frem til hvor den IP adresse findes henne. Måske har du misforstået hvad det går ud på, og forestillet dig at den virtuelle maskine bliver kørt i din browser, og derfor har adgang til dit lokale netværk?
'command-not-found' er Ubuntus program til at dig med at installere den pakke der har programmet du prøver at køre. Det ligner så at det ikke virker korrekt første gang du kører den, eftersom den crasher. Når du får ændre sprog variablerne virker den dog fint, og gør dig opmærksom på du kan få 'gcc' programmet ved at installere 'gcc' pakken. Det eneste der er uhensigtsmæssigt i det output du giver, er at 'command-not-found' crasher i første omgang, men det er måske fordi der enten bliver brugt et underligt locale, eller fordi den måske mangler tekst strenge i det sprog systemet er sat til. Derudover virker det hele som det skal.
Eftersom artiklen omhandler apps til iOS, så kan Adblock Plus ikke gøre særligt meget ved det.
Der er så mange ting i de citater som ikke giver den store mening, lad os lige løbe dem i gennem:
Hvad er en "filopgradering"? Peter Glüsing får det til at lyde som om det er en normal ting, men det gør åbenbart at deres ene mailserver skal geninstalleres hver gang de gør det?Hver gang vi har lavet en filopgradering, er serveren gået ned og skal bygges op igen
Hvordan skal det lade sig gøre? Skifter de til en frontend som læser filerne direkte fra deres NAS bokse, så alt logik ligger i frontenden? Og hvad gør de så med SMTP, POP3 og IMAP services der ikke kører som webmailen?NAS-servere skal erstatte vores backend
I forhold til hvad? Det er vel kun filsystem kald de potentielt kan behandle hurtigere, men hvad hjælper det på driftstabiliteten? Det kan muligvis hjælpe med at få afviklet deres backlogs hurtigere, hvis filsystemet er flaskehalsen, men ellers ved jeg ikke hvordan det skulle hjælpe.Det gode ved NAS er, at det kan behandle forespørgslerne hurtigere.
Med mindre mailsystemet går ned hver gang det modtager f.eks. en HTML email som der måske ikke fantes så mange af før i tiden, så har jeg svært ved at se det er softwaren i mailsystemet som er årsagen til det. Som Peter Johan Bruun skriver, så falder det vel ikke bare fra hinanden med tiden.Det nuværende servermiljø har ifølge Jesper Hansen fungeret upåklageligt i mange år, [...] men nu er der simpelthen for mange nedbrud til, at det er til at leve med.
Nu bliver der ikke sagt noget om hvad det er de forventer at lave i den periode, men hvis det er at finde en anden leverandør eller et andet mailsystem, teste at det virker korrekt, lave migreringsplan, installering af systemet, teste migrering og til sidst lave migreringen, så lyder det som en meget optimistisk og presset tidsplan i mine ører.Det kommer til at tage lidt tid, da vi gerne vil gøre det rigtigt. Så man skal nok regne med en uge til 14 dage
Det burde reelt set ikke være frontendens job? I øvrigt, så kommer der vel heller ikke mindre arbejde til backenden af at rækkefølgen tingene bliver lavet i ændres?Den nye frontend skulle sikre en bedre sortering på forespørgsler, så backenden ikke bliver oversvømmet.
Det lader til hjemmesiden http://112app.dk/ indeholder links til alle de apps der er lavet i forbindelse med dette.
Hvis app'en var tilgængelig nu, så kunne jeg installerede den på min telefon med det samme, og have den klar i tilfælde af jeg skulle få brug for den. Nu skal jeg i stedet for gå rundt og vente til det bliver mandag, og håbe på jeg husker at der var den der app jeg lige skulle installere - som vi i øvrigt ikke ved hvad kommer til at hedde. Det syntes jeg godt de kunne have gjort smartere, så app'en var klar når de nu annoncerer den på denne måde. Det tror jeg ville få flere folk til at installere den, hvilket jeg formoder er i deres - og alle andre folks - interesse.
Nu når der står der er succes med at bruge Nginx som load balancer, har der mon så også været forsøgt at bruge den til applikationsserverne? Min erfaring med Nginx er at den skalerer langt bedre end Apache HTTPD, og med langt færre ressourcer. Hvis flaskehalsen omkring applikationsserverne, og grunden til der skal være seks af dem, er f.eks. PHP eller hvilket sprog koden nu måtte været skrevet i, kunne der sikkert være noget perfomance at hente ved at skifte Apache ud, da man så ville bruge færre ressourcer på at håndtere HTTP forespørgsler, og dermed have flere til at køre sin egen kode.
Det har intet med DNS servere at gøre. Der er tale om stikprøver af alle pakker som bliver overført over en internet forbindelse, ikke kun DNS opslag. Desuden har dette heller ikke noget med blokering af specifikke hjemmesider at gøre, men kun et spørgsmål om overvågning af de danske borgerer.
Jeppe Toustrup