Min statusrapport for januar er lidt kedelig. Der er ikke sket noget væsentligt i MozillaDanmark, som jeg kender til. Vi er i øjeblikket lidt bagud med oversættelsen af Firefox og Firefox til Android.
MozillaDanmark, december 2011
Der er ikke sket så meget her i december.
- Vores udbyder Suftown havde et nedbrud 8. december, som havde nogle eftervirkninger nogle dage efter.
- Jeg har opdateret MediaWiki til seneste version. Jeg har stadig ikke fået kikket på at reetablere brugeroprettelse på wikien.
MozillaDanmark, november 2011
I denne måned var jeg til Mozilla Camp Europe 2011 i Berlin. Jeg har skrevet en del om det her på siden (1 2 3 4 5 6). Ud over det er der ikke sket de store ting på mozilladanmark.dk i november, så vidt jeg ved. Der er lige udkommet en ny version af MediaWiki, som jeg vil se på at få os opgraderet til.
Ingen brugerregistrering på wiki
På grund af problemer med spam, har jeg fjernet muligheden for at oprette nye brugere på vores wiki. Jeg håber på at gendanne denne mulighed hurtigst muligt, når jeg har fundet en måde, hvorpå vi kan bekæmpe denne spam. I mellemtiden kan man henvende sig i forummet og få et brugernavn, hvis man vil bidrage til vores wiki. Oprettelse af brugere i forummet er ikke påvirket.
Hvordan vi oversætter: Deadlines og versioner
Jeg vil gerne fortælle lidt om hvordan vi arbejder med oversættelse i MozillaDanmark. Vi oversætter både Mozillaprogrammer og -hjemmesider. Her vil jeg forsøge at beskrive hvordan oversættelse af programmerne (Firefox til computer og mobil, Thunderbird og Lightning) foregår med hensyn til versioner og udgivelsescyklus.
Firefox (og Thunderbird) udgives i en ny version hver sjette uge efter en fast kalender. Der findes altid fire aktive “kanaler” for Firefox: Nightly, Aurora, Beta og Release.
Enhver version af Firefox starter som Nightly (også kaldet central), som er kanalen hvor al udviklingen sker. Seks uger efter at en version er startet på Nightly flytter den til Aurora, hvor der ikke længere udvikles nyt på versionen, men kun rettes kritiske fejl. Efter yderligere seks uger flyttes versionen til Beta, hvor test og kritisk fejlretning fortsætter. Efter endnu seks uger flyttes versionen så til Release, hvor den så er tilgængelig for alle almindelige Firefox-brugere. Seks uger senere bliver versionen erstattet af den efterfølgende version af Firefox.
De fire kanaler er altid forskudt med en version i forhold til hinanden, så når Firefox 7 er i Release, er Firefox 8 i Beta, Firefox 9 er i Aurora, og Firefox 10 er i Nightly.
Hvordan relaterer disse fire kanaler til oversættelsen?
Aurora er stedet hvor oversættelsen normalt foregår. Præcis 12 uger før endelig udgivelse bliver de engelske tekststrenge tilgængelige til oversættelse i Aurora. Præcis 6 uger før endelig udgivelse skal den danske oversættelse af Aurora være færdig og uploadet til Mozilla. Den kvikke læser vil bemærke at tiden mellem at de engelske tekster bliver tilgængelige og de danske tekster skal være færdige svarer til tidsrummet mellem hver version af Firefox, nemlig seks uger. Det betyder at samme klokkeslæt som Firefox 9 skal være oversat på Aurora, bliver de engelske tekster til Firefox 10 tilgængelig for oversættelse på Aurora. Der er altså altid en version af Firefox som man kan arbejde med oversættelsen af.
Beta er stedet hvor oversættelsen kan rettes, hvis vi opdager fejl, eller hvis vi er kommet bagud. Præcis seks uger før endelig udgivelse overfører Mozilla den foreløbige danske oversættelse fra Aurora til Beta. Her kan de sidste rettelser foretages, og deadline for rettelserne er cirka en til to uger før endelig udgivelse. I modsætning til alle andre datoer er denne deadline en cirka-dato, da Mozillas kvalitetssikringshold skal bruge noget tid på at teste versionen før den slippes løs til de over 400 millioner brugere. Ulemperne ved at vente til Beta med at oversætte er blandt andet,
- at oversættelsen nu skal gemmes to steder, både til den nuværende version i Beta, og til den efterfølgende version i Aurora,
- at den efterfølgende version allerede er klar til oversættelse i Aurora, så man nu skal oversætte to versioner på samme tid, og
- at deadline ikke er en fast dato.
Vi forsøger derfor så vidt muligt at undgå at lave oversættelse på Beta.
Release involverer intet oversættelsesarbejde. Når først en version af Firefox er endeligt udgivet, kommer der ingen regelmæssige sikkerhedsopdateringer. I stedet kommer der en helt ny version seks uger senere. Hvis der skulle komme nogle uventede sikkerhedsopdateringer som fx Firefox 7.0.1, vil de kun indeholde kritiske rettelser, og det vil derfor ikke være muligt for os at opdatere oversættelsen i sådan en version.
Nightly er stedet hvor udviklerne arbejder, og kommer før Aurora. I det danske oversættelseshold har vi valgt ikke at oversætte Nightly, fordi der hele tiden kan komme nye tekster, der skal oversættes, og eksisterende tekster kan ændres eller fjernes helt. For at undgå spildt arbejde venter vi med oversættelsen til Aurora, hvor udviklerne er færdige med at foretage deres ændringer til teksterne, og vi har en stabil engelsk version vi kan oversætte. Nogle få oversættelsesgrupper tilhørende de store sprog oversætter Nightly, for at give feedback til udviklerne, så de kan finde engelske tekster der er svære eller umulige at oversætte.
Denne oversættelsesprocedure gælder både for Firefox og for Thunderbird. Det er dog usikkert om Lightning følger denne procedurer, selvom de har meldt ud at de vil følge samme procedure som Thunderbird.
MozillaDanmark, september 2011
Her er min statusrapport for MozillaDanmark for september 2011:
- Jørgen Rasmussen har fået SVN-adgang, så han nu selv kan committe sine oversættelser af mozilla.org og andre Mozilla-websider.
- Kim Ludvigsen har fået HG-adgang, så han nu selv kan pushe sine oversættelser af Thunderbird og Lightning. (Efter 5½ år!)
- Jan Krag vil gerne oversætte SeaMonkey, men vil gerne have flere til at hjælpe til.
- Certifikatet for ssl.mozilladanmark.dk udløb, og jeg fik det først udskiftet to dage for sent. Normalt får jeg en mail fra StartCom to uger før certifikatet udløber, men den mail må være gået tabt et sted, måske i et spam-filter. Jeg oprettede oprindeligt siden som en midlertidig løsning på en fejl i Firefox, som var relateret til forgængeren for NemID. Fejlen blev løst for lang tid siden, og ssl.mozilladanmark.dk bruges derfor stort set ikke længere.
- Jeg har opdateret første side i tilmeldingsproceduren på vores forum. Før fik man en standard juridisk besked fra phpBB, som var fuldstændig ubrugelig. Nu fortæller siden
- hvad man får ud af at registrere sig som bruger
- at man ikke behøver at registrere sig for at stille spørgsmål
Langt vigtigere er dog hvad jeg ikke har fået gennemført: Mozilla lovede for over en måned siden at betale for næste års hosting af mozilladanmark.dk, men jeg har ikke set noget til den betaling endnu. Deadline for betaling til Surftown er 18. oktober, så jeg skal snart til at se mig om efter en plan B. Opdatering: Vores webhotel er betalt 10. oktober.
MozillaDanmark, august 2011
MozillaDanmark.dk har gennem tiden været hostet mange forskellige steder, sponsoreret af forskellige virksomheder og personer. Det har ofte været problematisk, da vi ikke selv har haft fuld kontrol over vores hosting-konfiguration. Da vi fx skulle tilføje en wiki til vores side i 2006, måtte vi flytte til nyt webhotel og sponsor, da vi ikke kunne tilføje den i konfigurationen, og vi kunne ikke få fat i vores sponsor for at få dem til at foretage ændringerne. Siden hen har MozillaDanmark.dk været hostet på forskellige webhoteller, og en overgang lå den på min private server, hvilket betød at ingen andre end jeg havde adgang til opsætningen.
For to år siden lykkedes det at få Mozilla til at sponsorere vores hosting, så vi nu har et webhotel sponsoreret af Mozilla, men hvor vi selv har adgang til at ændre opsætningen. I slutningen af juli fik jeg en mail om at det endnu en gang var tid til at forny vores abonnement på vores webhotel. Der er sket en del i Mozilla siden sidste år, og det er nu blevet markant mere bureaukratisk at få Mozilla til at sponsorere os. De to foregående år sendte jeg en mail til Seth fra Mozilla, og fik pengene. Det er nu blevet erstattet af et program kaldet Mozilla Reps, a.k.a. ReMo. I starten af august tilmeldte jeg mig ReMo, med alle de formularer og erklæringer det medfører. Vi har endnu ikke fået bevilget hosting af MozillaDanmark.dk for det kommende år, men tingene skrider fremad, og jeg tror på vi når det, da der er over en måned til deadline for betalingen.
En del af betingelserne for at modtage sponsorat via ReMo er at vi hver måned skal rapportere hvad pengene bruges til. Så da jeg alligevel skal til at tænke over hvad der er sket på MozillaDanmark.dk hver måned, vil jeg også gerne dele dette med jer, for at skabe større indblik i hvad der sker:
Sket i MozillaDanmark i august 2011:
- Vi har opdateret vores wiki-sider til at være en bedre indgang til brugere der søger support, fx Firefox support forsiden. Før i tiden var der kun en liste over supportartikler med et link til forummet. Der var ingen åbenlys søgemulighed, og fokus var på artiklerne, som desværre ikke er særligt imponerende. Nu har vi mere plads reserveret til forummet, med en liste over de seneste spørgsmål, og vi har en samlet søgefunktion, der søger i både wiki og forum, afgrænset til det enkelte program.
- Jeg har som sagt ansøgt om at få sponsoreret hosting af MozillaDanmark.dk i et år mere, men har endnu ikke fået svar.
Planer for MozillaDanmark i september 2011:
- Jeg håber vi får sponsoreret vores hosting af Mozilla, og vil presse på for at der sker noget.
Oversvømmelse og nedbrud
Lørdag aften kl 22 gik mozilladanmark.dk ned på grund af oversvømmelse hos vores hosting udbyder Surftown i forbindelse med det voldsomme skybrud over København. Det har desværre taget Surftown flere dage at genoprette deres service, så vi fik først vores hjemmeside tilbage her tirsdag aften.
Vi håber at jer der har haft brug for hjælp til Firefox, Thunderbird og de andre Mozillaprogrammer har fundet hjælp andre steder i mellemtiden.
Ubudne gæster
Vi har desværre haft ubudne gæster her hos MozillaDanmark. Nogen har haft adgang til dele af vores hjemmeside, som de ikke skulle have haft adgang til.
Gerningsmændenes formål ser ud til at have været at bruge vores PageRank hos søgemaskinerne til at sprede spam-links. Vi tror umiddelbart ikke de er gået efter data om vores brugere eller på anden vis har forsøgt at skade de besøgende, men vi kan ikke være 100% sikre. Hvis du er registreret som bruger i vores forum og du bruger samme adgangskode hos os som andre steder, kan det derfor være en god ide at ændre din adgangskode.
Hvad er der sket?
Angriberne har på en eller anden måde fået adgang til at plante uønsket PHP-kode på vores server. Koden lå spredt rundt omkring i flere mapper i både nye og eksisterende filer. Efter et nærmere kig på koden ser det ud til at formålet har været to ting:
- Fylde vores side med spam-links hver gang en søgemaskine kom forbi. Koden forsøger at skjule disse links fra normale brugere, så kun søgemaskiner kan se dem, men det har ikke altid virket, og almindelige brugere har derfor også en gang imellem kunnet se denne spam.
- Sikre fremtidig adgang ved at placere komponenter fra kendte CMS-systemer, som gør angriberne i stand til at komme tilbage og ændre deres spam-links eller lægge nyt kode ind.
Hvor længe har de haft adgang?
De ældste filer vi har fjernet var dateret 28. januar, og vi fandt og fjernede de sidste filer 4. februar.
Hvordan har de fået adgang?
Vi ved det ikke, men der er tre teoretiske muligheder:
- De har opdaget adgangskoden til vores FTP-konto hos vores udbyder Surftown.
- De har fundet et sikkerhedshul i noget af den PHP-software vi kører (phpBB, WordPress, MediaWiki og diverse småting)
- De har fundet et sikkerhedshul i Surftowns systemer og har angrebet os via andre brugere.
Vi anser (3) for højest usandsynlig, og vi anser (2) som den mest sandsynlige.
Hvordan har vi fjernet koden?
Det meste af vores kode er standardsoftware (phpBB, WordPress og MediaWiki). Vi har derfor nemt kunne hente en ren udgave af softwaren fra producenternes hjemmesider, og har sammenlignet dem med hvad vi havde liggende (diff er et godt værktøj til dette formål). Vi har minutiøst gennemgået enhver forskel og verificeret om det er en vi selv har lavet eller om det var en del af angribernes kode.
Hvordan undgår vi at det sker igen?
FTP
Vi har ændret vores adgangskode til vores FTP-konto, og der er nu færre medlemmer, som kender koden. Samtidigt er det nu kun aktive medlemmer, der kender koden (Kim Ludvigsen , Søren Munk Skrøder og Jesper Kristensen).
PHP
Vi har også gennemgået vores PHP-software for sikkerhedsproblemer. Vi fandt ingen problemer i vores egen kode. Vores installerede udgaver af phpBB og WordPress var også opdaterede med sikkerhedsopdateringer. Vi fandt derimod ud af at vi brugte en gammel udgave af MediaWiki med kendte sikkerhedskuller. Den har vi nu opdateret til nyeste udgave. Vi gætter på at angriberne er kommet ind denne vej.
MediaWiki
Jeg var på et tidspunkt tilmeldt MediaWikis mailingliste for sikkerhedsopdateringer, men jeg må af en eller anden grund være røget af den, for jeg har ikke fået mail om sikkerhedsopdateringer i lang tid. Jeg er nu tilmeldt mailinglisten igen, så vi kan følge med sikkerhedsopdateringerne til MediaWiki. Her vil jeg gerne tillade mig at kritisere folkene bag MediaWiki for kun at stille en oldnordisk og uigennemskuelig mailingliste til rådighed. Folkene bag phpBB gør det fx meget bedre ved at stille et smart web feed til rådighed, og med web feeds er der ingen tvivl om hvorvidt beskederne når frem eller ej.
Hvordan styrker vi sikkerheden?
Jeg går kraftigt ind for sikkerhed i flere lag. Som jeg tidligere har skrevet her på bloggen, har vi fx indført Content Security Policy her på siden (CSP har dog intet med dette angreb at gøre, da den er designet til at beskytte mod helt andre trusler).
Databasen
Som ekstra beskyttelse af databasen bruger hver PHP-applikation hver deres database med hver deres adgangskode. phpBB kan fx ikke se eller rette i databasen tilhørende WordPress og omvendt. Samtidigt kører databasebrugeren med minimale rettigheder. Sådan har vores opsætning været længe før dette angreb. I den forbindelse vil jeg gerne give ros til Surftown for at gøre det muligt for os som kunder at oprette flere forskellige databaser med forskellige brugere og for at give os mulighed for at styre brugerrettighederne i mange detaljer via deres kontrolpanel.
Webserveren/PHP
På PHP-området er det straks sværere at indføre ekstra beskyttelseslag. Surftown kører med PHP safe_mode, hvilket gør det svært at lave et multibruger-setup med begrænsede rettigheder til hver bruger. Men de kører kun med safe_mode_gid, så det kunne teoretisk være muligt. Men Surftown giver ikke mulighed for at oprette flere brugere og ændre filejerskaberne (chown).
Som om det ikke var nok at vi kun har én bruger, som er ejer af alle vores filer, kører webserveren også som denne bruger, og vi har derved så vidt jeg kan se ingen mulighed for at forhindre webserveren i at have læse- og skriveadgang til alle vores filer. Hvis vi havde haft det, kunne vi begrænse angribernes adgang til mapper med caches og billeduploads, og vi kunne have forhindret al PHP-kørsel i disse mapper, således at angriberne ikke ville have haft mulighed for at udnytte sikkerhedshullet i MediaWiki.
En anden begrænsning er at Surftown kun kører PHP 5.2. I modsætning til version 5.3, er det i denne version ikke muligt at lave yderligere restriktioner på open_basedir i fx .htaccess-filer, hvilket kunne have forhindret angriberne i at sprede sig fra wikien til forummet, bloggen og vores statiske sider. Jeg håber Surftown opgraderer meget snart.
Netværkskryptering/FTP
Vi har adgang til vores filer via FTP. FTP-protokollen er som bekendt usikker, og man bør bruge fx SFTP eller SCP i stedet, men Surftown tilbyder ingen af disse muligheder, så det kan vi ikke.
Netværkskryptering/HTTP
Jeg har også for noget tid siden forsøgt at få SSL-kryptering på de dele af vores site, som har login (eller i det mindste til admin-områderne). Men SSL kræver enten en selvstændig IP eller SNI. Surftown tilbyder ikke selvstændig IP til det abonnement vi har, og en marginalt øget sikkerhed er ikke nok til at jeg vil betale det dobbelte for vores hosting på et dyrere abonnement. Jeg har desuden spurgt Surftown om de i stedet understøtter SNI, men de svarede at det gør de ikke, og de har ingen planer om at gøre det.
Til sidst
Det var så min gennemgang af sikkerheden her hos os. Jeg er overbevist om at vi har fået bugt med indbrudstyvene, og at mozilladanmark.dk nu er mere sikker end nogensinde. Men ser du noget mystisk er du som altid mere end velkommen til at give os besked. Jeg håber at vores erfaringer kan hjælpe andre med at blive lidt klogere på sikkerhed på webservere.
Opdateret: Indlægget er rettet efter Surftown Support har bekræftet at de hverken tilbyder SFTP/SCP eller multibrugersikkerhed for webserver og PHP.
Ramt af tekniske poblemer 23-24. oktober
MozillaDanmarks sider har været noget langsomme det sidste døgns tid. Det skyldes problemer med en databaseserver hos vores hosting-udbyder Surftown. Problemerne startede et sted mellem fredag aften og lørdag morgen, og har ført til at siderne oftest har været over 30 sekunder om at blive indlæst, hvis det da overhovedet lykkedes at indlæse siderne. Vores forum, blog og wiki var ramt, mens vores hovedside virkede som normalt, da den ikke benytter databasen.
Surftown har meddelt at databasen er blevet fikset klokken 16:25 i dag søndag, så den skulle forhåbentligt virke korrekt igen.
Der ser ud til at være nogle ting der ikke helt stemmer på vores forum. PhpBB-softwaren, som vi bruger, er åbenbart ikke særlig robust overfor en ustabil database. Det vil jeg se om jeg kan få fikset snarest muligt.
Vi må leve med at tingene nogen gange går galt. Det kan jo ske, specielt når man som vi bruger shared hosting. Men jeg synes godt Surftown kunne have været lidt hurtigere til at fikse problemet. Det tog over et døgn. Ydermere viste deres serverstatus-side ingen problemer, og oppetiden for databaseserveren står lige nu som om den har været 100% over de sidste seks døgn, hvilket åbenlyst er løgn. Men man kan nok ikke forvente mere af hosting til 50 kroner pr. måned, og vi er da også generelt tilfredse med vores hosting hos Surftown.
Opdateret senere: Tingene skulle nu gerne være fikset på forummet. Årsagen var at phpBB åbenbart overhovedet ikke bruger databasetransaktioner, og så kan det jo nemt gå galt.