Door Sander den Heijer

Product Lead

Tech-update over beveiliging en releasenotes - Development-iteratie #194

10-11-2020 • 13:37

36

Ook in de afgelopen sprint hebben we weer veel gewerkt aan zaken achter de schermen. Daarom geven we in deze .plan weer een overzicht van enkele dingen die wel zichtbaar zijn aan de voorkant en een update vanuit tech over beveiliging.

Tech-update over beveiliging

Beheer en beveiligingDe afgelopen sprint stond voor het techteam in het teken van beveiliging. Beveiliging leeft bij het developmentteam, maar dit is niet altijd zo gestructureerd in documentatie vastgelegd. We zijn daarom begonnen met het inventariseren en organiseren van alles wat we doen met betrekking tot beveiliging. Het doel is om daarmee een beveiligingsplan te maken.

Zo’n plan schrijven kost nogal wat werk en omdat we iteratief willen opleveren, hebben we besloten om te beginnen met een beveiligingsmanifest. Dit document is simpelweg een lijst van standpunten die we uitdragen. Bijvoorbeeld: “Ik geef mensen niet meer rechten dan nodig” of: “Ik maak fouten, dus maak ik gebruik van beveiligingschecks.”

Deze lijst vormt de basis voor het beveiligingsplan en helpt ons verder te bepalen wat we willen verbeteren. Een aantal concrete dingen waar we mee bezig zijn, naast het beveiligingsplan, zijn het onderzoeken van automatische security scan tools en betere bescherming tegen ddos-aanvallen. In de komende paar sprints zullen we dit verder uitwerken.

Tweakers down

Helaas was de site gisterochtend even down. Oorzaak was onderhoud aan de stroomfeeds in onze racks. Hoewel we daarop waren voorbereid, waren er twee servers die met een enkele voeding op dezelfde feed waren aangesloten, tussendoor geglipt. Dat waren twee van de drie 'monitor'-servers voor het ceph-cluster, waardoor dat hele cluster down ging. Daarop liepen de webservers langzaam vast en stopte Apache met reageren. De loadbalancers konden geen requests meer doorsturen naar die servers en de site ging plat.

Releasenotes

  • De weergave van de dealslisting in de .deals-artikelen is verbeterd.
  • Inlogissues voor Tweakblogs zijn opgelost.
  • In de tracker worden onder het label .plans geen advertentieartikelen (.adv's) meer getoond.
  • De code van het betalingssysteem achter de aboshop is verbeterd.

Reacties (36)

36
36
30
2
0
4
Wijzig sortering
Bij het lezen van het woord 'beveiliging' ging even de hoop leven dat tweakers nu eindelijk toch eens 2FA zou introduceren. Op zich fijn dat er enige aandacht voor het onderwerp is, maar het ontbreken van 2FA is inmiddels wel een serieus gebrek aan het worden en wat mij betreft zou nu toch wel eens tijd zijn om het te introduceren.
2FA valt zeker binnen het beveiligingsplan, dus wees gerust, we kijken er naar. Ik kan niet aangeven hoe snel we dit kunnen oppakken, en of we dit überhaupt kunnen doen in onze beperkte tijd die we hebben, maar ik ben het met je eens dat het er liever gisteren al in zat.
Fijn om te horen dat het toch op de radar staat
En anders het 2fa-foefje overlaten aan een derde partij. Het zijn nota bene de vrienden van Hardware Info die daar een uitstekende bundle voor hebben: HWIOAuthBundle
De bundle van HWI is interessant, maar gaat om autorisatie, niet zozeer de second-factor. Maar los daarvan, er zijn zeker mogelijkheden om het wiel niet helemaal opnieuw te hoeven uitvinden hoe je bijvoorbeeld TOTP 2FA implementeert.

Het "probleem" zit 'm juist in dat toefje, want de integratie is nu net het ding wat het complexer maakt dan enkel package installeren en gaan. Je moet immers ook denken aan hoe gaan de flows, hoe kunnen we de "tussenfase" faciliteren waarin iemand wel is ingelogd, maar nog niet zijn second-factor heeft afgegeven, waar en hoe worden de tokens opgeslagen, hoe werkt 't beheer, welke richtlijnen gaan we opstellen voor als iemand zijn second-factor verliest etc.

Bovendien is lang niet alle code up-to-date, en zeker voor bijvoorbeeld het beheergedeelte zal de login-flow zelf nog aangepast moeten worden om überhaupt 2FA te kunnen ondersteunen. En laat nu net het beheergedeelte vanuit het oogpunt beveiliging juist interessant zijn.

Nu zul je zeggen, begin gewoon want jullie werken agile? Doe eerst dat beheergedeelte fixen, en dan een meest eenvoudige versie van TOTP aanbieden? Ja zeker, dat wil ik wel, maar eerst ligt er nog een hoop 'laaghangend fruit' :)
Jullie werken met Symfony toch? Ik heb daar https://github.com/scheb/2fa voor gebruikt. Die kent na Auth, maar voor 2FA verificatie een extra role toe aan de user. Daarna in je security,yaml (aanpassen naar eigen smaak):

- {path: ^/admin/2fa, role: IS_AUTHENTICATED_2FA_IN_PROGRESS }
- {path: ^/admin, role: ROLE_ADMIN }

Onze 'shop' mag ook wel significant genoemd worden, met ook een hoop legacy. Die oplossing was erg makkelijk toe te passen met veel customize ruimte :)

[Reactie gewijzigd door Martijn.C.V op 22 juli 2024 14:05]

Dank je wel voor je tip, ik zet hem in het document er bij als "te bestuderen bronnen" :)
Tweakers komt volgens mij nogal uit de "Not Invented Here"-hoek als ik zo kijk naar de implementaties in het verleden en de huidige stack.

De moderatiescores zijn ook nog steeds synchrone ajax calls, die mijn GUI laten vastlopen als dat request ietsjes langer duurt bijv. Chrome waarschuwt daar ook over als je de console opent na een moderatie.

[Reactie gewijzigd door MsG op 22 juli 2024 14:05]

Ze schrijven toch dat van twee servers beide redundante voedingen op dezelfde rail waren aangesloten.
Als die rail er dan uitgaat voor onderhoud ben je die servers kwijt.

Dus heeft niets met meer redundant te maken en ook geen ongelukkig toeval maar gewoon een menselijke fout van degene die de server geplaatst heeft.
Zoiets kun je alleen met controle procedures proberen te voorkomen.
Nee, ze schrijven dat er twee servers met een enkele voeding op dezelfde feed waren aangesloten. En als ze elkaars fail-over zijn is dat jammer en kun je dit met een ATS voorkomen
Misschien was er ten tijde van het plaatsen van die servers wel helemaal geen tweede rail? En is er een aanname gedaan dat sinds er een tweede rail is alles inmiddels voorzien was van een aansluiting?

Controles hadden dit misschien uitgewezen maar ook dan zie je dit soort dingen helaas ook wel eens over het hoofd in een vol rack.

Edit:
* GewoonWatSpulle herrinnert zich wel een datacenter waarbij men geadviseerd werd de aangeleverde stroomkabels te gebruiken en die waren oranje en blauw als ik het mij goed herinner, voor de verschillende stroom voorzieningen. Is er een tweaker die dit datacenter toevallig bij naam weet te herinneren? (Volgens mij in Rotterdam)

[Reactie gewijzigd door GewoonWatSpulle op 22 juli 2024 14:05]

Maaaarrrr

Welke lijf /worstenbrood /taart straf staat er op het missen van die 2 servers?

Collega's hebben toch minimaal een bak koffie gekregen van de gestruikelde herder?

:+
Vroeger hadden we de traditie om op tompoucen te trakteren bij dit soort dingetjes (we zaten tenslotte boven de Hema in Noord). Maar eigenlijk is dat niet een hele gezonde (en dan bedoel ik niet alleen fysiek) manier om hiermee om te gaan. Iedereen maakt tenslotte fouten en om dan op tompoucen te trakteren, voelt toch een beetje als schandpaal/straf. We kijken nu simpelweg naar wat er is fout gegaan en hoe we dit gaan voorkomen in de toekomst.
Dat klinkt alsof de ARBO art ingegrepen heeft omdat jullie allemaal indikte :).

Wij doen het onderling nog wel. Fouten zijn prima.. maar wel trakteren. Al is het 1 bitterbal per man op vrijdagmiddag. We houden het dan wel onder ons en hangen het niet door het bedrijf heen.

Bij ons blijft het voorlopig lollig.
Mwah schandpaal. Ik zie het meer als het vieren van een leermoment voor het team. Dat soort dingen zijn belangrijk in de groeiende wereld van DevOps.

Op een bepaald moment denk je bijna alles wel gezien te hebben. Het standaard onderhoud ben je resillient tegen en dan gebeurd er zoiets. Op het moment dat het gebeurd is de kans groot dat er een iemand ineens een facepalm maakt en denkt “ohja sat ding”. Dat noem ik dan DevOops. Helemaal niet erg dat het gebeurt alleen wel erg dat er niet over gecommuniceerd is geweest, bijvoorbeeld. Want dan had het team het geweten.

Die taarten zijn dus niet zozeer voor de fout met de hardware of het stukje software, maar het stuk communicatie over iets wat later mogelijk issues kan geven en waar je als team niet dicht genoeg bij elkaar staat waardoor communicatie niet optimaal kan zijn.

De taart is dan een mooie incentive om gewoon ff met elkaar te ouwehoeren. Goed voor de teambuilding. Sws moet er eigenlijk iedere twee weken een keer taart zijn.
Of doen jullie niet aan Taart driven development?
Inlogissues voor Tweakblogs zijn opgelost.
Even tussen neus en lippen door melden ze deze belangrijke fix :+

Thanks!
Ik had er al een maand geen last meer van door cookies te verwijderen, uit te loggen en weer in te loggen.

Het blijft tenslotte een Tweakers platform en begin je met de basis als het begint te irriteren :)
Dat deed de truc niet bij mij. Believe me, I tried ;)
zo inderdaad hee. Kan me herinneren dat ik een paar maanden geleden al een keer zoiets had van oh dit werkt niet. Hmm apart. Dat is dus al die tijd een issue geweest?
Mooi om te lezen dat beveiliging leeft binnen Tweakers. Had natuurlijk niet anders verwacht ;)

Ben wel benieuwd of het beveiligingsmanifest "from scratch" wordt opgesteld n.a.v. jullie eigen ervaringen of dat jullie gebruik maken van een van de vele standaarden/richtlijnen die op dit gebied al bestaan.

Bedankt voor de transparantie en update.
We hebben gekeken naar andere security manifesten en guidelines, en daaruit gedistileerd wat wij belangrijk vinden en wat we ook al doen in de praktijk. Daarnaast hebben we ook gekeken of er andere zaken zijn die we belangrijk genoeg vonden om in ons eigen manifest op te nemen. Daarbij hebben we eventuele engelse standpunten naar het nederlands vertaald. Uiteindelijk is het een mooi geheel van standpunten die we al volledig naleven, deels naleven en nog willen verbeteren.
Wordt het manifest ook gepubliceerd tzt? Ik ben uiteraard benieuwd waar Tweakers voor staat, maar ik denk dat er ook genoeg bedrijven zijn die er van zouden kunnen leren.
We hebben het hier wel over gehad, en ik denk ook zeker dat het leerzaam kan zijn voor anderen. Immers, wij hebben ook veel gebruik gemaakt van verschillende manifesten, en dat hielp ons enorm. Het document is nu in ieder geval nog echt bedoeld voor intern gebruik, en ook de andere devvers mogen nog hun mening geven over het voorstel wat we als tech-team hebben gemaakt. Maar, een manifest dat je publiekelijk maakt is natuurlijk ook veel krachtiger; immers, je kunt je niet meer verschuilen onder "dat weet toch niemand"

Dus nog niet, maar hopelijk wel binnenkort!
Kudo's voor deze transparantie!
Helemaal mee eens !
@ikloon @Kees Wat betreft die down-tijd, zijn er dan daardoor ook plannen om dit meer redundant te maken? Of is dit een ongelukkig toeval en wordt er iets in de procedures opgenomen om dit te voorkomen?
Ja, 1 server qua stroom omprikken is genoeg om het meer redundant te maken, en wellicht schaffen we nog wat ATS'en aan om het helemaal te voorkomen dat er iets down gaat tijdens stroomonderhoud.

[Reactie gewijzigd door Kees op 22 juli 2024 14:05]

Goed dat beveiliging nu prioriteit krijgt (ook al is het nog niet concreet). Iedere Tweaker herinnert zich nog wel het debacle met 'Geen default SSL, want negatief effect op snelheid' van een paar jaar geleden.
Beveiliging is iets anders dan veiligheid, en SSL gaat meer over veiligheid. Verder kan ik me wel een levendige discussie herinneren, maar geen debacle ;) Met HTTP/2 was impact op performance iig geen groot issue meer en hebben we HTTPS/SSL voor de gehele site ingevoerd (daarvoor zat de profiel-omgeving al achter HTTPS).
Hoewel we daarop waren voorbereid, waren er twee servers die met een enkele voeding op dezelfde feed waren aangesloten, tussendoor geglipt.
Daar zijn oplossingen voor zoals pricewatch: APC Rack Automatic Transfer Switch.
En dan nog op 1 feed aansluiten ;)
In de tracker worden onder het label .plans geen advertentieartikelen (.adv's) meer getoond.
Dit is gewoon zo ontzettend fijn! :) _/-\o_

Op dit item kan niet meer gereageerd worden.