De sidste 14 dage har de to haft mindst een defekt mailserver i deres DNS rotation, hvilket effektivt fører til at det er umuligt at udtale sig om hvorvidt en modtager på domænerne kan/vil modtage mails man sender til dem.

Kombineret med det faktum, at det kan konstateres at have været tilfældet temmelig mange gange over de seneste par år, samt at det (selvsagt) er 100% umuligt at komme igennem med en fejlmelding til de to giganter, kan jeg vanskeligt konkludere andet end at det er en usædvanlig dårlig idé at benytte deres services, med mindre man er indstillet på at acceptere at mails periodisk og uden meldinger eller advarsler vil gå tabt.

Dog vil gælde, at afsenderen af mails der ikke afleveres må forventes at modtage en tilbagemelding om, at den/de pågældende mails ikke kunne afleveres – men hvis ikke afsender derefter finder en anden måde at kontakte modtager på, og orienterer om problemet, vil man aldrig blive opmærksom på at der er noget galt.

Supplerende ovenstående, for at give det lidt mere tekniske indblik, er mailserver-administrationen for systemer så store som de to, naturligvis ikke en enkel og simpel sag. Jævnfør det her indsatte øjebliksbillede af et opslag med nslookup, fordeler Hotmail sine mailservere over 5 indgange, hver med cirka 10 IP numre. Hvorvidt det i praksis bliver til 50 servere er vanskeligt at udtale sig om udefra – men det er indlysende at kompleksiteten af en sådan opsætning ikke er ubetydelig.

Når man har truffet valget at dirigere sine besøgende til en SSL krypteret side, vil det oftest være i høj grad uhensigtsmæssigt, hvis browseren skulle finde på at komme med advarsler om, at siden indeholde usikre elementer.

Eksempel på IE6 advarselsdialogboks

De logiske
Som ofte er tilfældet viser der sig i praksis at være forskel på hvordan markedets browsere håndterer sikkerhed – herunder er de selvskrevne kandidater til en checkliste for at undgå problemer er inkluderinger af eksternt indhold, som skal angives enten med en relativ eller HTTPS URI.

• <img src="..." alt="Ellipsis" />
• <script type="text/javascript" src="..."></script>
• <link rel="..." href="..."></script>

Værd at bide mærke i, i forhold til ovenstående er at følge op på hvad eventuelt 3. parts værktøjer som eksempelvis Google Analytics, Omniture og lignende indsætter af referencer – de fleste af disse har HTTPS-baserede ækvivalenter.

De bemærkelsesværdige
Hvad der formentlig er knap så indlysende er, at i Internet Explorer også <object codebase="..."> og <embed pluginspage="..."> skal angives relativt eller eksplicit med HTTPS. På trods af at browseren ikke gennemfører en request på URI’en, bliver der lavet en kontrol af overenstemmelse med dokumentets protokol.

Intuitivt eller ej, gør det sig også gældende for Internet Explorer, at eventuelle inkluderede URI’er der resulterer i en HTTP fejlkode, vil blive behandlet som usikre, idet det er browserens klassificering af sine egne fejlsider.

De lumske
Til gengæld er det formentlig kun blandt Microsofts egne udviklere indlysende, at brugen af iframe’s med enten tom eller ingen src-angivelse betragtes som en reference til HTTP og altså vil give en advarsel på en HTTPS side. Har man brug for den tomme iframe, kan eventuelt angives en reference til et tomt dokument, eller værdien “javascript:false“

Sidst, men bestemt ikke mindst: Hvis der benyttes javascript der kalder removeChild() på et element der har et baggrundsbillede kan fejlen også optræde. Omgåelsen er nem: Sæt i stedet outerHTML='' (og nej, der er ingen logisk og rimelig grund til at tingene skal virke sådan).

De ligegyldige
Blandt de ting der kan ignoreres uden konsekvenser, er protokolangivelser i:

• DOCTYPES
• XHTML namespaces
• Links

Forhåbentlig ovenstående kan redde uskyldige forbipasserende for timevis af fejlsøgning – kommer man alligevel dertil hvor der skal graves, er netværksovervågning et godt angrebspunkt – herfra er høstet gode erfaringer med både Ethereal og Fiddler.

Bemærk, at CONNECT requests altid vil ske via HTTP, men alt andet skal ske på HTTPS.

Et utal af hjemmesider kommer til på Internettet hver eneste dag. De fleste er små private blogs og mini-sider som kun har en stærkt begrænset bruger/læser skare. Men der findes også den del af nettet som bliver godt besøgt. Uagtet om man driver en hjemmeside med få besøgende pr. år eller flere tusinde pr. time er det vigtigt at have for øje at man dermed også bør tænke over hvad det er disse besøgende får serveret.

Har man ikke beskyttet sin server, hjemmeside, blog eller content-management system grundigt nok kan det gå galt.

Hvor galt det kan det da gå?

Advarsel: Links til eksterne sider fra dette punkt i artiklen kan lede til virusinficerede sider.

Et godt eksempel på dette er komikeren Omar Marzouk, der fornyligt har stiftet et parti kaldet Ny Filionggonggong som det kan læses på Politiken’s blog idag. Hjemmesiden er drevet af det vidt udbredte blogsystem Wordpress. Desværre er der ikke tale om en opdateret udgave af Wordpress, i skrivende stund er der anvendt version 2.3.2, hvilket har en række ærgelige konsekvenser. Dels er Omar Marzouk’s hjemmeside en fin og sikkert eftertragtet angrebsvektor for personer med urent mel i posen, da der er tale om en højt eksponeret hjemmeside der utvivlsomt har potentiale for at trække nogle tusinde besøg pr. dag. Problemet er at Wordpress version 2.3.2 er sårbar overfor en række kendte angreb (hvilket v2.3.3 retter op på), der gør en kyndig angriber istand til helt at overtage hjemmesiden. Vedkommende vil kunne rette/slette indlæg efter eget forgodtbefindende.

Udover at være drevet af en ældre version af Wordpress er der tilsyneladende også mangel på moderering af kommentarer på hjemmesiden. Dette har også en ubehagelig sideeffekt. I skrivende stund linkes der fra forsiden til ikke mindre end 5 forskellige virus inficerede eksterne hjemmesider fra boksen “Nyeste kommentarer”.

Min virus scanner rapporterede dette da jeg fulgte første kommentarlink:

Lektien ved dette

Der følger et “ansvar” med at drive en hjemmeside der tiltrækker mange besøgende kan man godt påstå. Ikke ment på den vis at der ville kunne gennemføres et juridisk gyldigt søgsmål mod det nye “partis” hjemmeside, men nærmere et professionelt stolthedsansvar. Man bør gøre sit ypperste for sikre ens server og ens besøgende ikke mindst.

Det er nemt at undgå

Det er relativt nemt i videst mulige udstrækning at sikre sig mod uforvarende at lede ens besøgende ind på inficerede sider og at have sikkerhedshuller i ens server/software, ved at følge disse simple grundregler:

• Hold server og software opdateret
• Anvend en virusscanner
• Moderer alle kommentarer og/eller beskyt gerne mod anonyme kommentarer
• Brug gerne anti-spam og captcha plugins på blog og CMS systemer
• Gennemgå ofte hjemmesiden i sikkerhedsøjemed
• Følg med på supportsiderne for de software-produkter der anvendes og tilmeld alle eventuelle sikkerhedsmailinglister