Linux-kernel kwetsbaar voor denial of service
Beveiligingsonderzoeker Juha-Matti Tilli heeft een kwetsbaarheid in de Linux-kernel ontdekt waardoor een aanvaller bij systemen met een open poort een denial of service kan veroorzaken. Hiervoor moet een aanvaller binnen een lopende tcp-sessie speciaal geprepareerde pakketten versturen.
Deze pakketten kunnen het geheugen van de server zodanig belasten dat er 'resource exhaustion' ontstaat en het systeem traag of onbereikbaar wordt. Om de denial of service te laten voortduren is een two-way tcp-sessie naar een bereikbare open poort vereist. "Dus de aanvallen zijn niet via gespoofte ip-adressen uit te voeren", aldus het CERT Coordination Center (CERT/CC) van de Carnegie Mellon Universiteit. Het probleem is aanwezig in Linux-kernel 4.9 en nieuwer. Het CERT/CC meldt dat er patches beschikbaar zijn om de kwetsbaarheid te verhelpen.
Een kwetsbaarheid, kan gebeuren. Er is al een patch, probleem waarschijnlijk opgelost. Ik wacht nog op een update van de Manjaro kernel, ik draai 4.14 LTS. Heeft ook geen haast voor mij, dit betreft alleen servers, desktops hebben standaard geen poorten open staan.
Kijk.... zo moet het hè? Ik ben toch best trots op die Linux gasten. Er wordt toch altijd weer adequaat gereageerd als er zich een veiligheidsissue voordoet. Die fixes en patches zijn er altijd razendsnel.
Kijk.... zo moet het hè? Ik ben toch best trots op die Linux gasten. Er wordt toch altijd weer adequaat gereageerd als er zich een veiligheidsissue voordoet. Die fixes en patches zijn er altijd razendsnel.
Kijk.... zo moet het hè? Ik ben toch best trots op die Linux gasten. Er wordt toch altijd weer adequaat gereageerd als er zich een veiligheidsissue voordoet. Die fixes en patches zijn er altijd razendsnel.
Patches worden bij Linux nooit zomaar ongetest en automatisch geïnstalleerd bij het opstarten. Geen idee wat Anoniem @03:48 voor Linux systeem heeft. Ik draai Manjaro Linux en heb nog geen patch gezien. Waarom niet? Omdat hij eerst door het Manjaro Team getest wordt voordat hij bij de stabiele updates aangeboden wordt. Daarna beslis ik zelf wanneer ik 'm instaleer. Maar dat is meestal meteen omdat hij al getest is.
Wat ik met anoniem eens ben is dat "Patch Tuesday" compleet achterlijk is en niets te maken heeft met het feit dat updates in een groot bedrijf eerst getest moeten worden voordat ze enterprise wide uitgerold worden. Ja zonder patch tuesday zullen de IT jongetjes meerdere keren per maand updates moeten testen i.p.v. op een vast maandelijks tijdstip na patch tuesday, goed voor ze, dat is hun werk!
Als je iets automatisch laat installeren loop je hoogstens de kans op instabiliteit, niet om gehacked te worden.
En waarom begin je weer over IoT? Voor jou is IoT een synoniem voor Linux maar er zijn ook andere OS voor IoT, dat "geweldige W10" van jou b.v. https://developer.microsoft.com/nl-nl/windows/iot
Als Linux gebaseerde IoT systemen achterlopen met updates is dat puur de schuld van de IoT applicatie ontwikkelaars en niet van Linux.
En waarom begin je weer over IoT? Voor jou is IoT een synoniem voor Linux maar er zijn ook andere OS voor IoT, dat "geweldige W10" van jou b.v. https://developer.microsoft.com/nl-nl/windows/iot
Als Linux gebaseerde IoT systemen achterlopen met updates is dat puur de schuld van de IoT applicatie ontwikkelaars en niet van Linux.
Zoals je aantoont elke vorm wat op kritiek zou kunnen duiden wordt afgedaan als "windows aanhang". Dat brengt geen verbetering, integendeel.
ik kan je uit profesionele ervaring vertellen op bijv CentOS / RHEL dat je de yum update vol automatisch aan kunt zetten via cron dagelijks als je je beperkt tot de nette officiele distro en epel repos en yum protection van die repos gebruikt. In de 20j ervaring heb ik nog geen 'rotte' update ervaren op servers en of op werkstations (>400 en dat zlefs met de meltdown/spectre rotte microcodes fase begin dit jaar van Intel) en hoewel in theorie inderdaad er eens een rotte update voorbij zou kunnen komen, denk ik persoonlijk dat 20j RHVE up to date zijn de resources/fte ballans nu al gunstig maakt als er vannacht ineens op alle servers zo een rotte update binnen zou komen. Maargoed dat is slechts mijn ervaring / risico analyse en die is niet een one size fits all voor iedereen, maar om nu zo uptight over die ene mogelijk rotte update in theorie te doen vind ik dus ook enigsinds overtrokken en heb ervaring en data om die stelling te ondersteunen. ook is een bekende rotte update eenvoudig tegengehouden met bijv yum versionlock danwel een rollback te doen via yum history undo. verschilletje tussen theorie en praktijk ervaring?
En waarom begin je weer over IoT? Voor jou is IoT een synoniem voor Linux maar er zijn ook andere OS voor IoT, dat "geweldige W10" van jou b.v. https://developer.microsoft.com/nl-nl/windows/iot
Als Linux gebaseerde IoT systemen achterlopen met updates is dat puur de schuld van de IoT applicatie ontwikkelaars en niet van Linux.
Zoals je aantoont elke vorm wat op kritiek zou kunnen duiden wordt afgedaan als "windows aanhang". Dat brengt geen verbetering, integendeel.
Alleen in jouw kleine wereldje! De kans dat dit aan jou ligt (bv. door een gebrek aan professioneel overwicht of overtuigingskracht - eigenlijk een beperkt ethos) is véél groter dan de kans dat dit met Linux te maken heeft.
maar het zou toevallig kunnen dat de 'bug' wel in de 3.10 gebackport was door RH.
deze lijkt bijv misschien wel van toepassing:
https://access.redhat.com/security/cve/cve-2018-5391
maar het zou toevallig kunnen dat de 'bug' wel in de 3.10 gebackport was door RH.
deze lijkt bijv misschien wel van toepassing:
https://access.redhat.com/security/cve/cve-2018-5391
correctie https://access.redhat.com/security/cve/cve-2018-5390
Deze posting is gelocked. Reageren is niet meer mogelijk.
Netwerk Security Engineer
Luchtverkeersleiding Nederland
Als Netwerk Security Engineer ontwerp en optimaliseer je onze technische netwerk- en beveiligingsinfrastructuur. Je stuurt tech-nische veranderingen aan op basis van de gestelde architectuur kaders en helpt mee met de uitvoering ervan. Ben jij een gedreven professional met passie voor netwerk-beveiliging? Dan is deze functie als Netwerk Security Engineer bij Luchtverkeersleiding Nederland (LVNL) iets voor jou!
Lead Network Security Engineer
Luchtverkeersleiding Nederland
Word Lead Network Security Engineer bij LVNL. Ontwerp en implementeer security-oplossingen die de luchtverkeersleidings-systemen veilig houden. Solliciteer nu en draag bij aan onze cyberweerbaarheid! Als Lead Network Security Engineer bij LVNL ben je verantwoordelijk voor het ontwerpen, implementeren en optimaliseren van de netwerkbeveiliging die cruciaal is voor de veilige en efficiënte werking van het luchtverkeersleidingssysteem in Nederland.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?