Dagbog-bloggen

Case study: Skat, CSC og det årlige cirkus

Nu har Skat frigivet de fleste danskeres årsopgørelser, og vanen tro er der problemer, når mange samtidig skal ind at se, om de har sparet for meget eller for lidt op hos etaten gennem året, der er gået.

Vi troede egentlig, Skat havde omgået load-problemet med en kø-løsning fra Queue-it, men denne gang ser det ud som om, Skat simpelthen har afskåret en række danskere fra deres website.

Ingen forbindelse til skat.dk

Lige nu har vores brugere ikke adgang til Skat.dk, og vi har fået meldinger om, at det også gælder kunder hos Glenten. Kunder på TDC's netværk samt flere mobiludbydere kommer derimod fint igennem.

Lidt hurtig debugging viser, at vores brugere muligvis bliver afvist i TDC's netværk:

# traceroute skat.dk
traceroute to skat.dk (147.29.150.82), 30 hops max, 60 byte packets
 1  185.107.12.49 (185.107.12.49)  40.088 ms  40.377 ms  40.618 ms
 2  10ge4-4.taas11cr2dk.gc-net.eu (212.98.127.153)  22.428 ms  22.572 ms  22.711 ms
 3  ae4-0.taas11cr1dk.gc-net.eu (77.243.33.145)  0.247 ms  0.288 ms  0.283 ms
 4  ae9-0.taas1cr2dk.gc-net.eu (77.243.32.106)  0.288 ms  0.270 ms  0.312 ms
 5  xe-9-1-1-0.alb2nqp7.dk.ip.tdc.net (195.215.170.53)  0.472 ms  0.513 ms  0.510 ms
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  *^C

TDC er en af de to udbydere, som anvendes af CSC, der hoster Skats website.

Som medlem af NLNOG RING kan vi checke, om Skats website generelt kan nås fra andre udbydere rundt omkring i verden.

Det er heldigvis simpelt - vi logger på vores egen ring-node og beder alle i ringen om at checke, om man kan hente forsiden fra skat.dk:

kviknet01:~$ ring-http -v skat.dk

Outputtet fra kommandoen er en lang liste over de forskellige deltagere i ringen, og resultatet af deres test.

Blandt de danske deltagere ser resultatet således ud:

  • Kviknet: timeout
  • Gigabit: OK
  • Fiberby: OK
  • GlobalConnect: OK
  • Larsen Data (GratisDNS): OK
  • TDC: OK
  • Zitcom: OK
  • Cloud.dk: OK
  • Nianet: OK
  • DeiC: OK
  • Siminn: OK
  • Kracon: timeout
  • Solido: timeout

119 deltagere i NLNOG RING kunne godt hente skat.dk, mens resten fejlede. Til sammenligning kunne 399 deltagere forbinde til kviknet.dk.

Det er således store dele af internettet, der ikke kan tilgå Skats website.

Sagen bringer minder frem om Post Danmark, der tilbage i starten af januar 2016 afviste vores brugere.

Det viste sig dengang, at TDC ikke havde whitelisted vores IP-adresser i deres anti-DDoS-service, som de drev for Post Danmark, og selv om de ikke ville fortælle hvorfor, lugtede det lidt af generel inkompetence krydret med en meget outdated whitelist over danske IP-adresser.

Er det mon samme problem i dag - eller er der en anden god grund til, at Skat har udelukket kunder fra vores og andre udbyderes netværk?

Og et spørgsmål mere: Hvor skal vi sende regningen for debugging hen: TDC, Skat eller CSC?

Grrrrr!

P.S. CSC annoncerer ligesom DR ingen IPv6-adresser. Hop ud af hængekøjen og kom ind i kampen...

Relateret indhold

Kommentarer (39)
Emil Stahl

Mit gæt er at det er det samme "hacking/block-af-udlandet værn" som PostNord bruger, men åbenbart ikke med en delt whitelist... Så I skal vel have fat i TDC SOC igen, mon ikke det er der den ligger?

Pinligt ligemeget hvad. Jeg kender andre med "nye" allokerede IP'er der havde samme problem.

Weekenden er en testperiode, så systemet kan være ustabilt, og adgangen fra udlandet vil være begrænset.

SKAT på Facebook

Yoel Caspersen Blogger

Mit gæt er at det er det samme "hacking/block-af-udlandet værn" som PostNord bruger, men åbenbart ikke med en delt whitelist... Så I skal vel have fat i TDC SOC igen, mon ikke det er der den ligger?

Det er også mit gæt, men hvad f***** bilder de sig egentlig ind? Det ligner jo bevidst chikane af nye udbydere.

Vi har fejlmeldt til TDC SOC, men lad os se om de holder åbent i weekenden eller om de først vågner på mandag.

Baldur Norddahl

Jeg kan melde at Gigabit er blevet delvist blokkeret hos skat.dk. Der er nogle af vores IP serier der virker og andre hvor der er blokkeret. Dem der er blokkeret er nogle vi købte for 3 år siden fra en lukket internetudbyder i Rumænien. Efterhånden har de fleste sider fundet ud af de er danske nu, men måske Skat er gået tilbage til nogle gamle lister?

Alex Holst

I januar 2017 skriver AURA på deres hjemmeside, at nogle af deres IP ranges blokeres rundt omkring:

"Men der er ikke yderligere AURA kan gøre. Så vi må henvise kunderne til at kontakte den udbyder som har fejlen (fx Viaplay, HBO Nordic osv.) og bede dem om at fejlmelde det internt"

(http://fiber.aura.dk/privat/support/driftsinformation)

Så hvor skal jeg som AURA kunde og skat-kunde sende min faktura hen? AURA? Skat? CSC? TDC?

Yoel Caspersen Blogger

Efterhånden har de fleste sider fundet ud af de er danske nu, men måske Skat er gået tilbage til nogle gamle lister?

Hvis det viser sig at være TDC, der mod bedre vidende blokerer vores net igen, går vi videre med en klage til Erhvervsstyrelsen og Skatteministeriet.

Det er jo et kæmpe retssikkerhedsmæssigt problem at Skat afskærer visse internetudbyderes kunder adgang til skat.dk - for de fleste "kunder" hos Skat er det jo ikke frivilligt, om man vil bruge deres website, og det kan være forbundet med bøder og værre konsekvenser, hvis man ikke kan indberette moms, løn osv.

Derudover er det åbenlyst et konkurrencemæssigt problem, hvis landets største teleselskab mod bedre vidende obstruerer sine konkurrenters adgang til vigtige samfundsfunktioner.

Hvad er det næste, der skal lukkes for? Hvilke andre vigtige websites skal "beskyttes" af en klamphuggerløsning, der påstår at lukke for udenlandske IP-adresser, men immervæk efterlader døren pivåben for ca. 30 % af internettet, samtidig med at den blokerer for en lang række danske IP-adresser, der ikke skulle have været blokeret?

Yoel Caspersen Blogger

Har netop modtaget en bekræftelse fra TDC SOC, der har whitelisted vores IP-adresser kl. 21:45.

Nu er situationen så, at vores kunder igen har adgang, mens en række andre operatørers kunder fortsat er afskåret fra skat.dk.

Samtidig er der en lang række udenlandske IP-adresser, der har adgang til skat.dk, så hvis TDC har solgt løsningen på at alle udenlandske IP-adresser skulle blokeres, er leverancen i bund og grund fejlet.

Vi er nødt til at have klarhed over, hvordan det kan ske, at TDC blokerer vilkårlige IP-adressers adgang til en af landets vigtigste websites på en af de allervigtigste dage.

Den forklaring får vi næppe fra TDC, som vil afvise at løfte sløret for deres sikkerhedsløsning med henvisning til security by obscurity, og fra Kviknets side bliver vi derfor nødt til at følge sagen til dørs gennem hhv. Erhvervsstyrelsen som ansvarlig for den konkurrencemæssige vinkel og Skatteministeriet som ansvarlig for skat.dk.

Skulle der sidde nogle operatører derude, som er ramt af problemet, og som ønsker at være med i den videre proces, er I velkommen til at kontakte undertegnede.

Lars Skovlund
Yoel Caspersen Blogger

Til information er vores adresser nu ikke længere blokeret

Vi kan se, TDC tilsyneladende har haft travlt. I går aftes var det kun 119 ud af ca. 400 nodes hos NLNOG RING, som kunne nå skat.dk, og her til morgen var tallet oppe på 163 nodes.

AS60111 har IP-adresser, der ligger inden for 185.0.0.0/8. Det samme gælder Glenten.dk og Kviknet.dk - og TDC har meldt tilbage, at lige netop det scope var blokeret, men at de har ophævet blokeringen nu.

Det ændrer dog ikke på, at man tilsyneladende har brugt en ukurant liste over danske IP-adresser - og da vi for ca. 14 måneder siden gjorde TDC opmærksom på fejlen i deres liste, har de haft rigelig tid til at løse problemet i mellemtiden.

Geo-blokering baseret på IP-adresser har nogle indbyggede begrænsninger, og når man så parrer det med en åbenlyst forældet liste over IP-adresser, skriger det til himlen, at det ikke er den rigtige måde at løse et forudsigeligt load-problem på. Og at TDC måske heller ikke er den rigtige partner til at udføre den opgave for Skat.

Kristian Pedersen

Det ændrer dog ikke på, at man tilsyneladende har brugt en ukurant liste over danske IP-adresser - og da vi for ca. 14 måneder siden gjorde TDC opmærksom på fejlen i deres liste, har de haft rigelig tid til at løse problemet i mellemtiden.

Geo-blokering baseret på IP-adresser har nogle indbyggede begrænsninger, og når man så parrer det med en åbenlyst forældet liste over IP-adresser, skriger det til himlen, at det ikke er den rigtige måde at løse et forudsigeligt load-problem på. Og at TDC måske heller ikke er den rigtige partner til at udføre den opgave for Skat.

Absolut enig. Det er en dårlig sag.

Men TDC er bestemt ikke de eneste der praktiserer brugen af brede ikke-opdaterede ip-lister som firewall-filtre og/eller geo-blokering, det er en trend vi ser hos mange både store og små firmaer. Som operatør er det begrænset hvad man kan gøre, og kunderne har ringe forståelse for problemet: "Jamen det virker på mobil bredbånd, så det må være jer der har en fejl .. ".

Baldur Norddahl

Vi kan se, TDC tilsyneladende har haft travlt.

Ikke så travlt... følgende af vores serier er stadig blokeret:

85.204.120.0/23
85.204.132.0/23
85.204.136.0/23
85.204.194.0/23

Det er 2000 danske familier der fortsat ikke har adgang til Skat. Hvordan kan myndighederne forsvare det?

Inden at TDC haster med også at whiteliste igen igen, så skulle man måske overveje om man har overholdt kontrakten med en IP liste der er mindst 3 år gammel. Ja vi har haft danske kunder på disse IP adresser i så lang tid. Hvornår bliver man erstatningsansvarlig når man ikke vedligeholder et "sikkerhedsprodukt" i årevis?

Jn Madsen

Det er sgu sørgeligt, at min gamle legeplads TDC halter på den måde.

De ansætter masser af reklamefolk, strateger, analytikere, webdesignere osv. De taler også et fælles sprog, noget med flotte PowerPoints.

Hardcore erfarne teknikere bliver losset ud i de årlige fyringsrunder. Teknik er sådan noget "simpelt" laverestående noget, de bruger f.eks. ikke ord som visioner og koncept i deres formuleringer.

Teknisk personale skal bare minimeres og helst outsources. Landets største og mest komplekse teknologivirksomhed skal drives af folk med et fluffy ordforråd, ikke folk der ved hvad BGP er.

Jens Jönsson

AS60111 har IP-adresser, der ligger inden for 185.0.0.0/8. Det samme gælder Glenten.dk og Kviknet.dk - og TDC har meldt tilbage, at lige netop det scope var blokeret, men at de har ophævet blokeringen nu.

Så har vi hos Skywire også været ramt. Det er ikke mere end et par måneder siden, at vi fik vores IPv4 adresser, som netop ligger indenfor den range.
Underligt at vi ikke har hørt noget i supporten om problemet...

Jens Jönsson
Jesper Hartoft
Jesper Wolf Jespersen

Der har i flere år været en religionskrig på nettet om hvorvidt man skal blokere for ICMP protokollen,.
På den ene side er den nødvendig for en masse grundlæggende services, men på den anden side er den åben for denial of service attacks.

Det har ført til at mange konfigurerer firewalls og routere til at strippe ICMP protokollen.
Der er et partsindlæg i sagen her hvis i tvivler på hvad jeg siger:
http://shouldiblockicmp.com/

Jeg bruger Gigabit.dk som IP provider og har IP adresse i et af de IP ranges som Baldur Nordahl nævner ikke kan nå skat.dk.
Men jeg kan faktisk godt nå skat.dk via TCP på port 80 og 443 som er de relevante protokoller og porte her (jeg var faktisk inde og checke min skat inden denne tråd blev startet).

Jeg kan ikke lave traceroute fordi en eller anden router/firewall er konfigureret på simpleste sæt, så man ikke risikerer denial of service angreb via ICMP.

Jeg tvivler på at der bruges whitelists separat på TCP/UDP og ICMP, tror nærmere på at udbyderen har gammelt udstyr der ikke kan lave rate control på ICMP pakker, eller af religiøse grunde bare har slukket for protokollen.

Det virker lidt useriøst at i sidder og skælder TDC ud for at være inkompetente og så benytter et upålideligt værktøj i bevisførelsen.

Jeg er selv tilhænger af ICMP protokollen fordi den gør det meget lettere at fejlfinde i komplekse netværk. Men har været nødt til at erkende at det ikke er mig der bestemmer den slags.

Hvis i vil virke seriøse så lav dog en seriøs undersøgelse, det kræver ikke særlige værktøjer, telnet er nok.

kommando adresse port
tel-net skat.dk 80
tel-net skat.dk 443

Desværre forhindrer denne hjemmeside mig i at indtaste kommandoen telnet i ovenstående skema men i kan sikkert selv fjerne den overflødige bindestreg.

Hvis man får forbindelse får man en blank skærm og skal trykke på <ctrl>^ for at komme til telnet prompten hvor man skal skrive quit for at komme ud.
Hvis man ikke får forbindelse melder programmet fejl efter et minuts tid.

Nu ved man konklusivt om der kan skabes forbindelse eller ej, og om der er noget at klage over.

Det er mere sandsynligt at TDC lytter når har undersøgt sagen rigtigt :-)

Yoel Caspersen Blogger

Hvis i vil virke seriøse så lav dog en seriøs undersøgelse, det kræver ikke særlige værktøjer, telnet er nok.

Overså du brugen af ring-http i blogindlægget?

Det er en kommando, som foretager et HTTP-opslag mod Skat.dk.

Når jeg også har inkluderet traceroute, er det for at få en ide om hvor problemet ligger.

En tilsvarende traceroute fra TDC's net nåede hele vejen ind til CSC - hvilket måske burde have fremgået tydligere af blogindlægget. Derfor kunne vores traceroute give et fingerpeg om, hvor i nettet pakkerne blev droppet.

Jeg bruger Gigabit.dk som IP provider og har IP adresse i et af de IP ranges som Baldur Nordahl nævner ikke kan nå skat.dk.
Men jeg kan faktisk godt nå skat.dk via TCP på port 80 og 443 som er de relevante protokoller og porte her (jeg var faktisk inde og checke min skat inden denne tråd blev startet).

Jeg har svært ved at forestille mig, at Baldur Norddahl ikke skulle kunne finde ud af at lave en rigtig test af hvorvidt der er blokeret for adgang til Skats website fra de pågældende IP-adresser - det ville faktisk undre mig rigtig meget.

Så det kunne måske være, at blokeringen har været aktiv på et tidspunkt, hvor du ikke selv har været inde at kigge - og så er blevet fjernet igen?

Det er mere sandsynligt at TDC lytter når har undersøgt sagen rigtigt :-)

Det tror jeg til gengæld, du har helt ret i.

Jesper Wolf Jespersen

Hej Yoel.

>>Overså du brugen af ring-http i blogindlægget?

Nej det gjorde jeg ikke, men det kan jo kun vise hvordan det ser ud fra ring noderne, ikke hvordan det ser ud fra de forskellige subnet.

Og du snyder dig selv hvis du tror at tracert hjælper dig med at finde synderen for du kan ikke skelne mellem om det er ICMP der bliver blokeret eller IP, så du risikerer at famle i blinde.

>>Så det kunne måske være, at blokeringen har været aktiv på et tidspunkt,
>>hvor du ikke selv har været inde at kigge - og så er blevet fjernet igen?

Er du ikke lidt langt ude på fantasiens overdrev her, jeg har været på skats hjemme side flere gange i weekenden og var på da Baldur skrev sit indlæg?

Loyalitet er en fin ting, men lad nu være med at overdrive.

Vi kan blive enige om at det er noget skidt når visse net ikke kan nå en service som skat.dk, men der er ikke nogen grund til at gå til angreb på TDC eller CSC hvis der ikke er noget problem.

Fortsat god weekend :-)

Baldur Norddahl

Nej det gjorde jeg ikke, men det kan jo kun vise hvordan det ser ud fra ring noderne, ikke hvordan det ser ud fra de forskellige subnet.

Det er faktisk lidt tricky at teste fra specifikke subnets (uanset om vi snakker ICMP, UDP eller TCP). Måden jeg gør det på er at bruge vores router. Den har en IP adresse på samtlige subnets, nemlig den adresse der bruges som default gateway for det pågældende subnet. Det er muligt at køre telnet og specificere source adressen til en af disse gateway adresser:

albertslund-edge1#telnet 147.29.150.82 80 vrf internet 85.204.120.1                                                                                                                  
Open  
   
Attention: Telnet Escape character is ctrl+']'  
   
Connection closed  
albertslund-edge1#

Hvis der er blokeret vil ovenstående give en timeout i stedet.

Jeg må tilstå at jeg ikke metodisk har testet samtlige /24 subnets som vi har. Vi har en del. Jeg konstaterede at det virkede for vores 185.24.168.0/22 og også fra 195.192.248.0/23 og 212.237.96.0/20. Men at det fejlede fra min egen adresse i 85.204.132.0/23 subnettet samt for mange af vores kunder (support mailen er fyldt med klager og se også vores Facebook side). Jeg har derudover lavet lidt stikprøve kontrol. Gigabit var derfor delvist blokeret og det er nærliggende at antage at blokeringen galt de fire blokke (de er købt sammen).

Der er ikke længere blokeret for de adresser jeg har testet på.

Ove Andersen

Hvad gør man egentligt når man som privat kunde er blokeret? Kontakter sin ISP?

Har Bredbånd Nord fiber og vi har heller ikke adgang til skat.dk. Får bare time-out.

Sidder på 85.191.217.0/26

Yoel Caspersen Blogger

Og du snyder dig selv hvis du tror at tracert hjælper dig med at finde synderen for du kan ikke skelne mellem om det er ICMP der bliver blokeret eller IP, så du risikerer at famle i blinde.

Du har ret i din karakteristik af traceroute - men nu er det jo langt fra kun traceroute, vi har brugt. Samlet er diagnosen stillet ud fra følgende:

  • HTTP til Skat.dk timede ud for 3/4 af ring-noderne inklusive vores
  • Emil Stahl henviste til Skats udmelding om at udenlandske IP-adresser kunne være blokeret her i weekenden
  • Vi ved fra tidligere, at TDC før har lavet en lignende fejl
  • Traceroute viste, at noget var blokeret hos TDC, når man kom fra vores net, men ikke når man kom fra TDC's eget net - om det så var ICMP, HTTP eller begge dele er et åbent spørgsmål. Linux bruger mig bekendt UDP til traceroute, medmindre man tvinger den til at bruge ICMP
  • TDC er den ene af CSC's transit providers (og den eneste relevante i dansk sammenhæng)
  • CSC er, sorry to say, ikke kendt for at have en sund og kompetent indstilling til sikkerhed

Hvis man skulle tage en bayesiansk vinkel og tildele hvert punkt et antal point, er der ingen tvivl om at TDC bongede rimelig kraftigt ud på blame-skalaen.

Nå ja, som en mindre detalje kan i øvrigt tilføjes, at de faktisk har tilstået og løst problemet for lige præcis vores vedkommende - og senere hen også for mange andres.

Vi kan blive enige om at det er noget skidt når visse net ikke kan nå en service som skat.dk, men der er ikke nogen grund til at gå til angreb på TDC eller CSC hvis der ikke er noget problem.

Nu var der beviseligt og uomtvisteligt et problem - og så er det vel fair nok at placere aben, hvor den hører hjemme?

At lukke for et stort antal danske brugeres adgang til skat.dk, fordi man bruger en gammel liste over IP-adresser, på trods af at man 14 måneder tidligere blev grebet i præcis samme manøvre, er efter min mening ikke et udtryk for solid kompetence.

Det er bare for dumt, ganske enkelt.

Yoel Caspersen Blogger

Hvad gør man egentligt når man som privat kunde er blokeret? Kontakter sin ISP?

Har Bredbånd Nord fiber og vi har heller ikke adgang til skat.dk. Får bare time-out.

Sidder på 85.191.217.0/26

Du er nok nødt til at kontakte din ISP, og foreslå dem at kontakte TDC SOC. Hvis de mangler kontaktoplysninger, er de velkommen til at tage fat i undertegnede.

Jf. RIPE burde du kunne skrive til din ISP på drift@bredbaandnord.dk og forvente en nogenlunde hurtig respons.

I øvrigt spøjst at din IP-adresse starter med 85 ligesom de adresser hos Gigabit, der tidligere var blokeret. Måske en tilfældighed, måske ikke.

Jesper Hartoft
Baldur Norddahl

Det virker til at 85.204.194.0/23 stadig er blokeret. De andre ser ud til at virke.

Spørgsmålet er hvorfor indlæser de ikke bare en frisk IP liste fra Maxmind eller hvor de nu har dem fra i første omgang? Kunne man frygte at det er fordi de ikke kan?

Anders Søndergaard

Yoel skrev:

Traceroute viste, at noget var blokeret hos TDC, når man kom fra vores net, men ikke når man kom fra TDC's eget net - om det så var ICMP, HTTP eller begge dele er et åbent spørgsmål. Linux bruger mig bekendt UDP til traceroute, medmindre man tvinger den til at bruge ICMP

Du kunne have lukke spørgsmålet ved at bruge -T -p 80 eller -T -p 443. Traceroute via TCP port 80 eller 443. Pr. default bruger den traceroute der kommer med Debian UDP. Ifølge manualen port 53 men ifølge Wireshark dump en tilfældig højt nummereret port.

Baldur Norddahl

Du kunne have lukke spørgsmålet ved at bruge -T -p 80 eller -T -p 443.

Det er desværre ikke supporteret af vores router, så det er ikke nemt. Måske vi er heldige at en af de berørte kunder i 85.204.194.0/23 vil prøve det. Resultatet er dog givet på forhånd da TDC som sagt har tilstået - pakkerne vil blive droppet ved TDCs firewall uanset hvilken type pakker der er tale om.

Jesper Wolf Jespersen

Det er kun nyere versioner af unix/linux der har en traceroute der supporterer -T argumentet.
De fleste understøtter kun ICMP protokollen.

Men der findes muligheder selv for Windows, på siden: https://support.opendns.com/hc/en-us/articles/227989007-How-to-Running-a...

Kan man finde en version der virker på Microsofts operativsystem også.

Og så kan man faktisk se hele vejen fra kilden til destinationen, men det kræver man installerer en driver og et program, så det er nok mest for den entusiastiske bruger der selv vil diagnosticere.

Værktøjet er formidabelt til at finde huller i osten, man kan håbe det bliver generelt anvendeligt (også i driftcentre hvor der vanker bank eller fyring hvis man installerer uautoriserede programmer).

Det ville gøre weekendens problemer noget nemmere at håndtere hvis man bare kunne bede kunden om at køre en tracetcp skat.dk:443 og sende en resultatet i en mail :-)

Det har vist været en besværlig weekend for vore ISP'er og det ser ikke ud til at være helt slut endnu, så vi må bare sige tak for indsatsen og håbe at de har lidt damp tilbage til at få hevet de sidste forbindelser hjem :-)

Martin Dahlem

Dem der er blokkeret er nogle vi købte for 3 år siden fra en lukket internetudbyder i Rumænien. Efterhånden har de fleste sider fundet ud af de er danske nu, men måske Skat er gået tilbage til nogle gamle lister?

Ah så giver det mere mening, hvorfor der jævnligt er nogle webshops som mener jeg sidder i Rumænien når jeg bestiller ting, og endda nogle som ikke har lyst til at sende ting til en dansk adresse, bestilt fra en IP dernede :-( Men ja sådanne lister er fantastiske, hvis de endnu ikke er opdateret.

Log ind eller Opret konto for at kommentere