Debian 8 LTS is na vijf jaar end-of-life

Debian 8 is end-of-life. De Long Term Support van het Linux-besturingssysteem is per 30 juni gestopt, schrijven de ontwikkelaars. Debian 8 werd sinds april 2015 ondersteund, maar krijgt nu geen beveiligingsupdates meer.

Debian 8, ook wel 'Jessie' genoemd, heeft officieel de end-of-life-status gekregen. Jessie wordt sinds 30 juni niet meer bijgewerkt, maar de ontwikkelaars maken de transitie nu pas bekend. Debian 8 LTS kreeg sinds 26 april 2015 al beveiligingsupdates.

Het Long Term Support-team gaat nu werken aan Debian 9 LTS, ook wel Stretch genoemd. Ook dat besturingssysteem krijgt vijf jaar lang securityupdates, tot aan 30 juni 2022. Ondersteuning voor dat OS geldt voortaan niet alleen voor amd64-, i386,- armel- en armhf-architecturen, maar ook voor arm64.

Reacties (92)

[Strebor]

Gelukkig is er, voor mensen die nog echt niet kunnen upgraden, Debian 8 ELTS:

https://deb.freexian.com/extended-lts/

Die heeft nog twee jaar ondersteuning op aardig wat pakketten (geen MySQL overigens) en dat is gratis.

[UPPERKEES]

Als je echt zo'n lange support wil dan kan je beter CentOS nemen (10 jaar). Er zit zoveel end-of-life software in Debian, PHP alleen al is vaak na 2 jaar al zonder upstream support. Debian devs zelf zeggen al dat ze de load van onderhouden niet aankunnen en prioriteiten moeten stellen om er nog wat van te maken.

Sure, dat heb je deels ook met CentOS, maar daar kan je met interne repo's nog upgraden naar nieuwe PHP versies met gewoon upstream support, wat ook kan voor andere software. Maar dan zonder op de PPA tour te gaan, wat nagenoeg hetzelfde is als (Russian hacker) community docker containers in productie te draaien.

En CentOS leunt op dikke portemonnee en flinke resource pool van Red Hat die daar gewoon mensen op zetten om de boel op orde te houden. Dus leuk zo'n Debian 8 ELTS, voor thuis (alsnog frowned upon though).

[MrFax]

Voor thuis moet je gewoon elke 2 jaar upgraden naar de nieuwste Debian als je dat echt gebruikt. Anders kan je beter Ubuntu LTS gebruiken want die zorgen ervoor dat pakketten up to date blijven inclusief security fixes. Het grootste voordeel daar is dat ook de kernel optioneel up to date gebracht wordt gehouden elke point release, wat een groot voordeel is als je packages ook up to date wilt houden.

[Reactie gewijzigd door MrFax op 23 juli 2024 02:53]

[Aanwezig]

Waarom? Juist thuis zit je achter een NAT. Uiteraard moet je niet het gevaar opzoeken met een oude browser oid. Maar relatief is het niet zo erg als de gemiddelde telefoon met ongein als Whatsapp

[MrFax]

Dat is echt een drogreden om je software niet up to date te houden. "Ach wat is de kans dat ik gehackt wordt en ik heb toch niks te verbergen."

[Aanwezig]

Ik breng het in perspectief. Dat is wat anders dan een drogreden. Up to date houden is goed, niet noodzakelijk beter. Je noemt specifiek thuis, nou dat is heel wat anders dan een edge router zonder laagjes firewall. Uiteraard heb je wat te verbergen. Halsoverkop bleeding edge gebruiken dat minder getest is, is het anderste uiterste

[pbeer]

Bij de NAT-router fabrikanten denken ze, ach de gebruikers zullen hun OS wel patchen...
nieuws: Onderzoek: vrijwel alle routers voor thuisgebruik hebben verouderde s...
Ik vind jou perspectief levensgevaarlijk.
Bovendien, een NAT-router is geen firewall. Je OS en software updaten is te weinig. Je router software updaten is te weinig. En opletten met wat je gebruikt/installeert/doet is te weinig. Het is allemaal te weinig.

[Aanwezig]

Het is allemaal te weinig. Echter wordt er wel degelijk een risico analyze gedaan om te voorkomen dat de ISP niet kan voortbestaan of centjes te verdienen. Het is helemaal waar wat je zegt maar het is niet zo zwart wit

[MrFax]

Nee maar zelfs de nieuwste Debian releases zijn LANG geen bleeding edge. Die zaten al 2 jaar in de Testing branch. Debian LTS is daarom voor de thuisgebruiker ook totaal onnodig.

LTS releases zijn nodig bij bijvoorbeeld kassasystemen zoals die van de AH. Want zo'n LTS release kan je met een zo'n klein mogelijk kans op problemen veilig houden.

[Reactie gewijzigd door MrFax op 23 juli 2024 02:53]

[RJG-223]

Nee maar zelfs de nieuwste Debian releases zijn LANG geen bleeding edge. Die zaten al 2 jaar in de Testing branch. Debian LTS is daarom voor de thuisgebruiker ook totaal onnodig.

Als je niets van Debian weet, moet je ook niets roepen.

De Testing release is nagenoeg bleeding edge - alle updates, nieuwe versies, etc. van software komen in principe, na een afkoelingsperiode / testperiode van 10 dagen (meen ik) in Testing. Testing is dus op geen enkele manier vergelijkbaar met een branch. Testing is gewoon de trunk, oftewel main development versie, maar dan grofweg 10 dagen vertraagd.

Pas op het moment dat ze een nieuwe Stable release willen uitbrengen worden de wijzigingen aan Testing gedurende ca. 6 maanden beperkt tot enkel bugfixes. Zodra er geen belangrijke bugs meer in zitten, en dan wordt dat de nieuwe Stable release, en krijgt Testing weer de laatste updates.

[mkools24]

Dat zegt hij toch? Als je nu 10.4 installeert heb je redelijk oude meuk.

Voor ZFS bijv moest ik backports repo toevoegen om toch een nieuwere versie te krijgen, zefde als met de nvidia driver.

De stable releases van Debian zijn zwaar conservatief met nieuwe software versies, zelfde als CentOS en je gaat testing toch niet in productie gebruiken.

Voor thuis als je bleeding edge wilt zou ik sowieso geen Debian aanraden maar gewoon Ubuntu of Fedora.

[RJG-223]

10.4 is stable, en niet Testing, en inmiddels één jaar oud. De software is dus waarschijnlijk minstens 1.5 jaar oud. Maar hij heeft het niet over de huidige nieuwste release, maar over 'de nieuwste releases' in het algemeen.

Hij heeft het er dus over dat een nieuwste release op het moment van uitbrengen geen bleeding-edge is, omdat die al twee jaar in Testing zit, waarmee hij dus bedoelt/impliceert dat de nieuwste release op het moment van uitbrengen al twee-jaar-oude software bevat. Dat klopt dus niet.

[keranoz]

NAT is geen firewall. Helemaal niet sinds bijna iedereen inmiddels IPv6 heeft.

[Reactie gewijzigd door keranoz op 23 juli 2024 02:53]

[Aanwezig]

Ipv6 is helaas geen gemeengoed. Een groot deel van de prijsvechters heeft het niet. Bij de KPN experia boxes moet je dit specifiek instellen dat inkomende verbindingen toegestaan zijn. De ISP heeft hierin een zorgplicht dat het sane defaults heeft. Moet je daarop leunen? Nee

[To_Tall]

Dan komt de buurjongen of neefje even langs omdat de WiFi boven niet goed werkt. Hij logt in op de router. Hey, ipv6 staat niet aan hoppa we zetten het aan.

Daarnaast zijn steeds meer isps. Die ipv6 aanbieden en over een niet al te lange tijd default zal aanzetten op de router. Omdat men anders niet op ipv6 websites kan komen.

ISP zoals KPN bieden niet voor niets pakketten aan zoals veilig internet.

[Dutch2007]

iedereen? hah!, 25% bij KPN en Ziggo ;-)

Zie het Tweakers IPv6 topic: Het grote IPv6 topic (bijna onderaan de pagina)

Liberty Global is Ziggo/VodafoneZiggo

[keranoz]

Oh ik dacht echt Ziggo en KPN inmiddels bij zowat iedereen IPv6 hadden uitgerold.

Ik heb al een paar jaar dualstack volgens mij bij Ziggo

[sampoo]

Je kunt met Debian ook werken met interne repos en daamee upgraden naar nieuwe PHP versies, dus daar zit het verschil niet in met CentOS.

[UPPERKEES]

Dan heb je het over de "testing" distributie. Dat is een repo die verbonden staat met "stable", dan hebben we het over 2 verschillende distributies. Dat is hetzelfde als het gebruiken van een CentOS/rawhide repo van de volgende release. Dat is dan wel een interne repo, maar volledig buiten je eigen distributie. Dat is niet hetzelfde wat ik dat is geen best practice of überhaupt een supported actie. Dat gaat met risico's, want je kan dan extra dependencies binnentrekken waarbij je core libraries veranderd en dan gaat je hele API/ABI stability verloren.

[Reactie gewijzigd door UPPERKEES op 23 juli 2024 02:53]

[sampoo]

Vast houden aan een EOL-product lijkt mij per definitie geen best practice of supported. Het zal om een tijdelijke en gerichte oplossing moeten gaan. Core libraries vastpinnen op de gewenste versies en de repo die je erbij kiest zet je alleen open voor de benodigde packages. Ik zou zelf de voorkeur geven een lokale repo voor de handvol extra packages en zo snel mogelijk de overstap maken naar een ondersteunde LTS versie.

[Reactie gewijzigd door sampoo op 23 juli 2024 02:53]

[Verwijderd]

PHP pak ik sowieso in Debian alsmede Ubuntu via sury MySQL is een kwestie van de repo's van MariaDB toevoegen. Volgens mij zijn die repo's allen net even wat sneller met releasen dan de repo's van CentOS, Debian, Ubuntu zelf.

[UPPERKEES]

"Sury" is dus zo'n third party waar ik het over heb. Zodra je dat moet doen dan is het tijd om een andere distro te pakken. Want eigenlijk zeg je dan al, mijn distro is niet voldoende, ik moet het fixen met iets buiten mijn distro. Wat je verder zegt over CentOS klopt verder niet. Bekijk dit overzicht maar eens. Dat kan je ook binnen CentOS gebruiken. Er zijn meer van dat soort repo's. Gewoon ondersteund binnen je eigen vertrouwde distributie en waarborging van dezelfde kwaliteit. Dat samen met upstream support zit je dan gewoon goed. Geen houtje touwtje werk.

[Reactie gewijzigd door UPPERKEES op 23 juli 2024 02:53]

[Hydranet]

En binnen RHEL8/CentOS8 heb je tegenwoordig nu ook Application Streams waardoor het ook makkelijker word om nieuwere versies te gebruiken en toch binnen de repositories van RHEL te blijven.

[GrooV]

Daarom draai ik zo veel mogelijk op containers, upgraden is veel makkelijker en je containers kunnen indien nodig een oude specifieke versie blijven draaien

[Katsunami]

Als je echt zo'n lange support wil dan kan je beter CentOS nemen (10 jaar). Er zit zoveel end-of-life software in Debian, PHP alleen al is vaak na 2 jaar al zonder upstream support. Debian devs zelf zeggen al dat ze de load van onderhouden niet aankunnen en prioriteiten moeten stellen om er nog wat van te maken.

Dat elke distributie zijn eigen repo heeft, waarin het OS en de applicaties bijna onlosmakelijk zijn verweven, is dan ook een rare constructie. Probeer eens een hedendaags programma te installeren op een Linux van 5 jaar terug; of een oud programma op een Linux van nu. Veel succes... in het geval van Windows kan dat gewoon.

De juiste manier zou zijn om Linux (Gnu / Linux, voor iemand erover begint) per distributie in zijn eigen repo te zetten, en compleet los te knippen van alle applicaties. In die repo zouden dan verwijzingen kunnen zitten naar repo's die onderhouden worden door de applicatie-ontwikkelaars. De applicatie-ontwikkelaars kunnen dan een repo hebben per distributie die ze wensen te ondersteunen. Een repo dat zou werken voor meerdere distributies, kan dan gebruikt worden door elk van die distributies.

Op deze manier zouden Linux, en de applicaties, apart van elkaar onderhouden kunnen worden, en zouden nieuwe applicaties compatible kunnen blijven met oude distributies en omgekeerd.

Op de huidige manier lijkt alles wel modulair te zijn, maar in mijn ogen is het gewoon een grote repo-kluwen. Soms komt het voor dat je in een upgradeketting terecht komt. Je werkt het éne programma bij, die dan zus bijwerkt, waardoor weer zo bijgewerkt moet worden, enz.... voor je het weet ben je je hele OS en een aantal applicaties aan het upgraden omdat je van één programma een nieuwere versie wil installeren.

[UPPERKEES]

Dat is geen rare constructie. Speciale build flags voor security/hardening worden dan ook centraal geregeld, ook je security patches worden mooi centraal bijgehouden. Dat is zoals het hoort. Bij Windows kan je applicatie gebundeld worden met een out-dated 'openssl' (dunno wat je normaliter gebruikt in Windows). Dan kan je wel denken veilig te zijn met je up-to-date OS, maar je applicaties leiden een totaal ander leven.

Wat je verder beschrijft, zoals iets installeren van 5 jaar terug is in de meeste gevallen mogelijk. Het is wel de vraag wat je wil installeren natuurlijk en wat de afhankelijkheden zijn. Maar door de POSIX standaard kan je zelfs applicaties van de jaren '80 installeren. Tenzij het natuurlijk iets novels heeft, maar dat probleem heb je ook met Windows.

Tenzij je inderdaad alles bundelt, dat kan met containers zoals Docker/Podman en met Flatpak. Flatpak heeft zijn OS onafhankelijke repo's en kan je in principe een applicatie shippen naar alle distributies, van verschillende versies. Gelijk ook met een sandbox erbij.

[Reactie gewijzigd door UPPERKEES op 23 juli 2024 02:53]

[Katsunami]

Vaak genoeg ben ik problemen tegengekomen, waarbij één programma versie X van een library nodig heeft, een ander programma versie Y. Dan heb je dus best een groot probleem, want om die naast elkaar geinstalleerd te krijgen is meestal niet triviaal.

Flatpak, waarin een applicatie zit met al zijn afhankelijkheden, kost wel meer ruimte, maar het zorgt er ook voor dat die applicatie onafhankelijk is van alle andere applicaties en het OS zelf. Gezien hoe goedkoop schijfruimte en zelfs geheugen tegenwoordig is (mijn huidige 5 jaar oude computer heeft al 2 TB opslag en 32 GB RAM, net als de laptop; en dat wordt enkel maar meer), is iets als Flatpak wat mij betreft de toekomst.

Ook voor Windows overigens: ik "installeer", indien mogelijk, het liefst portable applicaties. Een "normale" applicatie vreet zich in Windows vaak te veel in het systeem in, met bestanden verspreid over de hele schijf in allerlei mappen. (Dat gebeurt op Linux ook, maar daar is er nog een standaard over wat waar hoort; in Windows is die standaard er op zich ook, maar daar houden ontwikkelaars zich vaak niet aan.)

[elmuerte]

CentOS is een redelijk kleine distributie. Zonder EPEL kom je niet heel ver, maar EPEL heeft niet de 10 jaar support. En zelfs binnen EPEL worden niet alle packages even goed onderhouden. Het is me vaak genoeg voorgekomen dat de nieuwe EPEL package major upgrades waren die niet compatibel met de huidige setup. Iets wat me bij Debian nog nooit overkomen is. Zoals je zei, dit is gewoon niet de onderhouden voor een hele lange tijd met veel packages.
10 jaar lang op dezelfde baseline blijven zitten is echt verschrikkelijk lang. Zeker als je bedenkt dat je op die baseline alleen security patches kan verwachten, maar geen security upgrades. Je gaat geen nieuwe TLS versies krijgen.

[pennywiser]

MySQL kan je hier wegpakken: https://dev.mysql.com/downloads/repo/apt/

[Terr-E]

Of hier:
https://www.percona.com/doc/percona-repo-config/percona-release.html

[Archcry]

Mensen kunnen eventueel ook nog overwegen om over te gaan naar MariaDB.

[army]

Gezien de drift van Oracle om licenties te verkopen kan dat weleens geen slecht idee zijn. Van verschillende grotere organisaties in oa NL is al bekend dat ze de overstap naar PostgreSQL maken om juist deze reden.

[paradoXical]

Ik heb nog een Ubuntu 12.04 server draaien, is ook EOL. Al geruime tijd zelfs Hoeft geen issue te zijn indien je weet wat je doet.

[Egocentrix]

[...] indien je weet wat je doet.

De netwerkkabel eruit trekken bijvoorbeeld

[Accretion]

Leg uit?

Ik ben het een beetje met je eens hoor, zo lang je server achter een firewall zit op een gesloten netwerk; is het altijd relatief veilig. Zeker met een fatsoenlijk back-up systeem en/of als je je server heel snel weer opnieuw kan opzetten en je een soort scheiding hebt (met Docker containers bijvoorbeeld).

Echter; met verouderde smb shares etc, services die open zijn op het internet etc, zou ik het liever toch niet doen.

[To_Tall]

Doordat je per ongeluk een Port open hebt staan in je fw naar je eol server. Kom je er pas na maanden achter dat er een hacker misbruik maakt van een bekende lek op je server. En zo verder komt op je netwerk.

Een server staat er niet voor niets. Op een of andere manier heb je die neergezet om een taak te vervullen. Als hij niet op het netwerk zou staan had hij ook uit kunnen staan.

Elk device en of computer/server dient gewoon supported te zijn en gepatched kunnen worden via de officiële kanalen.

Alles wat daar buiten valt. Niet uitgezet worden.

Helaas zijn er nog steeds bedrijven met B.V. server 2003. Omdat de applicatie die er op zit zo belangrijk is. Maar geen geld willen uitgeven om de applicatie te updaten.

[Accretion]

Zijn punt was inderdaad: "Als je weet wat je doet".
Per ongeluk een port open hebben staan; is niet weten wat je doet.
"Kom je er pas maanden achter"; is ook niet echt weten wat je doet. Er wordt hier vaak geopperd dat mensen hier constant hun netwerk loggen voor verdachte activiteit.

Ik kan lokaal een CCTV server draaien op een gescheiden netwerk/VLAN; welke outdated is. Maar dat hoeft niet direct een probleem te zijn?

Ik ben het er zeer zeker mee eens dat je spul moet updaten en bij moet blijven. Maar als we heel kritisch zijn; zorgen juist updates vaak voor problemen.

[Blokker_1999]

Per ongeluk een poort open hebben staan heeft niets te maken met wel of niet weten wat je doet. Iedereen maakt fouten. Daarom dat beveiliging ook niet mag afhangen van 1 enkel ding maar een keten moet vormen. Met een up to date systeem is het risico gewoon kleiner mocht je vergeten een poort te sluiten zijn.

En loggen is leuk, maar je kan zoveel loggen dat je door de bomen het bos niet meer ziet. En je mag zoveel loggen als je wenst, als je de logs niet bekijkt wegens tijdsgebrek heb je er ook niets aan.

En als je schrik hebt dat updates voor problemen zorgen, dan zorg je voor een plan om een rollback te kunnen doen of eerst te testen wat het effect van een update is. Het kan niet zijn dat je gaat zeggen: ik doe geen updates omdat ik het risico te groot vind. Als we heel kritisch zijn dan is niet updaten gewoon een kwestie van geen moeite te willen steken in het goed doen.

[Aionicus]

Daar ben ik het totaal niet mee eens.

Kijk naar de laatste besturingsystemen van microsoft. (W10 / 2016/2019). Productieservers die gingen rebooten in de eerste periodes ondanks dat het duidelijk was aangegeven niet tijdens die uren, zelfs microsoft wist er geen raad mee na maanden klagen bij ze en dat hun senior engineers persoonlijk kwamen deep diven in ons cloud netwerk om te kijken waarom het niet werkte. Updates die ineens ongevraagd candy crush gingen installeren op de vdi's van klanten ondanks dat alles uitgezet was.Windows defender wat ineens actief ging weer door een update ondanks dat er overal bitdefender of eset op stond. Updates die printers kapot maken. Heh als je op reddit kijkt dan staat het er voor mee waarom latest greatest zeker niet altijd van toepassing is. Dan is het ook nog eens dat je niet meer zoals vroeger alleen security updates kon pushen maar dat je vast zit aan wat ze doorpushen.

Loggen is leuk , nee Loggen is mandatory.Monitoring is mandatory. En met de juiste filters heb je alle informatie die je nodig hebt. Ik draai 80+ vm's thuis op mijn interne netwerk maar als er ook maar iets plaats vind wat niet hoort dan weet ik dat. Daarbij heb je ook nog eens genoeg mogelijkheden om andere pieken of unwanted traffic te herkennen. Een callback naar china van een mediakastje wat stiekem alleen een txt record opvraagt om de laatste informatie binnen te halen zie ik direct. (was ook meteen uitgeschakeld).

Ja we maken fouten als mensen , maar als je goed bent in je vak en jezelf kent dan zorg je ervoor dat je software hebt staan wat je attendeerd op je fouten en dat je ze kan corrigeren. Zelfs al komen ze hier op het netwerk binnen dan zouden ze nergens bijkunnen want elke machine met een open port is geisoleerd van het netwerk (vlan+virtual applicance firewall)
met daaraan de desbetreffende monitoring. Het is gewoon een manier van werken.

Een up to date systeem kan helpen het risico kleiner te maken maar tegen een 0day heb je toch weinig kans, dus in dat geval ben je net zo kwetsbaar en komt het weer aan op je expertise in het omgaan met legacy hardware / software.
Je kan best een linux server EOL draaien, het is immers geen windows. Je moet alleen weten wat je doet. (desondanks ben ik van mening dat je beter dan de applications kan dockeren en het host os gewoon update), maar dat is vaak nog een financiele kwestie met software die ooit miljoenen gekost heeft of bv waarvan het bestaande bedrijf failliet is gegaan en het overstappen miljoenen meer zou gaan kosten dan 100k neerleggen om een eol systeem te ondersteunen met een FTE of 2).

Als we heel kritisch zijn dan is updaten niet een kwestie van geen moeite willen steken in het goed doen, maar zelf controle hebben over hoe wat waar en daarbij de kosten en de baten. Luiheid ? Nimmer.

Je kan met een unpatched windows 7 machine nog perfect op internet mits je het alleen voor bepaalde doeleinden gebruikt en bv de juiste browser / adblocker / av hebt draaien. Wil niet zeggen dat het optimaal is maar het kan zeker. (en het scheelt schiijfruimte, 7gb clean install w7 tegen 24-30gb patched up). Het is echt per use case en per expertise van de gebruiker.

Een EOL development server welk bv een lockdown heeft op ip basis en gewoon een goede firewall ervoor (be it virtual zoals opnsense) zou in theorie nog jaren door kunnen draaien. Voor de rest van de wereld qua verkeer is het gewoon null routing.

En het bestaansrecht van bv een EOL server is soms wel degelijk uit te leggen. (denk aan de medische wereld , ruimtevaart, klimaat etc , antieke randapparatuur wat ooit miljoenen heeft gekost)

Al met al :

- Ip based access
- Goede lockdown (acl / no shells etc)
- Security updates voor alles wat open staat en hun dependencies
- Firewall ervoor
- null routing op alles wat niet vanaf trusted source komt
- monitoring op file system changes die niet horen
- triggers om bij een change het terug te zetten (foreman , puppet)
- proper alerting -> rsyslog / elk stack / grafana / logstash / prtg

Je kan bij freebsd en de linux varianten genoeg doen om het goed dicht te timmeren. De hardening index van Lynis Enterprise komt altijd tussen de 95-100 percentile en de rest van je af via monitoring/triggers/safeguards.

Als afsluiters,

Logs niet bekijken door tijdsgebrek betekend gewoon dat er iets mis is in de organisatie. Bij een goede organisatie werk je progressief om problemen op te pakken en heb je weinig alerts. Als je alleen maar reactief aan het rennen bent moeten er mensen bijkomen.

En ook al draai je je updates ,als je je monitoring niet op orde hebt (zoals het rapport van fox-it liet zien van de week over de gepatchde citrix servers) dan staat die backdoor nog steeds geinstalleerd. Dus de beheerders hadden snel patches gedraaid maar nooit gekeken of er iets niet klopte verder of ze hadden de houding we zijn nu veilig want we hebben de patches gedraaid.

In theorie zou je dus het volgende kunnen stellen : een update garandeerd geen veiligheid tegen 0days en helpt pas wanneer de update beschikbaar is. De schade zou dus allang gedaan kunnen zijn zonder dat je eer ooit zicht in had. In dat geval maakt het dus niet uit of je een geupdate systeem hebt of niet.

Wel maak je het aanvallers makkelijk om je via een infected webpage te pakken , dat zeker. Updates zijn soms belangrijk en noodzakelijk.Desondanks krijg je ook veel troep mee of interface changes die soms niet wenselijk zijn.

Adequate monitoring / state maintaining / logging / alerting / lockdowns is vele malen belangrijker.

[To_Tall]

Ten eerste EOL is niet iets economisch. Er is geen support meer. Naast updates en andere zaken levert de fabrikant ook geen support meer of het nou een software product is of hardware. Als eol aan doet en dat is redelijk goed te voorspellen. Zal je moeten kijken naar upgrade paden. En niet je kop in het zand steken en denken oh ik heb er genoeg verstand van.

Dat goede monitoring en logging noodzakelijk is. Ja tuurlijk maar dat heeft niets te maken of een fabrikant wel of niet zero days patch. Er hoeft maar een fout in je firewall zitten of een zeroday die nog niet bekend is. Dan ben je toch kwetsbaar. Voor jou thuis misschien niet zo’n probleem al zou ik nooit kunnen verzinnen waarom je 80 vm’s nodig hebt privé. Maar als ze toch bij jou thuis binnen komen op 1 van die 80 vm’s waar je voor beheer toch 0,2 fte nodig hebt voor beheer en onderhoud. Zal je dat alleen merken als je de monitoring in duikt. Verkeer hoeft niet vreemd te lijken om toch vreemd te zijn.

Wat jij hierboven beschrijf kan natuurlijk altijd. Echter heb je 24/7 toezicht nodig. Niet alleen in de ochtend je log checken en de rest van de dag wat anders doen. Bij de meeste bedrijven is er maar 8 uur iemand aanwezig en 16 uur afwezig. In die 16 uur kan veel gebeuren.

Betreft w7. Ja daar zou je nu nog redelijk veilig mee kunnen surfen. Echter als er al een lek is maar nog niet publiekelijk bekend is maar bij een groepje. Zal het voor jou thuis niet zo’n probleem zijn. Echter de pc’s bij bedrijven en overheid kunnen een potentieel probleem. Als dit ook het doel is van deze groep.

Anyway je beveiliging is zo sterk als de zwakste beheerder.

[_Pussycat_]

Vraagje: wat doe je thuis met 80 vm's?

[Immutable]

Mijn vraag aan jou, waarom heb jij thuis geen 80 vm's? Je hebt toch ook een bank, tv, toilet, een keuken?

[Aionicus]

Oh dat wil ik best wel uitleggen haha

Uit de tijd dat ik ZZP'r was had ik de neiging om test omgevingen te bouwen van dingen die ik in productie uit ging rollen, vooral legacy migraties en andere dingen waar 16 bit software bij kwam kijken was afentoe nog wel een uitdaging. Wat draai ik zoal thuis :

- meerdere hypervisors (proxmox / xen / vmware/ kvm) (bepaalde variaties zoals bv een ceph cluster voor proxmox of een citrix netscaler / xendesktop omgeving / vmware horizon omgeving)
- meerdere test domains met hun indivuduele 'firewalls' en appliances (om bijvoorbeeld goed een site 2 site te simuleren met daarop bepaalde caps op bv bandwidth) om te zien wat bepaalde services voor impact hebben die onze klanten draaien.
- Mijn eigen domotica / cameras
- media indexers / web scrapers / ids / pihole / dns servers / mail servers (redmail/exchange etc)
- development vm's (python / c++ / php)
- vps nodes (ik bouw mijn eigen cpanel alternatief), hier heb ik 4 productie machines voor draaien die dagelijks builds testen en load testing doen etc)
- kubernetes clusters met allemaal HA dingen voor testen
- IPA omgeving ingericht voor state monitoring en management (hardening / lockdowns / puppet / ansible / filebeat and nog meer andere leuke dingen)
- Hybrid solutions (IPA / LDAP icm VDI (win/linux)).
- allemaal monitoring / alerting / backup appliances.

en nog een hoop speeldozen.

Niet dat ik een groot budget heb of dat mijn energie rekening mega is , alles is ingericht voor low power efficiency (al maakt het dat soms wel wat trager) maar het is voor mij als IT'r de manier om mijzelf heel breed te kunnen inzetten. Het is natuurlijk op bepaalde manieren overkill. Maar het helpt enorm als je de resources hebt thuis om dingen van a tot z te bouwen of te slopen . Een vaag azure issue ? ik pak me azure omgeving er wel bij en ga met vm's analyzen tot ik het kan reproduceren / oplossen. Handigheidjes die het leven makkelijker maken met autopilot/ deployment maar waar eigenlijk in de drukte van de dag geen tijd voor is om te scripten / bouwen , doe ik thuis in het weekend, dan de week erop is iedereen happy omdat iets wat eerst 3 uur tijd kostte handmatig teruggebracht is naar 5 minuten (inclusief after check) met 100% foutafhandeling en status updates in een private teams kanaal voor de desbetreffende deployer.

*let op : natuurlijk geen enkele vorm van klantdata of ook maar iets wat te herleiden is naar klanten bevind zich op mijn netwerk*.

De reden dat ik mijn thuis situatie aangaf ipv een werksituatie is omdat ik het net zo veilig maak als een zakelijke enterprise omgeving. Ja ik weet ik ben een uber nerd en niet iedere tweaker of IT'r zal zo zijn. Maar daarom vind ik dat het veel meer op inrichting en skill aankomt dan dat je wel of niet een patch draait.

Kan er nog een hele hoop over schrijven maar dat is denk ik niet echt heel zinnig momenteel. En ik moet nog kattenvoer halen haha.

[_Pussycat_]

Erg leuk, bedankt voor de toelichting!

[Terrestrial]

Grotendeels ben ik het wel met je eens als je in een bedrijfssituatie zit waar ze IT heel serieus nemen, maar in een thuis omgeving is dit te veel gevraagd en ook van de gemiddelde tweaker. Tuurlijk ben ik ook voor monitoring en wellicht heb jij een groot huis met kasten vol apparatuur, onbeperkt budget, is stroom verbruik geen enkel probleem, en heb je genoeg tijd/zin om elke dag logs door te gaan spitten en ingewikkelde filter en alerting systemen op te zetten, je kunt het allemaal net zo complex en secure maken als je zelf wilt maar op den duur kom je tot de conclusie, waar ben ik eigenlijk mee bezig.. Ook bij storingen zoeken heb je ineens een enorme uitdaging voor jezelf gecreëerd voor een netwerkje waar misschien een paar mensen gebruik van maken.? Ik weet niet of je een gezin hebt maar je had die tijd ook aan hen kunnen besteden, krijg je niet telkens het verwijt... oh zit die weer in z'n kantoor ehm hok.

[To_Tall]

Wat @Blokker_1999 ook aangeeft. Iets over het hoofd zien of een klein foutje maken heeft niets met onkunde te maken.

Ik ken een systeem dan al jaren zonder updates werkt. Echter. Enige wat er op aangesloten is. Is het stroom netwerk en een seriële kabel naar een hijs motor. Om een lift aan te sturen.
Systeem staat in een bunker, op de 33e etage. Ja zo’n systeem kan je zonder veel zorgen laten staan. Inbreken kan alleen lokaal/fysiek.

Echter een apparaat aan een netwerk hangen out of date eol al is het cctv. Is een no go tenzij het netwerk fysiek gescheiden is van de rest. VLAN klinkt leuk dat is een virtueel netwerk. Onderling is er nog steeds communicatie mogelijk, op 1 switch op het netwerk tussen 100e met een config fout en je kan nat gaan.

Als je thuis het risico wil nemen geen probleem. Ik heb hier een polis voor beroepsaansprakelijkheid voor me. Daarin staat ook dat bij willens en wetens door mij een fout wordt gemaakt lees server is eol en ik ben daar verantwoordelijk voor en ik weet dat er een security probleem is en ik adviseer om de server niet te vervangen. Kan ik aansprakelijk worden gesteld als blijkt door mijn gegeven advies een lek ontstaat en het bedrijf daardoor schade lijd. Ook al zou het risico 0,000001% zijn.

[still_the_same]

Ja, ik had ook klanten die dit soort zaken hadden. Tot ineens er geen hardware te vinden was die xp nog draaide... Dus zelfs stand alone machines moet je af en toe naar kijken.

[Blokker_1999]

Tuurlijk is die hardware nog wel te vinden. Ik kan je zelfs nog tonen waar je moederborden met ISA sloten kunt kopen. Maar denk dan niet dat je er goedkoop van af komt. Legacy hardware is duur.

[divvid]

He kan niet altijd updaten, bv om dat de fabrikant failliet is maar je machine van 3 ton niet te vervangen is. Het is niet altijd willen, maar soms ook moeten met oude software. ( gelukkig is daar singularity)

[paradoXical]

Hangt er helemaal vanaf waarvoor je een server inzet. Deze hangt zelfs aan het internet, webserver erop, zelf gecompileerde versie van nginx, statische content. Staat verder compleet afgesloten (ufw).

Hij moet een keer over, maar ik zie momenteel geen noodzaak of risico's.

[mbe81]

Als je weet wat je doet draai je geen out of support besturingssysteem. Niet omdat je geen kennis zou hebben maar omdat je geen security updates meer krijgt en daarmee een potentieel lek hebt.

[Dorank]

Als je weet wat je doet. En dus weet wat de risicos zijn. En de afweging hebt gemaakt. En bv de boel loskoppeld van de grote boze buitenwereld. Hoeft het inderdaad geen probleem te zijn.

BTW dat Debian zelf geen updates meer doorvoerd betekent nog niet dat er geen updates meer beschikbaar zijn. Je bent zelf in staat om patches te maken (lang leve open source), makkelijker is het om backports te maken. Maar je kan dat ook uitbesteden, zie bv https://deb.freexian.com/extended-lts/ als je geluk hebt kost het niets maar anders moet je er wellicht iets voor betalen om anderen te motiveren om werk voor je te verrichten.

[mrmrmr]

Je kunt gerust Windows 95 draaien zonder updates, zonder netwerk en geen dataoverdracht. Maar zelf updates maken lijkt mij toch wel enorm omslachtig en de kwaliteit is onzeker. Dan is het upgraden van de distributie een veel betere optie. Dat is niet zo moeilijk.

[gamezfreak]

En als je weet wat je doet, dan zorg je er voor dat niet alleen je security updates bijna altijd up to date zijn, maar ook de accounts die je gebruikt. In plaats van 1 wachtwoord voor alle accounts, 1 admin / root password die liefst zo lang mogelijk is en nooit wordt gebruikt; en een account waar je als standard user met admin / root previleges hebt. Dus voor je standard user + admin previleges heb je dus 2 wachtwoorden.

Wat betreft het uitstellen van security updates, sommige updates kunnen een grote impact op je systeem / omgeving hebben. Dus is het meestal goed om 1 á 2 weken te wachten, om er zeker voor te zijn dat je omgeving niet uit elkaar valt. Tenzij er een zéér kritische kwetsbaarheid / zero day is, dan liefst zo snel mogelijk patchen.

Een potentieel lek kan grote gevolgen hebben als je server / omgeving vol met belangrijke informatie staat en die informatie absoluut niet gelekt mag worden; we weten immers wel de gevolgen als dat gebeurt

Hoe kritischer je omgeving, hoe beter de security erachter moet zijn om er voor te zorgen dat er zo min mogelijk risico's kunnen zijn.

[sfranken]

n plaats van 1 wachtwoord voor alle accounts, 1 admin / root password die liefst zo lang mogelijk is en nooit wordt gebruikt; en een account waar je als standard user met admin / root previleges hebt. Dus voor je standard user + admin previleges heb je dus 2 wachtwoorden.

Hmm, gewoon je root account disablen en sudo goed configureren. Je reguliere account waar je mee inlogt met een goed wachtwoord wat je eens in de 3 maanden wijzigt (of liever MFA) gebruiken.

[Htbaa]

Hier ook haha. Moest helaas onlangs rebooten. Had een uptime van rond de 670 dagen. En moest onlangs nog een package installeren en was verbaasd dat dit ook nog gewoon ging. In het verleden wel gehad dat deze niet meer konden worden gedownload, maar ik vermoed dat dit toen bij 8.04 was. Ik moest toen in ieder geval de sources handmatig aanpassen, dus was verbaasd dat dat hier niet hoefde.

Overigens heb ik de server onlangs geërfd, dus daar moet binnenkort wat aan gaan gebeuren. Maar draait verder als een zonnetje.

[paradoXical]

Herkenbaar, ik moet een TLS certificaat vernieuwen, maar enkele packages zijn nu toch wel oud. Ik verbaas me er over dat ik zoveel gedownvote word, terwijl ik dit toch stiekem erg vet blijf vinden.

23:59:30 up 1913 days, 17:17, 1 user, load average: 0.00, 0.01, 0.05

[mkools24]

Dat is wel heel lang, die hangt aan een UPS neem ik aan?

[paradoXical]

Draait in een datacenter, blijkbaar hebben ze daar de zaken goed op orde

[Htbaa]

Oh wow dat is nog langer haha. De server die ik heb geërfd heeft maar 1 taak, maar ben nu vannacht toch maar begonnen met upgraden. Snapshot gedraaid en de upgrade naar 14.04 ging goed. Direct door naar 16.04 en dan eventueel later nog een keer naar 18.04. Met 16.04 in ieder geval weer voorzien van security patches, dus ik ga nog even door :-).

[carlpls]

Zou je toe kunnen lichten wat je precies bedoelt? Uiteraard kan je voor een servertje wat thuis draait en niet aan het internet hangt wat minder kritisch over security updates denken. Maar voor een server die wel aan het internet hangt lijkt het mij een heel karwei om constant zelf in de gaten te moeten houden of er nieuwe versies zijn voor de software die je gebruikt en deze of zelf compilen of uit een 3rd party repository te trekken. Waarbij de 3rd party repository eigenlijk een suboptimale manier is wat betreft security. Daarbij kom je uiteindelijk in zo'n grote wirwar van verschillende software packages uit dat je volgensmij beter opnieuw kan beginnen.

[Reactie gewijzigd door carlpls op 23 juli 2024 02:53]

[paradoXical]

Valt mee: een geharde webserver met een minimaal aantal modules, enkel poort 443 (tls), statische content. Beheer via openssh, ip restrictie.

[c-nan]

Dan heb je wel hele oude TLS draaien.

[paradoXical]

Letsencrypt, met moderne settings, gewoon vanaf: https://ssl-config.mozilla.org

[c-nan]

Dat heeft niks met de TLS versie te maken. Je OpenSSL is veelste oud om moderne TLS te draaien.

[paradoXical]

Ik draai een recente versie, OpenSSL zelf compileren is niet bepaald rocketscience, ik ben dat ook niet afhankelijk van wat apt me voorschotelt.. Ik mijn startpost geef ik al direct aan: 'indien je weet wat je doet'.

[Zer0]

Dus je compileert os OpenSSL opnieuw voor een server met alleen statische content... waarschijnlijk had een update/migratie naar een recente OS versie minder moeite gekost...

[paradoXical]

Wat is er mis met je eigen software compileren? Ik compileer vaak software, nginx bijvoorbeeld indien ik een bepaalde module nodig heb. Vaak zijn er dependecies, die ik dan ook dien te compileren (zoals openSSL). Het is echt niet zo dat een willekeurige (kritische) server altijd en zomaar te upgraden is, bijvoorbeeld door procedures, risico's, het niet in huis hebben van expertise, geen budget.

Dan is het wellicht geen best practice, in de realiteit zijn dit zaken die voorkomen. Daarvoor zoek je dan een oplossing.

[Zer0]

Niks mis met zelf compileren, maar waarom veel moeite doen om een verouderd OS veilig te houden op een webserver die alleen statische content biedt...

[c-nan]

Wat is je URL?

[paradoXical]

Op de welbekende SSLabs haal ik een 'A' score, ik maak enkel gebruik van TLS versie 1.2. De URL is privé.

[DJMaze]

Ik begrijp je best. Een server ga je niet upgraden, die migreer je.
En dan maakt het echt niet uit welk OS en waarvoor.
Zo ben ik vorig jaar gemigreerd van CentOS 6 naar CentOS 8, en dat was al problemen genoeg op zichzelf.

[himlims_]

Debian wijzigt je source.list files, gooit er een update/upgrade/distupgrade tegenaan, zie geen rede waarom je moet migreren.. t is geen windows!?

Zo heb ik een bak al 12jr diverse distupgrades doorgemaakt, vlamt nog steeds. Debian is degelijk en solide systeem.

Zoals iemand hierboven schrijft; als weet wat je doet kan eol ook....een risico wat privé en zakelijk niet zou durven nemen. Ook niet met 20jr hippy software ervaring

Updates zijn er niet voor niets!

[Reactie gewijzigd door himlims_ op 23 juli 2024 02:53]

[triflip]

Hangt er net vanaf wat voor server is. Als er kritieke software op draait dan ga je niet zomaar een distrupgrade uitvoeren, zelfs niet als het redundant is uitgevoerd. Dan zet je liever een server neer om naar toe te migreren.

Gaat het om een hobby server dan maakt het allemaal weinig uit, zolang je maar een backup hebt.

Maar zoals je zelf ook zegt een OS draaien dat EOL is gewoon not done. Als het al nodig is dan zorg je ervoor dat de bak op geen manier met het netwerk/internet kan communiceren.

[mkools24]

Zo doe ik het ook, nieuwe ernaast opbouwen en zo migreren. Ik ben niet zo'n fan van in-place upgrades.

[goarilla]

Ik ook alhoewel ik weleens geforceerd werd om het wel te doen: wat ik dan zou doen is het in-place zoveel mogelijk simuleren op een VM totdat ik me klaar genoeg voelde om het in het echt te doen.

[lezzmeister]

Ik heb een thuisserver gewoon omdat. Mocht ik die terug moeten zetten want de boel crasht vanwege upates, dan doe ik dat, prima toch. Niet alsof Schiphol of een ziekenhuis plat gaat. Wel firewalls, raid, cloudbackup, etc, data is wel redelijk veilig denk ik.

[goarilla]

Heb je nooit een HD crash gehad en/of ben je altijd bij hetzelfde filesystem gebleven: ext3 op LVM2 ofzo ?

[pennywiser]

Waarom niet gewoon via 14.04 naar 16.04?

[kcRogue]

naar 14.04 toch zeker. In 16.04 krijg je opeens systemd ipv upstart en dat kan wel wat verouderde init scripts in de war sturen.

[pennywiser]

Let wel 14.04 is ook end of life.

[B38A12A]

Vond 10.04 ook fantastisch, maar die is toch echt uitgefaseerd inmiddels.
Je maakt het jezelf vaak moeilijker door een oude versie in de lucht te houden, dan dat je stap voor stap zaken overzet naar een OS dat nog wel supported is.

[Ludwig005]

Je gaat het steeds moeilijker hebben. Updaten maar naar 20.04, Die release is zeer goed.

[Tr1pke]

als je weet wat je doet dan upgrade je

[m00d]

Het is zeker wel een potentiële issue, ook als je weet wat je doet.

Je bent en blijft een mens- en wij maken nu eenmaal fouten. Je kunt altijd iets vergeten zijn, of toch iets verkeerds doen. Dat kan al jammer zijn op een up to date systeem, maar dat is nog meer risicovol op een verouderde systeem.

Daarbij ben je ook vatbaar voor lekken die Canonical en Linux kernel zelf allang hebben gefixt in nieuwe versies.

En aangezien Ubuntu vergeleken met heel veel andere distros best makkelijk te upgraden is, vind ik dat als je weet wat je doet dat toch echt het minimale is.

[michaelkamen]

Waarom gaat men nu een LTS versie maken van Debian 9, terwijl we al op 10 zitten?

[Icelus]

Elke Debian krijgt drie jaar updates. Daarna valt het automatisch onder het LTS team dat nog twee jaar security updates uitbrengt. Er is dus geen aparte LTS versie.

[pennywiser]

Hier gaat het nog een poosje door:

https://www.freexian.com/services/debian-lts.html

Het lijstje sponsors bestaat oa. het NLse Exonet.

[Comp User]

Is Raspbian niet ook nog op Jessie gebaseerd?

Correctie is inmiddels al over op buster zie ik.

[Reactie gewijzigd door Comp User op 23 juli 2024 02:53]

[sdevos13]

5 jaar gaat snel voorbij.