yoel caspersen blog bloghoved

Case study: Smider Post Danmark vores pakker væk?

Af 54

Som læserne ved, har man som iværksætter ikke tid til at se skihop 1. januar, men må i stedet passe forretningen og løse de fejl, der opstår.

Vi har nu været oppe at køre med vores setup i ca. 1 uges tid, og jeg har haft mulighed for at teste det af.

Det virker fremragende - lige bortset fra, at vi ikke kan tilgå Post Danmarks website. Hvis en bruger på vores netværk åbner www.postdanmark.dk, står browseren og hænger, indtil den fejler med en timeout.

Nå, så er det tid til lidt fejlfinding. På kontoret har jeg en Bredbånd Basic-forbindelse, der kører på TDC's netværk. Her virker det fint:

$ wget -O /dev/null "http://www.postdanmark.dk"
--2016-01-01 10:12:34--  http://www.postdanmark.dk/
Resolving www.postdanmark.dk (www.postdanmark.dk)... 147.14.11.143
Connecting to www.postdanmark.dk (www.postdanmark.dk)|147.14.11.143|:80... connected.
HTTP request sent, awaiting response... 302 Redirect
Location: http://www.postdanmark.dk/da/privat/Sider/privat.aspx [following]
--2016-01-01 10:12:34--  http://www.postdanmark.dk/da/privat/Sider/privat.aspx
Reusing existing connection to www.postdanmark.dk:80.
HTTP request sent, awaiting response... 200 OK
Length: 84019 (82K) [text/html]
Saving to: ‘/dev/null’
 
100%[================================>] 84.019       329KB/s   in 0,2s
 
2016-01-01 10:12:35 (329 KB/s) - ‘/dev/null’ saved [84019/84019]

Som vi kan se, connecter vores klient til www.postdanmark.dk på port 80. Herfra får den en HTTP 302 redirect til en underside - det ser helt kosher ud.

Næste test: Samme øvelse på router-1:

# wget -O /dev/null "http://www.postdanmark.dk"
--2016-01-01 10:13:46--  http://www.postdanmark.dk/
Resolving www.postdanmark.dk (www.postdanmark.dk)... 147.14.11.143
Connecting to www.postdanmark.dk (www.postdanmark.dk)|147.14.11.143|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: /LkakZ/ [following]
--2016-01-01 10:13:46--  http://www.postdanmark.dk/LkakZ/
Connecting to www.postdanmark.dk (www.postdanmark.dk)|147.14.11.143|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: / [following]
--2016-01-01 10:13:46--  http://www.postdanmark.dk/
Connecting to www.postdanmark.dk (www.postdanmark.dk)|147.14.11.143|:80... connected.
HTTP request sent, awaiting response...

Og herefter sker der ingenting, indtil forbindelsen timer ud. Det er lidt interessant - den første forespørgsel til webserveren lykkedes, hvorefter vi får en redirect til /LkakZ/ - når jeg åbner http://www.postdanmark.dk/LkakZ/ på min arbejds-PC, får jeg en pæn fejl-side, der fortæller, at siden ikke blev fundet:

Illustration: Privatfoto

Men på router-1 får jeg en redirect til "/" igen, dvs. der hvor jeg startede. WTF?

Nu vil jeg ikke pege på Post Danmark, før jeg har undersøgt problemet yderligere. Så lad os se på, hvad der ellers kan være galt.

Som udgangspunkt virker forbindelsen til serveren, da jeg connecter og får en HTTP 302 Redirect fra serveren. Det beviser efter min mening følgende:

  • DNS-opslag virker fint
  • Der er en fungerende route mellem min offentlige IPv4-adresse og Post Danmarks ditto
  • Der er også en fungerende route den anden vej

Hvad kan der så ellers være galt i vores ende? Well, et HTTP redirect fylder ikke alverden, så hvis der er et MTU-issue med vores forbindelse, kan det være, de små pakker går igennem, mens de store pakker med HTML-indhold fra www.postdanmark.dk går tabt.

Lad os verificere, at vores MTU er sat korrekt - først skal vi lige checke, hvilket interface vi anvender til vores forespørgsel:

router-1# sh ip route 147.14.11.143
Routing entry for 147.14.0.0/16
  Known via "bgp", distance 20, metric 0, vrf 0, best
  Last update 01w1d16h ago
  * 212.98.127.93, via bond0.10

Aha. Vores interface er bond0.10 - lad os kigge på MTU-settingen på bond0.10:

# ifconfig bond0.10
bond0.10  Link encap:Ethernet  HWaddr 90:1b:0e:62:a8:22  
          inet addr:212.98.127.94  Bcast:212.98.127.95  Mask:255.255.255.252
          inet6 addr: 2a01:7e8:1:800::1c2/126 Scope:Global
          inet6 addr: fe80::921b:eff:fe62:a822/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2066508046 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3783854424 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:3714050861226 (3.7 TB)  TX bytes:710260177401 (710.2 GB)

MTU står umiddelbart til 1500. Lad os checke, om det nu rent faktisk virker i praksis - hvis jeg tester IP-adressen 212.98.127.94 (IP-adressen på bond0.10) udefra på http://www.letmecheck.it/mtu-test.php, får jeg at vide, at vores maximum MTU size er 1500.

Det er jo lige som det skal være - lad os prøve det samme på Post Danmarks IP-adresse 147.14.11.143. Så får jeg følgende svar:

Sending 32 bytes to 147.14.11.143  <-  NO REPLY!
 
We are unable to test this host or IP.
Most likely ICMP traffic to that host or IP is not allowed or the host or IP is invalid.

Hm - det passer også med, at vi ikke kan lave en komplet traceroute til deres IP-adresse:

# traceroute 147.14.11.143
traceroute to 147.14.11.143 (147.14.11.143), 30 hops max, 60 byte packets
 1  212.98.127.93 (212.98.127.93)  0.226 ms  0.351 ms  0.519 ms
 2  ae0-0.taas1cr3dk.gc-net.eu (77.243.32.142)  0.205 ms  0.212 ms  0.217 ms
 3  xe-9-1-1-0.alb2nqp7.dk.ip.tdc.net (195.215.170.53)  0.457 ms  0.445 ms  0.434 ms
 4  xe-0-3-1-0.alb2nqe10.dk.ip.tdc.net (83.91.92.229)  0.553 ms  0.588 ms  0.621 ms
 5  te4-1-439.tg4-pe5.sto.se.ip.tdc.net (213.50.123.53)  9.578 ms  9.631 ms  9.674 ms
 6  cpe.te4-1-439.tg4-pe5.sto.se.customer.tdc.net (213.50.123.54)  9.708 ms  9.370 ms  9.468 ms
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * *^C

Det kunne tyde på, at postvæsenet har en meget ristriktiv firewall på deres server, der ikke tillader udgående ICMP-pakker, så vi kan ikke umiddelbart fastslå, om deres max MTU size også er 1500.

Serveren ser i øvrigt ser ud til at stå i Stockholm - hvilket giver mening, da Post Danmark er blevet fusioneret med svenske PostNord.

Mon de har et problem internt i deres system, hvis man kommer fra vores IP-adresser? Billedet ser ud til at være det samme, uanset om vi connecter fra IP-adresserne nævnt her, som tilhører GlobalConnect, eller om vi connecter fra vores egne, RIPE-registrerede IP-adresser.

Næste stop Sverige

Næste udfordring: Vi skal have fat i Post Danmark og spurgt, om de kan se nogen problemer i deres system, hvis man kommer fra vores IP-adresser.

Hm... jeg ved allerede på forhånd, at det ikke giver nogen mening at ringe til deres såkaldte kundeservice. For det første ved de det ikke, for det andet er de ligeglade og for det tredie får man nok lov at sidde i en telefonkø i evigheder, hvis man overhovedet kan finde et telefonnummer.

Vi skal have fat i folkene i maskinrummet - i deres NOC, eller BOFH, eller hvem det nu er, de har til at administrere deres system:

# whois 147.14.11.143
... (en masse irrelevante detaljer)
% No abuse contact registered for 147.14.0.0 - 147.14.127.255
 
inetnum:        147.14.0.0 - 147.14.127.255
netname:        NET-SWEPONET-STH
descr:          Posten Sverige AB
descr:          Swedish Post
country:        SE
admin-c:        HP665-RIPE
tech-c:         HP665-RIPE
status:         LEGACY
mnt-by:         POSTEN-MNT
mnt-routes:     POSTEN-MNT
created:        2003-05-27T06:50:52Z
last-modified:  2014-05-27T12:56:58Z
source:         RIPE # Filtered
 
# whois HP665-RIPE
... (en masse irrelevante detaljer)
address:        Europoint AB
address:        Slattervagen 6
address:        S-756 46 Uppsala
address:        Sweden
phone:          +46 705 22 01 10
fax-no:         +46 706 15 01 10
nic-hdl:        BS337
mnt-by:         EUROPOINT-MNT
created:        2002-08-15T06:42:11Z
last-modified:  2002-08-15T06:42:11Z
source:         RIPE # Filtered

En svensk BOFH uden e-mailadresse. Jeg kan levende forestille mig samtalen på en tømmermandsramt 1. januar, selv hvis det skulle lykkes mig at komme igennem:

»Ursäkta mig, jag ringer från Kviknet i Danmark. Jag tror att ni har ett problem med er hemsida...«

Lang pause.

»Jag tror, ni ringt fel... DUT DUT DUT DUT«

Jeg er sikker på, den svenske sysadmin er en venlig herre, men jeg ønsker ikke at forstyrre ham på en højhellig 1. januar, før jeg har undersøgt alle andre muligheder.

Jeg håber bestemt, fejlen ligger i vores ende, for så kan vi selv gøre noget ved den nu. Er der noget, jeg har overset - nogle andre tests, jeg bør foretage?

Kommentarer (54)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Christian E. Lysel

Kan du ikke teste http sessionen med nc eller telnet til port 80, skriv fx

telnet 147.14.11.143 GET / http/1.1 host: www.postdanmark.dk

Jeg er meget interesseret i at se hvilke server header du får.

Fra Linux kan du checke MTU på de enkelte hop med tracepath og måske komme længere med traceroute med hping3 --traceroute -V -S -p 80 -s 4444 147.14.11.143

Jeg tvivler dog det er MTU, den første http redirect peger i retning af du rammer den anden server, eller måske rammer en fejl i wget.

Har du en tcpdump af de sidste 10 pakker fra sessionen?

  • 4
  • 0
#2 Yoel Caspersen Blogger

Tak for dit forslag Christian.

# telnet 147.14.11.143 80  
Trying 147.14.11.143...  
Connected to 147.14.11.143.  
Escape character is '^]'.  
GET / HTTP/1.1  
Host: www.postdanmark.dkHTTP/1.1 302 Found  
Connection: close  
Pragma: no-cache  
cache-control: no-cache  
Location: /QVeKZ/  
   
Connection closed by foreign host.  
# Host: www.postdanmark.dk

Som du kan se, lukker serveren forbindelsen med en redirect før den overhovedet modtager Host-headeren.

Jeg har kørt wget med -d (debug). Outputtet er for stort til at poste her, men jeg har lagt det på https://www.kviknet.dk/misc/wget_debug.txt så det kan hentes der.

hping3 når ikke så langt, før den stopper:

# hping3 --traceroute -V -S -p 80 -s 444 147.14.11.143  
using bond0.10, addr: 212.98.127.94, MTU: 1500  
HPING 147.14.11.143 (bond0.10 147.14.11.143): S set, 40 headers + 0 data bytes  
hop=1 TTL 0 during transit from ip=212.98.127.93 name=UNKNOWN     
hop=1 hoprtt=3.6 ms  
hop=2 TTL 0 during transit from ip=77.243.32.142 name=ae0-0.taas1cr3dk.gc-net.eu  
hop=2 hoprtt=3.7 ms  
hop=3 TTL 0 during transit from ip=195.215.170.53 name=xe-9-1-1-0.alb2nqp7.dk.ip.tdc.net  
hop=3 hoprtt=3.5 ms  
^C  
--- 147.14.11.143 hping statistic ---  
79 packets transmitted, 3 packets received, 97% packet loss  
round-trip min/avg/max = 3.5/3.6/3.7 ms

Jeg har taget et tcpdump:

tcpdump -i bond0.10 host 147.14.11.143 -w /tmp/debug.pcap

Det kan hentes her: https://www.kviknet.dk/misc/debug.pcap

  • 2
  • 0
#3 Benny Simonsen

Edit: havde ikke set kommentar #2 inden jeg skrev min kommentar /EDIT

Min tanke var at det kan jo være forskelligt indhold om der er sat en referrer header (+ alle mulige andre headers) og skulle lige prøve det.

Men det ser nærmere ud til at der er random 302 redirects fra gang til gang på samme forbindelse (fiber fra bredbaand nord (waoo) - I hvert fald med wget, har ikke checket hvad der sker med Firefox, der ses redirects jo ikke umiddelbart (men ender på en fejlside for /WXdLZ og /abc).

Systemet ser lidt ud til at være: Redirect til "sub-side" og redirect tilbage og hæng der, de 2 redirects er nogle gange undladt. Jeg har prøvet at hente http://www.postdanmark.dk/WXdLZ nogle gange -> hver gang hænger den uden redirects Jeg har også prøvet http://www.postdanmark.dk/abc med samme resultat.

Til gengæld kan jeg ikke se at referrer har noget at sige, men det er jo lidt svært at se om det påvirker tilfældighedsredirecteren :-).

Du kan da lave en track-and-trace på de manglende pakker på http://postdanmark.dk/tt :-).

Jeg ved ikke lige hvad det kan bruges til, men opleverer også noget "sjovt" her.

benny@hemsedal:~ > wget --referer=http://www.postdanmark.dk http://www.postdanmark.dk/LkakZ  
--2016-01-01 13:11:46--  http://www.postdanmark.dk/LkakZ  
Resolving www.postdanmark.dk (www.postdanmark.dk)... 147.14.11.143  
Connecting to www.postdanmark.dk (www.postdanmark.dk)|147.14.11.143|:80... connected.  
HTTP request sent, awaiting response... 302 Found  
Location: /QoOhZ/LkakZ [following]  
--2016-01-01 13:11:46--  http://www.postdanmark.dk/QoOhZ/LkakZ  
Connecting to www.postdanmark.dk (www.postdanmark.dk)|147.14.11.143|:80... connected.  
HTTP request sent, awaiting response... 302 Found  
Location: /LkakZ [following]  
--2016-01-01 13:11:46--  http://www.postdanmark.dk/LkakZ  
Connecting to www.postdanmark.dk (www.postdanmark.dk)|147.14.11.143|:80... connected.  
HTTP request sent, awaiting response... ^C    
benny@hemsedal:~ > wget http://www.postdanmark.dk/LkakZ--2016-01-01 13:19:20--  http://www.postdanmark.dk/LkakZ  
Resolving www.postdanmark.dk (www.postdanmark.dk)... 147.14.11.143  
Connecting to www.postdanmark.dk (www.postdanmark.dk)|147.14.11.143|:80... connected.  
HTTP request sent, awaiting response... 302 Found  
Location: /WXdLZ/LkakZ [following]  
--2016-01-01 13:19:21--  http://www.postdanmark.dk/WXdLZ/LkakZ  
Connecting to www.postdanmark.dk (www.postdanmark.dk)|147.14.11.143|:80... connected.  
HTTP request sent, awaiting response... 302 Found  
Location: /LkakZ [following]  
--2016-01-01 13:19:21--  http://www.postdanmark.dk/LkakZ  
Connecting to www.postdanmark.dk (www.postdanmark.dk)|147.14.11.143|:80... connected.  
HTTP request sent, awaiting response... ^C                        
benny@hemsedal:~ > wget --referer=http://www.postdanmark.dk http://www.postdanmark.dk/LkakZ  
--2016-01-01 13:20:05--  http://www.postdanmark.dk/LkakZ  
Resolving www.postdanmark.dk (www.postdanmark.dk)... 147.14.11.143  
Connecting to www.postdanmark.dk (www.postdanmark.dk)|147.14.11.143|:80... connected.  
HTTP request sent, awaiting response... ^C  
[bash]
  • 3
  • 0
#4 Michael Rasmussen

Som det fremgår af nedenstående, har man ikke samme problemer, såfremt man er tilkoblet via TDC!!!

Kunne det være noget http connection, der driller? (http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html) Reusing existing connection to www.postdanmark.dk:80.

$ wget -O /dev/null "http://www.postdanmark.dk"  
--2016-01-01 13:56:46--  http://www.postdanmark.dk/  
Resolving www.postdanmark.dk (www.postdanmark.dk)... 147.14.11.143  
Connecting to www.postdanmark.dk (www.postdanmark.dk)|147.14.11.143|:80... connected.  
HTTP request sent, awaiting response... 302 Found  
Location: http://www.postdanmark.dk/da/privat/Sider/privat.aspx [following]  
--2016-01-01 13:56:46--  http://www.postdanmark.dk/da/privat/Sider/privat.aspx  
Reusing existing connection to www.postdanmark.dk:80.  
HTTP request sent, awaiting response... 200 OK  
Length: 84025 (82K) [text/html]  
Saving to: ‘/dev/null’  
   
/dev/null           100%[===================>]  82,06K   398KB/s    in 0,2s      
   
2016-01-01 13:56:47 (398 KB/s) - ‘/dev/null’ saved [84025/84025]
  • 1
  • 0
#5 Claus Bruun

Hos mig giver det via gigabits net den korrekte url.

Det, der undrer mig, er at du får mærkelige redirects istedet for den rigtige = da/privat/Sider/privat.aspx

For mig ligner det en redirect, der skal sende sid ind på den rigtige side baseret på sprog. Er det noget GeoIP for kviknet, der er forkert ?

Såden ser det ud herfra C:\utils\GetGnuWin32\GetGnuWin32\gnuwin32\bin\wget.exe -d "http://www.postdanmark.dk" SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc syswgetrc = C:\utils\GetGnuWin32\GetGnuWin32\gnuwin32/etc/wgetrc DEBUG output created by Wget 1.11.4 on Windows-MinGW.

--2016-01-01 13:53:34-- http://www.postdanmark.dk/ Løser www.postdanmark.dk...seconds 0,00, 147.14.11.143 Caching www.postdanmark.dk => 147.14.11.143 Connecting to www.postdanmark.dk|147.14.11.143|:80... seconds 0,00, forbundet. Created socket 436. Releasing 0x0101d3c0 (new refcount 1).

---request begin--- GET / HTTP/1.0 User-Agent: Wget/1.11.4 Accept: / Host: www.postdanmark.dk Connection: Keep-Alive

---request end--- HTTP forespørgsel sendt, afventer svar... ---response begin--- HTTP/1.1 302 Redirect connection: keep-alive content-length: 176 content-type: text/html; charset=UTF-8 date: Fri, 01 Jan 2016 12:53:33 GMT location: http://www.postdanmark.dk/da/privat/Sider/privat.aspx p3p: CP="NON CUR OTPi OUR NOR UNI" server: Microsoft-IIS/7.5 x-ms-invokeapp: 1; RequireReadOnly x-powered-by: ASP.NET x-sharepointhealthscore: 0 sprequestguid: 40d27275-8ce1-4f40-97cd-21aeaec57835

---response end--- 302 Redirect Registered socket 436 for persistent reuse. Sted: http://www.postdanmark.dk/da/privat/Sider/privat.aspx [omdirigeret] Skipping 176 bytes of body: [Document Moved

Object Moved

This document may be found here] done. --2016-01-01 13:53:34-- http://www.postdanmark.dk/da/privat/Sider/privat.aspx Reusing existing connection to www.postdanmark.dk:80. Reusing fd 436.

---request begin--- GET /da/privat/Sider/privat.aspx HTTP/1.0 User-Agent: Wget/1.11.4 Accept: / Host: www.postdanmark.dk Connection: Keep-Alive

---request end--- HTTP forespørgsel sendt, afventer svar... ---response begin--- HTTP/1.1 200 OK connection: keep-alive content-length: 84025 content-type: text/html; charset=utf-8 date: Fri, 01 Jan 2016 12:53:34 GMT last-modified: Fri, 01 Jan 2016 12:53:33 GMT p3p: CP="NON CUR OTPi OUR NOR UNI" server: Microsoft-IIS/7.5 x-ms-invokeapp: 1; RequireReadOnly x-powered-by: ASP.NET x-sharepointhealthscore: 0 x-aspnet-version: 2.0.50727 sprequestguid: 4b79db39-75ae-4dfa-b7e4-c7924172e59b cache-control: private, max-age=0 expires: Thu, 17 Dec 2015 12:53:33 GMT Set-Cookie: _lasturl=/da/Privat; Path=/; Expires=Sun, 01-Jan-2017 12:53:33 GMT

---response end--- 200 OK

Stored cookie www.postdanmark.dk -1 (ANY) / [expiry 2017-01-01 13:53:33] _lasturl /da/Privat Længde: 84025 (82K) [text/html] Saving to: `privat.aspx.5'

100%[========================================================================================================================================

2016-01-01 13:53:35 (76,1 MB/s) - `privat.aspx.5' saved [84025/84025]

  • 1
  • 0
#6 Christian E. Lysel

Jeg kan sagtens reproducere det som du ser.

telnet www.postdanmark.dk 80  
Trying 147.14.11.143...  
Connected to www.postdanmark.dk.  
Escape character is '^]'.  
GET / http/1.1  
HTTP/1.1 302 Found  
Connection: close  
Pragma: no-cache  
cache-control: no-cache  
Location: /QKZcZ/  
   
Connection closed by foreign host.  
   
telnet www.postdanmark.dk 80  
Trying 147.14.11.143...  
Connected to www.postdanmark.dk.  
Escape character is '^]'.  
GET / HTTP/1.1  
HTTP/1.1 302 Found  
Connection: close  
Pragma: no-cache  
cache-control: no-cache  
Location: /  
   
Connection closed by foreign host.

Og lige nu kan min chrome browser ikke længere få fat i postdanmark, dvs TCP sessionen ikke får svar.

Tidligere kunne jeg med curl:

curl 'http://www.postdanmark.dk/da/privat/Sider/privat.aspx' -H 'Accept-Encoding: gzip, deflate, sdch' -H 'Accept-Language: da,en-US;q=0.8,en;q=0.6' -H 'Upgrade-Insecure-Requests: 1' -H 'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8' -H 'Cache-Control: max-age=0' -H 'Cookie: __utmt_UA-4795000-1=1; _gat_UA-23336661-8=1; _lasturl=/da/Privat; __utma=14845111.259030174.1451653548.1451653548.1451653548.1; __utmb=14845111.2.10.1451653548; __utmc=14845111; __utmz=14845111.1451653548.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); _ga=GA1.2.259030174.1451653548; szcib=3' -H 'Connection: keep-alive' -H 'If-Modified-Since: Fri, 01 Jan 2016 13:07:28 GMT' --compressed

Gætter på jeg "blot" er blevet black listet, af et produkt der skal beskytte dem .... nej nu kan jeg tilgå dem, og fik 12 "Location:/da/privat/Sider/privat.aspx", derefter "Location: /VhVUZ/da/privat/Sider/privat.aspx" og derefter "Location:/da/privat/Sider/privat.aspx", hvor den sidste side tog 700 ms at hente.

Bruger jeg wget får jeg efter en række location loops, 20 redirections exceeded ...

Jeg ville ikke kikke efter fejl i dit netværk :)

  • 4
  • 0
#7 Yoel Caspersen Blogger

Men det ser nærmere ud til at der er random 302 redirects fra gang til gang på samme forbindelse (fiber fra bredbaand nord (waoo) - I hvert fald med wget, har ikke checket hvad der sker med Firefox, der ses redirects jo ikke umiddelbart (men ender på en fejlside for /WXdLZ og /abc).

Benny, tak for dit svar. Virker websitet www.postdanmark.dk normalt i en browser hos dig, eller er det både wget og browseren, der hænger?

  • 0
  • 0
#8 Yoel Caspersen Blogger

Hos mig giver det via gigabits net den korrekte url.

Det, der undrer mig, er at du får mærkelige redirects istedet for den rigtige = da/privat/Sider/privat.aspx

For mig ligner det en redirect, der skal sende sid ind på den rigtige side baseret på sprog. Er det noget GeoIP for kviknet, der er forkert ?

Det ser meget ud som om, der er noget mystisk ved Post Danmarks webserver - det er nok en anti-DDoS appliance, en load balancer eller noget andet, der giver problemer.

Det kan sagtens være noget GeoIP-setting, der er forkert, men i så fald rammer det både Kviknets egne IP-adresser og de adresse, vi anvender på GlobalConnects netværk. Vores egne IP-adresser er allokeret for nylig, mens adresserne på GlobalConnects netværk har været allokeret i længere tid.

  • 2
  • 0
#9 Yoel Caspersen Blogger

Tidligere kunne jeg med curl:

Jeg har netop prøvet med din curl-kommando. Det virker fint - jeg får en masse HTML fra deres startside.

Bruger jeg wget får jeg efter en række location loops, 20 redirections exceeded ...

Jeg ville ikke kikke efter fejl i dit netværk :)

Det virker meget mærkeligt at deres website ter sig på den måde. Kan være jeg trods alt bliver nødt til at forstyrre svenskerne alligevel.

  • 0
  • 0
#10 Ivo Santos

Da jeg prøvede med en Opera 12.17 browser med alt deaktiveret fik jeg en 302 til den korrekte side: Altså minus følgende ting: javascript referer automatic redirect plugins

Efter en ny test et par minutter senere fik jeg følgende 302 redirect: /OobbZ/

ved at trykke på det pågældende link fik jeg /YUahZ/OobbZ/

og ved at trykke på det pågældende link: /SecfZ/YUahZ/OobbZ/.

For mig virker det som om der er noget helt galt hos post danmark, enten er de blevet hacket, eller også er der noget helt galt et eller andet sted. I øvrigt syntes at det virker lidt underligt at der bliver tilføjet en undermappe hver gang man trykker på det pågældende link.

  • 2
  • 0
#11 Yoel Caspersen Blogger

Ivo, har du lyst til at vise os en traceroute til www.postdanmark.dk fra din lokation?

Det virker meget mærkeligt med de random redirects, de sender ud. Hvad ser du i browseren, når du får et redirect - er det den almindelige side, bare med en mærkelig adresse, eller er det en blank side, eller..?

  • 0
  • 0
#12 Ivo Santos

D:\Documents and Settings\Dos Norden>tracert www.postdanmrk.dk

Sporer rute til postdanmrk.dk [172.99.89.212] over et maksimum af 30 hop:

1 <1 ms <1 ms <1 ms 192.168.5.1 2 <1 ms <1 ms <1 ms 87.73.64.1 3 1 ms 1 ms 1 ms ve4031.albcr2.ip.cxnet.dk [87.72.99.225] 4 1 ms 1 ms 1 ms PO6-0.155M.rc00-vej.aplus.dk [62.61.128.61] 5 1 ms 1 ms 5 ms xe-7-2-0-0.alb2nqp7.dk.ip.tdc.net [176.22.248.2 9] 6 113 ms 113 ms 113 ms ae8-0.ashbnqp1.us.ip.tdc.net [83.88.19.219] 7 113 ms 113 ms 113 ms eq-iad1.rackspace.net [206.126.236.151] 8 * * * Anmodning fik timeout. 9 114 ms 114 ms 114 ms corea-dcpe1.iad3.rackspace.net [69.20.2.161] 10 114 ms 114 ms 113 ms corea-core8.iad3.rackspace.net [69.20.2.99] 11 113 ms 113 ms 113 ms core8-aggr501a-4.iad3.rackspace.net [69.20.2.33

12 114 ms 113 ms 113 ms 172.99.89.212

Sporing fuldført.

D:\Documents and Settings\Dos Norden>

  • 1
  • 0
#15 Thomas Lønskov Luther

Jeg tror de har noget stående som forsøger at lave beskyttelse af deres side... hvis jeg med curl fra min NAS hente www.postdanmark.dk via min BBN forbindelse, så får jeg en pæn redirect til forsiden. Men hvis jeg forsøger at hente den via en VPN forbindelse til udlandet, så får jeg den underlige redirect som ligner noget short-url som dog nogle gange godt kan hentes (men giver HTTP 200 ok men en "Siden findes ikke" besked).

Så min mistanke er at der står en service foran deres IIS'er som ikke helt fatter at lave redirect pænt når den ikke kan finde ud af hvilet sprog man vil have.

  • 4
  • 0
#17 Casper Bruun

Baseret på de beskrevne mønstre - særligt de tilsyneladende mærkværdige redirects, der ender på en fejlside - er mit bud, at PostDanmark har en aktiv (automatisk) DDoS mitigering kørende.

De oplevede redirects er en del af en HTTP Authentication mekanisme, hvor ideen er at legitime browsere følger redirects, mens ondsinde klienter ikke gør. Se for eksempel sektion 3.2 her: https://www.defcon.org/images/defcon-21/dc-21-presentations/Mui-Lee/DEFC...

En sådan mitigeringsmekanisme findes blandt andet implementeret på præcis den beskrevne måde i Arbor Networks anti-DDoS produkter. Redirecten laves af Anti-DDoS systemet, som umiddelbart sender browseren videre til den rigtige side hos Post Danmark, og derefter glemmes den pågældende session. Det er derfor man efterfølgende kommer til en 404 side fra CMS systemet, hvis man prøver at åbne samme redirect URL igen.

Når angrebet på Post Danmark er overstået og mitigeringen er indstillet, så vil der formentlig være hul igennem fra Kviknet igen.

  • 5
  • 0
#18 Benny Simonsen

Benny, tak for dit svar. Virker websitet www.postdanmark.dk normalt i en browser hos dig, eller er det både wget og browseren, der hænger?

Ja i Firefox virkede det fint (og det gør det stadig). Jeg har også lige checket Chrome, virker også fint. OS: Kubuntu 14.04. Så derfor var min tanke at det kunne være browser identifikation de har med i deres redirect regler.

  • 2
  • 0
#19 Benny Simonsen

Så derfor var min tanke at det kunne være browser identifikation de har med i deres redirect regler.

Du skal bare bruge firefox (sæt useragent =firefox' user agent streng, så spiller det - stadig med redirects frem og tilbage (nogle gange 3 redirects) andre gange med 1 redirect, ender på /da/privat/Sider/privat.aspx hver gang (ud af 3 forsøg) Detaljer kan ses i loggen herunder.

benny@dovre:~$ wget -O /dev/null http://www.postdanmark.dk  
--2016-01-01 17:46:44--  http://www.postdanmark.dk/  
Resolving www.postdanmark.dk (www.postdanmark.dk)... 147.14.11.143  
Connecting to www.postdanmark.dk (www.postdanmark.dk)|147.14.11.143|:80... connected.  
HTTP request sent, awaiting response... 302 Found  
Location: /XWZiZ/ [following]  
--2016-01-01 17:46:44--  http://www.postdanmark.dk/XWZiZ/  
Connecting to www.postdanmark.dk (www.postdanmark.dk)|147.14.11.143|:80... connected.  
HTTP request sent, awaiting response... 302 Found  
Location: / [following]  
--2016-01-01 17:46:44--  http://www.postdanmark.dk/  
Connecting to www.postdanmark.dk (www.postdanmark.dk)|147.14.11.143|:80... connected.  
HTTP request sent, awaiting response... ^C  
benny@dovre:~$ wget -O /dev/null http://www.postdanmark.dk  
--2016-01-01 17:46:54--  http://www.postdanmark.dk/  
Resolving www.postdanmark.dk (www.postdanmark.dk)... 147.14.11.143  
Connecting to www.postdanmark.dk (www.postdanmark.dk)|147.14.11.143|:80... connected.  
HTTP request sent, awaiting response... ^C  
benny@dovre:~$ wget -O /dev/null http://www.postdanmark.dk  
--2016-01-01 17:46:59--  http://www.postdanmark.dk/  
Resolving www.postdanmark.dk (www.postdanmark.dk)... 147.14.11.143  
Connecting to www.postdanmark.dk (www.postdanmark.dk)|147.14.11.143|:80... connected.  
HTTP request sent, awaiting response... ^C  
benny@dovre:~$ wget -O /dev/null --user-agent="Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0" http://www.postdanmark.dk  
--2016-01-01 17:48:50--  http://www.postdanmark.dk/  
Resolving www.postdanmark.dk (www.postdanmark.dk)... 147.14.11.143  
Connecting to www.postdanmark.dk (www.postdanmark.dk)|147.14.11.143|:80... connected.  
HTTP request sent, awaiting response... 302 Found  
Location: /KUWkZ/ [following]  
--2016-01-01 17:48:50--  http://www.postdanmark.dk/KUWkZ/  
Connecting to www.postdanmark.dk (www.postdanmark.dk)|147.14.11.143|:80... connected.  
HTTP request sent, awaiting response... 302 Found  
Location: / [following]  
--2016-01-01 17:48:50--  http://www.postdanmark.dk/  
Connecting to www.postdanmark.dk (www.postdanmark.dk)|147.14.11.143|:80... connected.  
HTTP request sent, awaiting response... 302 Redirect  
Location: http://www.postdanmark.dk/da/privat/Sider/privat.aspx [following]  
--2016-01-01 17:48:50--  http://www.postdanmark.dk/da/privat/Sider/privat.aspx  
Reusing existing connection to www.postdanmark.dk:80.  
HTTP request sent, awaiting response... 200 OK  
Length: 87461 (85K) [text/html]  
Saving to: ‘/dev/null’  
100%[============================================================================================================================>] 87,461       403KB/s   in 0.2s     
   
2016-01-01 17:48:50 (403 KB/s) - ‘/dev/null’ saved [87461/87461]  
   
benny@dovre:~$ wget -O /dev/null --user-agent="Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0" http://www.postdanmark.dk  
--2016-01-01 17:51:32--  http://www.postdanmark.dk/  
Resolving www.postdanmark.dk (www.postdanmark.dk)... 147.14.11.143  
Connecting to www.postdanmark.dk (www.postdanmark.dk)|147.14.11.143|:80... connected.  
HTTP request sent, awaiting response... 302 Found  
Location: /SYPaZ/ [following]  
--2016-01-01 17:51:32--  http://www.postdanmark.dk/SYPaZ/  
Connecting to www.postdanmark.dk (www.postdanmark.dk)|147.14.11.143|:80... connected.  
HTTP request sent, awaiting response... 302 Found  
Location: / [following]  
--2016-01-01 17:51:32--  http://www.postdanmark.dk/  
Connecting to www.postdanmark.dk (www.postdanmark.dk)|147.14.11.143|:80... connected.  
HTTP request sent, awaiting response... 302 Redirect  
Location: http://www.postdanmark.dk/da/privat/Sider/privat.aspx [following]  
--2016-01-01 17:51:32--  http://www.postdanmark.dk/da/privat/Sider/privat.aspx  
Reusing existing connection to www.postdanmark.dk:80.  
HTTP request sent, awaiting response... 200 OK  
Length: 87461 (85K) [text/html]  
Saving to: ‘/dev/null’  
   
100%[============================================================================================================================>] 87,461       398KB/s   in 0.2s     
   
2016-01-01 17:51:33 (398 KB/s) - ‘/dev/null’ saved [87461/87461]  
   
benny@dovre:~$ wget -O /dev/null --user-agent="Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0" http://www.postdanmark.dk  
--2016-01-01 17:51:35--  http://www.postdanmark.dk/  
Resolving www.postdanmark.dk (www.postdanmark.dk)... 147.14.11.143  
Connecting to www.postdanmark.dk (www.postdanmark.dk)|147.14.11.143|:80... connected.  
HTTP request sent, awaiting response... 302 Redirect  
Location: http://www.postdanmark.dk/da/privat/Sider/privat.aspx [following]  
--2016-01-01 17:51:35--  http://www.postdanmark.dk/da/privat/Sider/privat.aspx  
Reusing existing connection to www.postdanmark.dk:80.  
HTTP request sent, awaiting response... 200 OK  
Length: 87461 (85K) [text/html]  
Saving to: ‘/dev/null’  
   
[bash]
  • 3
  • 0
#21 Yoel Caspersen Blogger

Tak for jeres hjælp. Ud fra alle de fine indlæg kan situationen umiddelbart opsummeres således:

  • www.postdanmark.dk er bag en anti-DDoS-løsning, muligvis fra Arbor Networks
  • Denne mekanisme gør at kun almindelige browsere har adgang (der skal være en user agent header hvis man anvender wget)
  • Hvis man anvender wget med user agent header er der adgang fra GlobalConnect's IP-adresser, som vi anvender på uplinks på router-1 og router-2
  • Kviknets RIPE-tildelte adresserum er åbenbart blokeret hos www.postdanmark.dk (det virker ikke for almindelige browsere på Kviknets netværk)

Se, nu nærmer vi os noget, der måske kan bruges.

Kviknet har IPv4 adresserummet 185.107.12.0/22 på AS-nummer AS204151. Jeg har testet fra vores bolignet-scope 185.107.12.32/29. Her er der IKKE adgang til www.postdanmark.dk.

Hvad er der galt med vores IP scope? Well, hele /22-scopet blev allokeret til Kviknet i RIPE's database tilbage i juni 2015. Scopet 185.107.12.32/29 blev oprettet i RIPE-databasen den 29. december med status ASSIGNED PA.

Der burde således ikke være noget galt med RIPE-registreringen, og hvis Post Danmark filtrerer på registreringer fra RIPE-databasen, skulle man gå ud fra, de har automatiseret importen af objekter. Måske er det her, kæden knækker - hvis de har foretaget en manuel import af danske IP-adresser i deres firewall for lang tid siden og herefter glemt alt om systemet, kan det forklare, hvorfor vi ikke har adgang.

Næste opgave: Vi skal se om vi kan få hul igennem til nogen, der ved noget om deres firewall. Det må være svenskerne, vi fandt frem til i blogindlægget.

Er der andre bud på ting, vi skal teste først?

  • 4
  • 0
#22 Claus Waldersdorff Knudsen

Virker ikke her fra Fremont, Ca. Ubuntu 14.04.03 LTS, Firefox

ubuntu@ubuntu:~$ wget -O /dev/null http://www.postdanmark.dk  
--2016-01-01 12:18:38--  http://www.postdanmark.dk/  
Resolving www.postdanmark.dk (www.postdanmark.dk)... 147.14.11.143  
Connecting to www.postdanmark.dk (www.postdanmark.dk)|147.14.11.143|:80... connected.  
HTTP request sent, awaiting response... 302 Found  
Location: /KjadZ/ [following]  
--2016-01-01 12:18:39--  http://www.postdanmark.dk/KjadZ/  
Connecting to www.postdanmark.dk (www.postdanmark.dk)|147.14.11.143|:80... connected.  
HTTP request sent, awaiting response... 302 Found  
Location: / [following]  
--2016-01-01 12:18:40--  http://www.postdanmark.dk/  
Connecting to www.postdanmark.dk (www.postdanmark.dk)|147.14.11.143|:80... ^C  
ubuntu@ubuntu:~$ wget -O /dev/null http://www.postdanmark.dk  
--2016-01-01 12:19:32--  http://www.postdanmark.dk/  
Resolving www.postdanmark.dk (www.postdanmark.dk)... 147.14.11.143  
Connecting to www.postdanmark.dk (www.postdanmark.dk)|147.14.11.143|:80... ^C  
ubuntu@ubuntu:~$
  • 2
  • 0
#23 Michael Weber

Du skal bare bruge firefox (sæt useragent =firefox' user agent streng, så spiller det - stadig med redirects frem og tilbage (nogle gange 3 redirects) andre gange med 1 redirect, ender på /da/privat/Sider/privat.aspx hver gang (ud af 3 forsøg) Detaljer kan ses i loggen herunder.

Det forekommer mig lidt mere speget end som så med user-agent-strengen. Benytter man f.eks. "Test" eller "DenneUserAgentFindesIkke" virker det via wget. Man får en text/html-side, der fylder "84025 (82K) [text/html]" og ikke - som i dit tilfælde - 87461 (85K) [text/html] . Men det er jo så nok webserveren, der svarer forskelligt på baggrund af user-agenten.

I mit tilfælde er default user-agent "Wget/1.11.4" og sætter jeg user-agent-parameteren kun til "Wget" virker det. Sætter jeg aktivt user-agent-parameteren til "Wget/1.11.4". virker det ikke - Den står bare og venter på svar fra websitet (og i en browser vil det resulterer i en timeout). Sætter jeg user-agent til en tom streng i.e. wget medsender ikke parameteren i requestet. virker det også. Man får tanken, at der ikke bare er noget filtrering på baggrund af user-agenten, men en filtrering baseret på en blacklist af user-agents og "Wget/1.11.4" er på denne blacklist.

Iøvrigt kan jeg heller ikke hverken pinge eller tracert til www.postdanmark.dk fra Telia. Webstedet virker fint i firefox.

  • 3
  • 0
#25 Claus Bruun

Det kommer også an på, hvilken GeoIP service, der bruges. Mange GeoIP tjenester er sene til at opdatere. Jeg fik selv I foråret en IP adresse, da jeg skiftede til Gigabit.dk, som tidligere havde tilhørt en ISP i Rumænien. Det var ikke morsomt at få dens reputation nulstillet... Det tog mere end et halvt år selvom RIPE og de fleste GeoIP tjenester svarede rigtigt allerede, da jeg fik adressen. De fleste spørger en paraplylookup, så der skal bare være en enkelt Spamlookup, som svarer negativt, så kan du ikke snakke med diverse mailtjenester.

Jeg har slået dine IP adresser op på nogle forskellige GeoIP tjenester, og der er flere, som ikke kender dine adresser... (Spurgte på 185.107.12.1)

  • 5
  • 0
#26 Baldur Norddahl

GeoIP er noget fanden har skabt. Vi har for nyligt taget en ny serie i brug. Men ikke mere ny end at den blev købt samtidig med den serie som Claus har en IP adresse fra. Vi har bare ikke haft kunder på den før nu. Og gud hjælpe mig om vi ikke igen får klager over sites der er spærret. Tilsyneladende har mange sites slet ikke opdateret deres database, men blot sat specifikke adresser på en whitelist.

Hvis nu de bare ville implementere IPv6...

  • 5
  • 0
#27 Baldur Norddahl

Hvad er der galt med vores IP scope? Well, hele /22-scopet blev allokeret til Kviknet i RIPE's database tilbage i juni 2015. Scopet 185.107.12.32/29 blev oprettet i RIPE-databasen den 29. december med status ASSIGNED PA.

Du mangler at lave reverse DNS. Det er vigtigere end whois. Der er stadig mange mail servere der bruger reverse DNS til at vurdere om mail er spam. Det er desuden et nyttigt debug værktøj når man får meningsfyldte navne tilbage fra traceroute :-)

RIPEs database er af meget høj kvalitet. Det gælder desværre ikke universelt for de andre regioner. Amerikanerne bruger typisk RADb http://www.radb.net/ hvor hvem som helst kan registrere, inklusiv på dine vegne (uden at du ved det). Mange amerikanere kender kun til USA, så de vægter naturligvis RADb højere end RIPE (hvis de overhovedet gider se på data fra RIPE).

Det er en af mange grunde til at folk ikke bare bruger IRR data til geo location.

  • 4
  • 0
#29 Yoel Caspersen Blogger

Du mangler at lave reverse DNS. Det er vigtigere end whois. Der er stadig mange mail servere der bruger reverse DNS til at vurdere om mail er spam. Det er desuden et nyttigt debug værktøj når man får meningsfyldte navne tilbage fra traceroute :-)

Vi er i gang med processen, men venter på GratisDNS' alt for sløve zone-reload. Jeg er stærkt fristet til at købe et .net-domæne, installere nogle DNS-servere selv og så ellers gå i gang. Kombinationen af DK-Hostmasters politik om godkendelse af DNS-servere og GratisDNS' halvsløve 90'er-system er lidt giftig, så det er fristende at undgå .dk-domæner i det omfang, det kan lade sig gøre.

Når det er sagt, så har Post Danmark ikke reverse DNS på deres egen IP-adresse, og jeg har også testet opslag fra IP-adresser uden reverse DNS, og her virker det fint. Medmindre de bruger en form for bayesian filter i deres anti-DDoS-løsning, gør det næppe nogen forskel om vi har reverse DNS på vores adresser eller ej.

Apropos datakvalitet og RIPE - så har Post Danmark også forsømt den del. 147.14.11.143 annonceres af AS41076, PostDanmark A/S. I deres RIPE-entry for ORG-POST2-RIPE står der bl.a. følgende:

remarks:        For urgent matters contact COLT Helpdesk 24x7:  
remarks:        Phone: +45 70 21 23 20  
remarks:        E-mail: helpdesk@colt-telecom.dk

Som sagt, så gjort. E-mailen bouncer, da adressen ikke findes, og deres telefon-helpdesk kan ikke hjælpe, da de ikke ved om Post Danmark er kunde hos dem.

Så du har ret, man bør ikke anvende IRR-data til den slags formål, det virker tydeligvis ikke.

  • 3
  • 0
#30 Yoel Caspersen Blogger

Hvad viser user-agent-parameteret ved et fingerprint af browseren, der får time-out ved www.postdanmark.dk?

Jeg har testet både på min egen computer og på flere andre brugeres computere. Min egen user agent er:

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/47.0.2526.73 Chrome/47.0.2526.73 Safari/537.36

Det virker fint fra TDC's net, men ikke fra vores eget.

Det er i øvrigt tæt på umuligt at komme igennem til Post Danmark i disse dage. De har dog en kontaktformular på deres website, men det ser næsten ud som om, de ikke ønsker kontakt med kunderne:

Da vi oplever lidt ustabilitet med formularen, kan du muligvis opleve en fejl. Stol på, at vi har modtaget din henvendelse.

Jeg stoler på, at de er fuldstændig ligeglade. ;-)

  • 4
  • 0
#31 Christian Nobel

Der er stadig mange mail servere der bruger reverse DNS til at vurdere om mail er spam.

Mangler der ikke et "desværre" i den sætning - for at bruge reverse DNS til at vurdere om mail er spam er direkte tåbeligt, da det eksempelvis kan udlukke helt legitime DSL brugere, med fast IP, men uden mulighed for at deres ISP kan tilbyde rDNS (eksempelvis Telenor).

Og det har givet cloud udbydere som f.eks. Amazon mange udfordringer, når der ændres i serverpoolen.

Men er der efterhånden andre end klaphattene fra Trend Micro som benytter den praksis?

  • 1
  • 0
#33 Christian Nobel

det ser næsten ud som om, de ikke ønsker kontakt med kunderne

Er det ikke den overordnede forretningsplan - vi gider slet ikke kunderne:

Nøj, konkurrencen er ved at blive hårdere, der kommer flere og flere alternative pakke og postservices, med væsentlig mere attraktive priser og bedre service end vores - vi må gøre noget:

Jamen så må vi da hellere sætte vores priser væsentlig op!

  • 2
  • 1
#35 Bent Jensen

Postdanmark har været ramt af mange DoS så de har nok sat barren meget (for) højt.

Er det ikke nemmere at skifte leverandør, der er mange andre der er villigt til at sender pakker, også billiger. Så man som privat kunde kunne få 35% Rabat ved GLS hvis man går via DBA. Post Danmark er ikke interesseret i små (privat)kunder mere, men kun i meget store afsender, samt udsendelse af reklamer. Lad dem om at forbløde langsomt.

Men du har ret, post danmark har et problem, eller retter vi som deres påtvungen kunder. Prøvt at lave en reklamtion, som også kun kan foretages online, men det virket ikke, når jeg have tastet alle oplysninger, og jeg prøvet at sende så skete der intet i Edge, Firefox og Chrome det maximale var at jeg fik en ny tom indtastning med mine oplysninger slettet.. Da posten bare have lagt en ny mobiltelefon uden for døren i regnen. De pligtopfyldende og kvalitetsbevidste postbude, har vel fundet nyt job, for ikke at gå ned på grund af stress. Post Danmark er umuligt at kontakte. Når du har modtaget en pakke fra et andet firma, mener de også at de har fået et fast kundeforhold, og misbruger den Email du har opgivet dig firma hvor du har købt en vare, til at sende dig spam, og bede dig om at anmelde dem på Trustpilot, så får de gladeligt en stjerne, da jeg ikke kan give mindre.

  • 0
  • 1
#37 Yoel Caspersen Blogger

Vi er blevet kontaktet af TDC, som mener, at problemet muligvis ligger hos dem, da de driver en DDoS-scrubber for www.postdanmark.dk.

De vil derfor kigge på sagen på mandag - så vi må væbne os med tålmodighed indtil da.

Herfra skal der lyde et tak til TDC, et godt nytår og en opfordring til at tage et kig på deres RIPE-registreringer, når de alligevel er i gang.

  • 4
  • 0
#38 Yoel Caspersen Blogger

Abuse-c som er relativt ny burde virke som kontakt specielt hvis du tror det er noget DDoS der driller

Abuse-c på hvilket objekt? Fra whois på 147.14.11.143:

% No abuse contact registered for 147.14.0.0 - 147.14.127.255

Jeg antager, det er abuse-c på ORG-POST2-RIPE, du mener. Tak for tippet, skrev faktisk til dem i går, men fik ikke noget svar - før vi blev kontaktet af TDC her i dag.

Derudover, få noget ipv6 igang og få dig en nlnog ring node, claim dine LIR credits på RIPE atlas og brug det til debug

Vi har faktisk IPv6 allerede - vores scope er 2a06:4000::/29, men www.postdanmark.dk er IPv4 only ;-)

God ide med en NLNOG ring node - den er på tegnebrættet, og det kommer, når vi har lidt luft til at få det implementeret.

  • 2
  • 0
#39 Baldur Norddahl

Mangler der ikke et "desværre" i den sætning - for at bruge reverse DNS til at vurdere om mail er spam er direkte tåbeligt, da det eksempelvis kan udlukke helt legitime DSL brugere, med fast IP, men uden mulighed for at deres ISP kan tilbyde rDNS (eksempelvis Telenor).

Og det har givet cloud udbydere som f.eks. Amazon mange udfordringer, når der ændres i serverpoolen.

Men er der efterhånden andre end klaphattene fra Trend Micro som benytter den praksis?

Selvom jeg hellere ikke helt kan se hvad reverse DNS kan bevise, så går trenden imod at det bliver vigtigere at have. På IPv4 giver mangel på reverse DNS et minus point i GMails spam filter. På IPv6 afviser GMail helt at modtage mailen hvis der ikke er reverse DNS sat op.

  • 2
  • 0
#41 Yoel Caspersen Blogger

Kan det være det som I (forkert) er ramt af?

Det virker meget sandsynligt - Claus Knudsen har længere oppe i tråden meldt, at det ikke virker fra Fremont, California.

Når nu vores alle sammens postmonopol ønsker at afskære udenlandske brugere fra deres website, har vi så et bedre forslag til, hvordan de kan sikre sig mod DDoS-angreb end at whiteliste danske (europæiske?) IP-adresser fra en arbitrær liste, der tydeligvis ikke er up-to-date?

  • 6
  • 0
#42 Henrik Kramselund Jereminsen Blogger

https://stat.ripe.net/%20147.14.11.143#tabId=anti-abuse

RIPE har været meget ivrige med at pushe abuse-c, på ORG objekterne organisation: ORG-POST2-RIPE org-name: Post Danmark A/S org-type: OTHER address: Bernstorffsgade 36 address: DK-1566 Copenhagen address: Denmark phone: +45 33 61 42 31 abuse-c: AR30172-RIPE

men det henviser til et role: Abuse-C Role nic-hdl: AR30172-RIPE abuse-mailbox: postmaster@abuse.mail.dk mnt-by: SE-COLT-MNT address: Bernstorffsgade 36 address: DK-1566 Copenhagen address: Denmark

Så deres objekter er lidt blandet Colt og TDC, men det ligner de kun har TDC som upstream http://bgp.he.net/AS41076#_graph4

Mht. nlnog RING så får du adgang til alle andres noder, og det er et super værktøj til debuggging! Det "koster" at man selv har en node, OG de kræver man har IPv6

  • 3
  • 0
#43 Yoel Caspersen Blogger

Er det ikke en smule ironisk i lige netop denne sag, at TDC's abuse-mail er postmaster@...? ;-)

NLNOG ring er et super initiativ, og vi opretter en lige så snart vi har tid til at sætte en virtuel maskine af til formålet (dvs. i løbet af et par dage).

  • 2
  • 0
#45 Jesper Rasmussen

Hej Yoel

Vi har samme problemer med vores /22 IPv4 range vi fik for godt 2 år siden og har sat global connect på sagen. Har du en evt. kontakt hos TDC som kan hjælpe os? Jeg har selv forsøgt at ringe til TDC, de siger det er postdanmark vi skal kontakte og så skal de fejlmelde det hos TDC. Vi har også forgæves forsøgt at kontakte postdanmark, men er stillet rundt 10 gange og de er meget forvirret omkring hvem der skal håndtere sagen, de bliver ved at påstå at det kun er os der har problemer og vi blot skal benytte en anden browser for at løse problemerne.

Lad mig endelig vide løsningen eller kontakt på nogen der kan hjælpe. glitch85@gmail.com

  • 2
  • 0
#46 Yoel Caspersen Blogger

I hvert fald for vores vedkommende - vores brugere kan tilgå www.postdanmark.dk igen.

TDC mener, det er for risikabelt at fortælle os, hvad problemet var, men jeg synes, denne tråd har givet os nok data til at konkludere, at det sandsynligvis skyldtes, at Post Danmarks anti-DDoS-løsning filtrerer IP-adresser ud fra en ufuldstændig whitelist.

Vi takker TDC for hjælpen og har anmodet dem om at sikre, at et lignende problem nemt kan løses i fremtiden. Det er dog i sidste ende op til Post Danmark, der jo er TDC's kunde i den her sammenhæng.

  • 3
  • 0
#49 Leif Neland

På et tidspunkt kunne én maskine ikke nå en server ude på internettet (betalingsgateway), mens alle andre maskiner på vores netværk kunne. Det viste sig at maskinen havde forkert netmaske, /24 i stedet for /27, og den u-nåbare server lå i samme /24 som vores netværk.

Of all the C-classes in the world, she walks into mine ...

  • 1
  • 0
#51 Yoel Caspersen Blogger

Man bliver lidt træt... min forbindelse fra hiper får bare timeout på www.postdanmark.dk .. og skifter jeg til min forbindelse fra 3 så får jeg bare too many redirects. Jeg troede rent faktisk at postdanmark tog sine kunder seriøst - har de et hemmeligt website man kan benytte som rent faktisk virker eller hvad ?

Du kan bede Hiper om at tage fat i undertegnede, så er det muligt at jeg kan formidle kontakten til dem, der kan løse problemet.

  • 0
  • 0
#52 Nicolai Petri

Jeg skal ikke afvise at der kan være et peering problem for hiper kunder, men alt andet virker umiddelbart, og baseret på postdanmark.dk's imponerende oppe- (eller måske nede-)tid alt efter hvilken ip man nu er uheldig at komme fra, så er jeg nok mere på at man fjerne den sindsyge anti-dos device. Næste gang postdanmark har brug for sådan en, så vil jeg anbefale at lave en blackhole route istedet - effekten er nogenlunde den samme..

Bemærk jeg heller ikke kan komme på fra 3's netværk - skal de også kontakte dig ? Det der med at whiteliste udbydere der må tilgå en hjemmeside ... det er lidt op af bakke!

  • 2
  • 0
#53 Yoel Caspersen Blogger

Jeg skal ikke afvise at der kan være et peering problem for hiper kunder, men alt andet virker umiddelbart, og baseret på postdanmark.dk's imponerende oppe- (eller måske nede-)tid alt efter hvilken ip man nu er uheldig at komme fra, så er jeg nok mere på at man fjerne den sindsyge anti-dos device.

Hiper har nøjagtigt samme problem som vi havde, indtil vi fik det løst, nemlig nyligt allokerede IP-adresser, der ikke er registreret i TDC's whitelist over europæiske IP-adresser.

Jeg ved ikke hvad 3's problem er, men hvis de kontakter os skal jeg gerne henvise dem til rette vedkommende ;-)

Der er heldigvis en simpel løsning på det hele, og den hedder GLS, DHL, UPS, eller en af Post Danmarks andre konkurrenter. Når man ikke gider have besøg af kunderne på sit website, har man heller ikke fortjent at beholde dem som kunder.

  • 1
  • 0
Log ind eller Opret konto for at kommentere
Job fra Jobfinder
Tip redaktionen