Tak for indlægget, og sjovt at læse.
Jeg er selv glad kunde hos 3 og hos dem får man nemt IPv6 med i lommen. Jeg har eksempelvis en lille 4G lommerouter med IPv6+IPv4 når jeg er i DK.
Reklame: Jeg er LIR dk.zencurity i DK og laver gerne en IPv6 Provider Independent ansøgning til RIPE NCC på jeres vegne, dem som vil lege med IPv6. Send mig en email på hlk@zencurity.com hvis det er noget i ønsker. Selve ansøgningen gør jeg pt. gratis, indtil der kommer for mange.
NB: jeg bliver opkrævet 50EUR om året, så I vil fremover bliver opkrævet 100EUR pr år for dette.
NB: når I så får adresser skal de routes et sted, og det kan de fleste firma ISPer nemt gøre. Privat personers internetforbindelser er sjældent "supporteret" selvom det virker hos nogle. Jeg var hos Wizer/Gigabit med native IPv6, og tidligere Bolignet igennem mange år. Nu er jeg solgt til fastspeed så det bliver spændende om IPv6 virker hos dem.
Et godt sted at kigge og opdatere er: https://ipv6-adresse.dk/ Tak Emil
nej, det er bestemt ikke ligemeget.
Om en DNS server er IPv4 eller IPv6 enablet betyder intet for om den serverer A eller AAAA (IPv6) records. Det giver fin mening at have IPv4-only server for domæne example.com, men servere AAAA adresser.
Forestil dig en IPv6-only client som spørger sin lokale DNS resolver, som så spørger videre ud. Denne resolver kan snildt have dual-stack, selvom klienterne ikke har det :-) Der er ofte flere lag ude i verden, så hvis du spørger Quad-9 om DNS, via deres adresser på IPv6 vil de også kunne slå op med IPv4 til domænets autoriative DNS. https://www.quad9.net/ har IPv4 og IPv6 resolver adresser.
ååh gud
Altså når det offentlige KØBER og dermed er opdragsgiver burde de imho have bedt om det.
NÅR DET ER INDGANGEN til at se OFFENTLIGE data, fra OFFENTLIGE myndigheder, arrhh you get the point :-P
Der skrives lidt frem og tilbage.
Sjovt nok nævner ingen at NAT også begynder at kræve "support". Her menes blandt andet større og større enheder som skal lave Carrier Grade NAT og bøvl med logning, og håndtering af henvendelser fra eksempelvis politiet.
Gode NAT bokse koster også penge og support, samt failover osv.
Tak klåge åge
I det lovforslag, som nu er trådt i kraft, indskrænker man hvad oplysningerne kan bruges til - nemlig beskyttelse af den nationale sikkerhed, bekæmpelse af grov kriminalitet og forebyggelse af alvorlige trusler mod den offentlige sikkerhed, siger Sune Klinge.
Det er IKKE rigtigt. Man har talt om at "kun" bruge det til alvorlig kriminalitet. Der benyttes ofte eksempler på GROV krim, og der tales om straframmer 6 år vs 3år. Det som glemmes er at siden rockerloven har man haft ekstreme muligheder for invaderende tiltag. I praksis ved du og alle andre at man benytter alle værktøjer til alting. Der er ikke noget som ikke er "godt nok" til en dansk ret (inadmissible in court). Når data er indsamlet er overgrebet sket.
Det er fantastisk at få dommen, en mavepuster, og så folk der skal kloge sig. Specielt når JM har vundet på at deres advokat i højesteret står og lyver, og bruger jm.dk som eneste reference. Det er i praksis åbenbart umuligt AT få kendt det ulovligt, selvom alle ved det er over grænse. Selv advokaten der stod og prostituerede sig selv, vidste det.
Det danske retssystem har spillet fallit idag.
jeg bruger ns01. og ns02.zencurity.com som er Zencurity ApS, mit eget firma. beklager jeg ikke fik skrevet tydeligt nok. Jeg tilbyder dem gerne til et mindre antal andre firmaer som er kommet i klemme i denne migrering.
Tak for kommentar.
Det rører ved noget helt centralt, at man ikke ud fra hverken routing eller geografisk placering kan spå om performance. Der kan være alskens grunde til at endepunktet du efter DNS besøger kan være ringe, perfekt, uoptimalt eller anbefalet til netop dig. Jeg kan til nøds gå med til at TDC DNS vil sende dig til en cache indenfor eget netværk, at de har en DNS med logik bagved. Du siger Akamai, men det kunne være Netflix eller andet. Mange andre DNS resolvere hos udbydere er en sidegeschjæft som lider en stille død. Det er ikke noget der er fokus på, hvis den bare virker nogenlunde.
De andre svar uanset om det er Nordunet Stockholm, eller via Amsterdam AMSIX kan godt være tilnærmelsesvis lige så gode som Akamai Kbh. Der er mange tilfælde hvor trafikken mellem to danske netværk går ud af landet, grundet økonomi og peerings.
Vi glemte også begge to at nævne at browsere begynder at lave andre tricks, og måske pludselig benytter en anden resolver end dit operativsystem via DoH ... det er også noget skidt i mange tilfælde, og så igen måske en fordel for nogle. Se https://en.wikipedia.org/wiki/DNS_over_HTTPS og https://en.wikipedia.org/wiki/DNS_over_TLS
Svaret ville blive langt nok til en serie blog indlæg, måske jeg skulle se på det
Det er ikke frækt at sige sin mening :-)
For at tage det sidste først, jeg ser sjældent at OSCP er et krav, omend de måske skriver at det er et ønske i job opslag. Da jeg var i VIGILANTe, tilbage for snart 20 år siden havde vi altid to jobopslag på hjemmesiden, et til senior og et til junior. Vi kunne bruge begge typer.
Mht open source vs kommercielle systemer, så har jeg en helt specifik anbefaling til alle - se også foregående blog omkring logning. Afprøv altid open source løsningerne. Et Proof of Concept kan laves relativt simpelt og alle erfaringer man får er brugbare.
En af erfaringerne er at det er "for bøvlet" og man gerne vil bruge mange penge på en kommerciel løsning. Det kan også være man finder ud af at nogle dele er vigtigere for ens organisation end andet. Det gør at man er bedre klædt på til at vurdere HVILKEN en af de kommercielle løsninger der vil passe bedst. Man kan stille de rigtige spørgsmål til leverandørerne.
Når man så som arbejdstager har mulighed for at lege med open source løsningerne, så giver det stadig en masse begreber og erfaring som alt andet lige vil være gavnligt, selvom organisationen måske har valgt Splunk eller andet. De leder ofte med en alt for lang, og specifik liste over tekniske krav, hvor de imho burde se mere på mennesket.
Det er vist blot et sikkerhedsfirma der skal pudse brillerne.
Jeg har hentet deres "whitepaper" og det er en ynk. Der er mange unøjagtigheder. Sproget er ret dårligt og selve problemet er langt mindre end de prøver at FUDde det op.
Det er fint at de angiver testmetoden, jeg elsker hping3 - se eksempelvis mit workshop materiale fra BornHack hvor vi brugte samme. https://github.com/kramse/security-courses/tree/master/presentations/pentest/simulated-ddos-workshop
Nå, tangent. Når man sender EEEEEEN UDP pakke bliver der produceret EEEEEEEN ICMP, og udover ICMP Echo giver ICMP SPECIFIKT IKKE anledning til FLERE ICMP pakker.
For at understrege, ping 1.2.3.4 sender ICMP Echo og giver potentielt Echo Reply tilbage. Alle de andre ICMP typer er kun eeen besked.
Så når man sender en UDP til en closed port på en enhed får man ganske rigtigt ICMP retur. Jeg checkede med hping3, tcpdump og Wireshark hjemme. En UDP probe på ialt "42 bytes on the wire" giver anledning til een ICMP Port Unreachable "70 bytes " on the wire.
Dernæst er der mange mange enheder, specielt netværksenheder, men også FreeBSD, Linux m.fl. begrænser antal ICMP beskeder, rate limit. En kilde sagde Linux har default 1.000 since kerne 2.4.
Så vi er i en situation med moderat amplifikation, 42 bliver til 70, men angriberen rammer formentlig hurtigt rate limit.
Så jeg vil fremover tænke dårligt om Nexusguard, og deres "deploy deep learning" loool
Logningsværktøjer er ofte ligeglade med hvor logs kommer fra. Jeg er glad for elastic stack, fordi den har så meget med fra starten. De har også packetbeat som er relativt nemt at sætte op og giver godt indblik.
Elastic Common Scheme er en nice feature, så værktøjer på tværs af leverandører kan bruge samme felter osv.
Det ville eksempelvis kunne sige, hvilken PC slog først op på et specifik malware domæne, hvis man er blevet inficeret.
Det forstår jeg ikke hvordan du kan sige. Det var BGP der fejlede og som følge af det fejlede alle tjenester, herunder også DNS.
Hvis vi snakker root cause, så er det BGP - eller faktisk før i kæden, og den del som FB ikke har fortalt ret meget om, deres FB engineering post er jo næsten tom for teknik.
Hvis vi snakker brugeroplevelsen, klient vinkel så er det DNS de ser som problemet, først.
Jeg kan sige DNS hele dagen ;-)
Det synes at være lidt søgt. DNS var faktisk irrelevant da du ikke kunne komme til sitet uanset da deres IP adresser ikke var routet. Der gik tilmed mere end en time efter at DNS var tilbage hvor sitet stadig var nede.
DNS er da bestemt ikke irrelevant. Det er det step der fejlede, stopklodsen om du vil. Gav det andre problemer at BGP fejlede, helt sikkert. En af de twitter tråde jeg så havde var det 110 vs normalt 133 routes/prefixes, så ja der er sikkert flere problemer, som man så støder på når DNS er "fixet".
DNS er jo heller ikke bare eeeeen A record, men typisk et antal hostnavne, til diverse ressourcer. Hver af kan så have problemer med NS, records, caching osv. En time til at DNS stabiliserer sig virker ikke unormalt.
Når man nitpicker skal man passe på, spejlet kommer hurtigt frem
Først og fremmest har FB ikke lavet en root cause analysis rapport, som de har publiceret.
Det betyder at vi allesammen ser på symptomerne.
Der hvor vi er enige, formoder jeg, er at en browser ikke kunne se servere med facebook (og de andre services).
Det er en længere lavine, hvor BGP var skyld i at DNS ikke kunne nås, som gør at browsere, som spørger recursive DNS ikke fik svar.
Om FB servere er på samme prefixes, annonceret via BGP, eller andre er ligegyldigt. Grundet DNS fejlede det ved at hostnavne ikke kunne slåes op. DNS fejlede fordi man ikke kunne nå de servere, som formentlig stod og trillede fint i et datacenter, bagved routere. DET skyldes BGP fejlen.
Tilsvarende var alle FBs webservere, og dertilhørende load balancers m.v. formentlig også oppe og klar til at servicere, online, men ingen kunder ind til dem.
Jeg mener godt vi kan sige DNS er problemet, det var det specifikke step som gjorde at man ikke kunne nå FB servere fra en browser - som vil være det normale man som forbruger vil bedømme servicen på.
Kæden kan FB selv optrevle, og det skyldes formentlig nogle helt almindelige, men uheldige ændringer, som skubbet igennem pipelines af automatisering.
Dernæst kan vi begynde at snakke hvordan de kunne have undgået det.
og siden, og relevant, hvor mange danske firmaer har problemer med dårligere DNS, BGP og lignende.
Det er naturligvis ironisk eftersom ARPANET oprindeligt blev designet til at være robust sådan at det kunne fungere selv hvis dele af nettet blev udslettet.
Det er en myte at internet er designet til at modstå atomangreb
Der var dog forskning igang på RAND omkring Telefon netværk som havde disse ting under behandling
fra mit speciale: The evolution of the Internet is an interesting and long story, and the roots can be traced as far back as to notes written by J.C.R. Licklider of MIT in August 1962 [Leiner, 2000]. The first reference to the architecture we call the TCP/IP Reference Model can be found in the historical document A protocol for Packet Network Interconnection, [Cerf and Kahn, 1974].
Regarding the design and goals of the Internet Protocols, and the family of protocols, there is a lot of misconception. One such rumor says that the ARPANET and protocols were designed to withstand a nuclear attack - which is why it is designed without a single controlling entity. This rumor is believed to be caused by the parallel work done at RAND 1 involving design of networks for transmission of secure voice communications for the US military. The work carried out was done in parallel, and the researchers were unaware of each other during the 1960s where the work was carried out [Leiner, 2000]. The RAND document describing attacks on infrastructure is part of the RAND series On Distributed Communications Networks, [Baran, Paul, et al.].
Henrik, kan du fortælle noget om, hvor meget trafik, du har på din exit node? Hvis den samlede trafik i Tor-nettet er på ca. 10 Gbit/s, må det jo være begrænset, hvor meget trafik, der ryger gennem den enkelte node - eller hvad?
Den kører ikke max, af forskellige grunde. Det er dog noget man selv sætter ind i konfigurationen, så du kan selv vælge det.
https://support.torproject.org/relay-operators/#bandwidth-shaping
sammen medhttps://support.torproject.org/relay-operators/#limit-total-bandwidth
Bemærk også at der går en rum tid før en ny node får trafik, af designgrunde og for at undgå netværket overtages af en masse noder som nogen kunne finde på at starte.
Mht blokering af andre IPer i samme range, er det IKKE noget jeg umiddelbart ser. Jeg har dog allokeret en /24 til formålet aligevel.
Tak for uddybning af coax elendigheder, samme med GPON længere oppe.
For nu at være den irriterende kunde fortsat,
Jeres teknologivalg og begrænsninger på samme er mig uvedkommende.
I hiver jeres betingelser frem, og jeg er med på at man ikke automatisk bliver rig af at drive en ISP - eksempelvis skal TDC som netværksleverandør da nok altid sørge for at deres forretningsmodel hænger sammen.
Når I blander diskussionen om jeres betingelser med teknologibegrænsninger bliver det mudret.
Jeg checkede for sjov FAQ hos en af jer, og der tales om servere. Hvis ikke NAT var så elendigt ville jeg gerne afvikle min Big Blue Button server hjemme.
Der er også mange andre brugsituationer som I helt sikkert IKKE kan fraskrive jer. Jeg laver eksempelvis backup af min laptop, og kan snildt være det er en remote backup, eller upload af mine GoPro film fra dagens windsurfing. Der er sikkert mange fotonørder som netop i peak overfører mange Mb. Videoovervågning begynder også at blive populært. Streaming ligeså - som ihvertfald hos diverse udbydere reklameres som en brugssituation.
Når I sælger 1000/500 til 319 pr md eller 1000/560 til 269,- må I forvente et vist forbrug - også et løbende kontinuert forbrug.
Prisforskellen mellem 200/200 op til 1000/560 er forøvrigt kun 199kr vs 269kr. Er det en merpris som I forventer forbrugeren aldrig bruger?
- jeg har valgt den fordi jeg holder hackercamp i hjemmet, og gerne vil se +20 personer bruge min linie samtidig en hel forlænget weekend!
TL;DR Jeg forstår ikke jeres vilde og overdrevne fokus på Tor, og af den grund er jeg ude.
Den allervigtigste er altid den sidste måde noget gik galt på, eller hackerne kom ind på. Min liste er på ingen måde fuldstændig. Fik ikke engang plads til alt fra den interne liste over "pains" jeg vedligeholder. Tænkte dog vi skal starte et sted og max 3-5 ting kan være igang samtidig.
Jeg tror vi i mange tilfælde så vidt muligt skal undgå at netop een person, med eeet sæt hænder, på eeen konsol kan smadre hele vores infrastruktur. Der er for mange cowboys med SQL adgang.
Det er som Martin bemærker nok desværre svært i praksis.
Mit bedste bud er nok at alting går via noget configuration management, og med rollback, evt. langsomt rul udover infrastrukturen - så når 5 ud af 10 noder begynder at kaste op og smide guru meditation, så kan man trække i en nødbremse.
Nogle er så heldige at have et prod system, andre har kun udvikling og test.
Det overrasker nok ikke, men jeg er enig med Ole.
Det er blot en lang række af sager hvor eksempelvis Tor og andre værktøjer gør gavn. Jeg husker tidligere sager i Tyrkiet, Tunesien, selvf altid Kina, og det bliver ved.
Tor er et godt værktøj.
Tak også til René og Alex for at diskutere med de herrer ISPer, hvoraf den ene er min ISP hjemme privat.
Jeg vil ikke gå i en større diskussion, udover at når man sætter en Tor node op er den altid med en slags grænse for forbruget, som er lav.
Hvis en ISP ikke tillader mig, med en 1000/500 forbindelse at bruge 20Mbps på Tor, så er det fandme en nedern ISP!
Til sammenligning kan man læse på Twitter:
https://twitter.com/3Danmark/status/1428351280250966025
Grundet den ekstraordinære situation i Afghanistan kan alle vores kunder ringe og sende sms fra Danmark til Afghanistan og omvendt til 0 kr. pr. minut og sms.
Den frie mobiltrafik (opkald og SMS) gælder med tilbagevirkende kraft fra fredag den 13/8 til og med onsdag den 1/9
Gæt selv hvem jeg er stolt af at være kunde hos!
Henrik Kramselund