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

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?

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]

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]

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: [<head><title>Document Moved</title></head>
<body><h1>Object Moved</h1>This document may be found <a HREF="http://www.postdanmark.dk/da/privat/Sider/privat.aspx">here</a></body&gt;] 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) / <permanent> <insecure> [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]

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 :)

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.

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>

URL: www.postdanmark.dk >Resultat:

<!DOCTYPE HTML>
<html dir="ltr">
<head>
<title>Omdirigering</title>
<link rel="stylesheet" href="file://localhost/D:/Programmer/Opera/styles/message.css" media="screen,projection,tv,handheld,print,speech">
<meta name="viewport" content="width=device-width">
</head>
<body>
<h1>Omdirigering</h1>
<p>URL'en blev omdirigeret til <a href="/UPVUZ/">/UPVUZ/</a>. Klik på linket for at gå dertil.</p>
<p>Du kan aktivere automatisk omdirigering under Indstillinger.</p>
<address>Genereret af Opera.</address>
</body></html>

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

Hov, pas lige på,- du har stavet forkert. Det der er er meget underlig side man ikke har lyst til at klikke videre på :-)

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.

Men hvis jeg forsøger at hente den via en VPN

Jeg kan så ikke få den til at fejle. Har prøvet flere identiteter via tor-browser.
Underlig sag.
Sidder på en Stofa forbindelse i København.

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.

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.

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]

Beklager folkens, det lader vist til at var for hurtig ved tasterne.

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:~$ 

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.

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

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

http://fingerprint.pet-portal.eu/

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)

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...

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.

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?

Yoel,

Jeg er stadig i et givende julehumør, så du har en flødekage tilgode hos mig for ordspillet i blogtitlen.. ;-)

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!

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.

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

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

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.

“postdanmark.dk kan ikke tilgås udenfor EU, der blev spærret for i forbind. med et hachkerangreb”

https://twitter.com/postdanmark/status/664083594281918464

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

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

... da det heller ikke virker her fra Schweiz. Det er ret irriterende, da vi prøver at finde deres nye priser. Nu da jeg har fundet dem, så synes jeg egentligt bare, at de skal blive ved med at spærre for deres hjemmeside :)

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

Jeg kom til at tænke på denne tråd da jeg så denne video

https://youtu.be/7xDGgQizZGw

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 ...

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 ?

<bittermand>
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!

</bittermand>

Tjae, Gribskov avis er fyldt med læserbreve hver uge, som i underholdende vendinger fortæller om at postomdelingen i Gilleleje fungerer efter stort set samme princip.

Men er Pest Danmark i det hele taget ikke under afvikling - de har bare ikke meldt det officielt ud endnu?