Vraag Opnieuw installeren na een rootcompromis?


Na het lezen deze vraag over een servercompromis, Begon ik me af te vragen waarom mensen nog steeds lijken te geloven dat ze een aangetast systeem kunnen herstellen met behulp van detectie- / opschoonhulpprogramma's, of door gewoon het gat te repareren dat werd gebruikt om het systeem te compromitteren.

Gezien de verschillende rootkit-technologieën en andere dingen die een hacker kan doen, raden de meeste experts aan dat u dit zou moeten doen installeer het besturingssysteem opnieuw.

Ik hoop een beter idee te krijgen waarom meer mensen niet zomaar opstijgen en atoombom het systeem vanuit een baan.

Hier zijn een paar punten die ik graag zou willen zien.

  • Zijn er voorwaarden waar een formaat / herinstallatie het systeem niet zou schoonmaken?
  • Onder welke omstandigheden denk je dat een systeem kan worden schoongemaakt en wanneer moet je een volledige herinstallatie uitvoeren?
  • Welke redenering heeft u tegen een volledige herinstallatie?
  • Als u ervoor kiest om het niet opnieuw te installeren, welke methode gebruikt u dan om er redelijk zeker van te zijn dat u hebt schoongemaakt en dat er geen verdere schade is opgetreden.

56
2018-05-08 09:32


oorsprong




antwoorden:


Een beveiligingsbeslissing is uiteindelijk een zakelijke beslissing over risico's, net als een beslissing over welk product op de markt moet worden gebracht. Wanneer u het in die context raamt, is het zinvol om niet te herconfigureren en opnieuw te installeren. Wanneer je het strikt vanuit een technisch perspectief bekijkt, doet het dat niet.

Dit is wat gewoonlijk in die zakelijke beslissing wordt opgenomen:

  • Hoeveel kost onze downtime ons in een meetbare hoeveelheid?
  • Hoeveel kost het ons mogelijk als we een beetje aan klanten moeten onthullen waarom we down waren?
  • Voor welke andere activiteiten moet ik mensen weghalen om de herinstallatie uit te voeren? Wat zijn de kosten?
  • Hebben we de juiste mensen die weten hoe het systeem zonder fouten moet worden opgeroepen? Zo nee, wat gaat het mij kosten als ze bugs oplossen?

En daarom, wanneer u de kosten zoals die optelt, kan worden aangenomen dat doorgaan met een "potentieel" nog steeds aangetast systeem beter is dan het opnieuw installeren van het systeem.


30
2018-05-08 09:58



Neem alstublieft de tijd en lees het uitstekende bericht van Richard Bejtlich over "Goedkope IT is uiteindelijk duur" Op te sommen, "Het is niet goedkoper om gecompromitteerde systemen binnen de onderneming te laten werken vanwege de" productiviteitsslag "die wordt genomen wanneer een systeem moet worden onderbroken om veiligheidsanalyse mogelijk te maken." - Josh Brower
Ik heb hier een tijdje over nagedacht en kan geen reden bedenken waarom het logischer zou zijn om een ​​systeem in te zetten dat waarschijnlijk in gevaar wordt gebracht. - duffbeer703
Ik zou een systeem waarvan ik weet dat het is aangetast, ook niet willen inzetten of online willen houden. Maar dit ben ik als een technicus. En ik ben het hier niet mee eens, omdat hoewel hij zegt een verliespreventie-oefening is, het bedrijf het niet als zodanig behandelt. Business bekijkt het vanuit een risicoperspectief, en terecht. Ze kunnen bijvoorbeeld op een verzekering rekenen om hen te dekken in het geval van een rechtszaak en dat is hoe ze omgaan met het risico. En Richard weegt dit niet in zijn argument. Ik heb niet gezegd dat ik het eens ben met dit denken, maar zo begrijp je het, en dat vroeg het OP. - K. Brian Kelley
Ik ben het tot op zekere hoogte ook oneens met Bejtilich, maar laat me in ieder geval zijn laatste opmerking citeren, want het voegt een andere dimensie toe aan deze discussie: het "meten" van het risico is een grap. Het meten van verlies is meestal onmogelijk. (Vertel me hoeveel je verliest wanneer een concurrent je gegevens steelt om zijn producten in de komende 10 jaar te verbeteren) Het meten van de kosten is de oefening die het meest waarschijnlijk betrouwbare resultaten oplevert, omdat je geld kunt volgen dat het bedrijf verlaat. Gemeten kosten is waar ik naar refereer in deze post. Ik zou graag verliezen willen meten, maar het zal geen echte cijfers opleveren. Het meten van risico is een gigantische gok. " - Josh Brower
... en toch zijn onze hele verzekeringssector en het systeem van de burgerlijke rechtbank gebaseerd op het meten van risico's en het in dollars zetten van verliezen. Dus blijkbaar die benadering is aanvaardbaar voor de verantwoordelijke personen. - Brian Knoblauch


Gebaseerd op een bericht I schreef eeuwen geleden toen ik nog steeds de moeite had om te bloggen.

Deze vraag blijft herhaaldelijk gesteld door de slachtoffers van hackers die inbraken op hun webserver. De antwoorden veranderen zelden, maar mensen blijven de vraag stellen. Ik weet niet zeker waarom. Misschien houden mensen gewoon niet van de antwoorden die ze hebben gezien bij het zoeken naar hulp, of ze kunnen iemand die ze vertrouwen niet vinden om hen advies te geven. Of misschien lezen mensen een antwoord op deze vraag en concentreren ze zich teveel op de 5% waarom hun geval speciaal is en verschillen van de antwoorden die ze online kunnen vinden en missen ze de 95% van de vraag en het antwoord waar hun zaak bijna in de buurt is als degene die ze online lezen.

Dat brengt me bij de eerste belangrijke nugget van informatie. Ik waardeer het echt dat je een speciale unieke sneeuwvlok bent. Ik waardeer dat uw website ook is, omdat het een weerspiegeling is van u en uw bedrijf of op zijn minst uw harde werk voor rekening van een werkgever. Maar als iemand aan de buitenkant kijkt, of een computerbeveiligingsspecialist die naar het probleem kijkt om u te helpen of zelfs de aanvaller zelf, is het zeer waarschijnlijk dat uw probleem minstens 95% identiek is aan elk ander geval dat zij hebben ooit bekeken.

Neem de aanval niet persoonlijk en neem de aanbevelingen die hier volgen of die u persoonlijk van anderen krijgt niet. Als je dit leest nadat je het slachtoffer bent geworden van een website-hack, vind ik het echt jammer en ik hoop echt dat je hier iets nuttigs kunt vinden, maar dit is niet het moment om je ego in de weg te laten zitten van wat je nodig hebt om do.

U hebt net ontdekt dat uw server (s) is gehackt. Wat nu?

Raak niet in paniek. Doe absoluut geen haast en probeer absoluut niet te doen alsof dingen nooit zijn gebeurd en helemaal niet handelen.

Ten eerste: begrijp dat de ramp al is gebeurd. Dit is niet het moment voor ontkenning; het is de tijd om te accepteren wat er is gebeurd, er realistisch over te zijn en stappen te ondernemen om de gevolgen van de impact te beheersen.

Sommige van deze stappen zullen pijn doen en (tenzij je website een kopie van mijn gegevens heeft), maakt het me echt niet uit als je alle of sommige van deze stappen negeert, maar als je dit doet, verbeter je het uiteindelijk. Het medicijn kan vreselijk smaken, maar soms moet je dat over het hoofd zien als je echt wilt dat de kuur werkt.

Zorg dat het probleem niet erger wordt dan het al is:

  1. Het eerste dat u moet doen, is de betreffende systemen loskoppelen van internet. Welke andere problemen u ook hebt, waardoor het systeem verbonden blijft met internet, zorgt ervoor dat de aanval door kan gaan. Ik bedoel dit vrij letterlijk; laat iemand de server fysiek bezoeken en netwerkkabels loskoppelen als dat is wat nodig is, maar koppel het slachtoffer los van de overvallers voordat u iets anders probeert te doen.
  2. Wijzig al uw wachtwoorden voor alle accounts op alle computers die zich in hetzelfde netwerk bevinden als de besmette systemen. Nee echt. Alle accounts. Alle computers. Ja, je hebt gelijk, dit kan overdreven zijn; aan de andere kant, misschien niet. Je weet geen van beide, toch?
  3. Controleer uw andere systemen. Besteed speciale aandacht aan andere op het internet gerichte services en aan die welke financiële of andere commercieel gevoelige gegevens bevatten.
  4. Als het systeem iemands persoonlijke gegevens bevat, maak dan een volledige en openhartige melding aan iedereen die mogelijk in een keer wordt getroffen. Ik weet dat deze zwaar is. Ik weet dat deze pijn gaat doen. Ik weet dat veel bedrijven dit soort problemen onder het tapijt willen vegen, maar ik ben bang dat je er gewoon mee te maken zult krijgen.

Nog steeds aarzelen om deze laatste stap te zetten? Ik begrijp het, ik begrijp het. Maar kijk er als volgt naar:

Op sommige plaatsen is het mogelijk wettelijk verplicht om de autoriteiten en / of de slachtoffers te informeren over dit soort privacyschending. Hoe geïrriteerd uw klanten ook zijn om u te laten vertellen over een probleem, ze zullen veel meer geïrriteerd zijn als u het ze niet vertelt, en zij ontdekken het pas nadat iemand $ 8.000 aan goederen heeft gerekend met behulp van de creditcardgegevens die zij heeft gestolen van uw site.

Weet je nog wat ik eerder zei? Het slechte is al gebeurd. De enige vraag is nu hoe goed je ermee omgaat.

Begrijp het probleem volledig:

  1. Plaats de betreffende systemen NIET online totdat deze fase volledig is voltooid, tenzij je de persoon wilt zijn wiens bericht het omslagpunt was voor mij, toen ik besloot dit artikel te schrijven. Ik link niet naar de post zodat mensen goedkoop kunnen lachen; Ik koppel om je te waarschuwen voor de gevolgen van het niet volgen van deze eerste stap.
  2. Bestudeer de 'aangevallen' systemen om te begrijpen hoe de aanvallen erin slaagden om uw veiligheid in gevaar te brengen. Doe alles om te achterhalen waar de aanvallen "vandaan kwamen", zodat u begrijpt welke problemen u hebt en moet aanpakken om uw systeem in de toekomst te beveiligen.
  3. Onderzoek de 'aangevallen' systemen opnieuw, deze keer om te begrijpen waar de aanvallen zijn gegaan, zodat je begrijpt welke systemen tijdens de aanval zijn aangetast. Zorg ervoor dat u eventuele aanwijzingen opvolgt die suggereren dat besmette systemen een springplank kunnen worden om uw systemen verder aan te vallen.
  4. Zorg ervoor dat de "gateways" die bij alle aanvallen worden gebruikt, volledig worden begrepen, zodat u ze op de juiste manier kunt sluiten. (bijvoorbeeld als uw systemen zijn aangetast door een SQL-injectieaanval, dan moet u niet alleen de specifieke code met fouten die ze hebben ingesloten, sluiten, u wilt ook al uw code controleren om te zien of hetzelfde soort fout is werd elders gemaakt).
  5. Begrijp dat aanvallen kunnen slagen vanwege meer dan één fout. Vaak slagen aanvallen er niet in één grote bug in een systeem te vinden, maar door verschillende problemen (soms klein en triviaal op zichzelf) samen te brengen om een ​​systeem in gevaar te brengen. Als u bijvoorbeeld SQL-injectie-aanvallen gebruikt om opdrachten naar een databaseserver te verzenden, wordt het ontdekken van de website / applicatie die u aanvalt, uitgevoerd in de context van een administratieve gebruiker en worden de rechten van dat account gebruikt als opstap om andere delen van een systeem. Of zoals hackers het graag noemen: "nog een dag op kantoor om misbruik te maken van veelvoorkomende fouten die mensen maken".

Maak een herstelplan en breng uw website weer online en houd u eraan:

Niemand wil langer offline zijn dan nodig is. Dat is een gegeven. Als deze website een inkomstengenererend mechanisme is, zal de druk om het snel weer online te brengen, groot zijn. Zelfs als het enige dat op het spel staat de reputatie van je / je bedrijf is, gaat dit nog steeds veel druk genereren om dingen snel weer op te bouwen.

Geef echter niet toe aan de verleiding om te snel weer online te gaan. Verplaats in plaats daarvan zo snel mogelijk om te begrijpen waardoor het probleem is veroorzaakt en om het op te lossen voordat je weer online gaat, anders word je bijna zeker het slachtoffer van een inbraak en onthoud je dat "een keer gehackt worden als ongeluk kan worden beschouwd; om daarna weer gehackt te worden, ziet eruit als onvoorzichtigheid "(excuses aan Oscar Wilde).

  1. Ik neem aan dat je alle problemen hebt begrepen die hebben geleid tot de succesvolle inbraak in de eerste plaats voordat je deze sectie zelfs maar start. Ik wil de zaak niet overdrijven, maar als je dat nog niet eerder hebt gedaan, moet je dat echt doen. Sorry.
  2. Betaal nooit chantage / beschermingsgeld. Dit is het teken van een gemakkelijke markering en je wilt niet dat die uitdrukking ooit wordt gebruikt om je te beschrijven.
  3. Laat u niet verleiden om dezelfde server (s) weer online te zetten zonder een volledige herbouw. Het zou veel sneller moeten zijn om een ​​nieuwe doos te bouwen of de server "uit de omloop te halen en een schone installatie uit te voeren" op de oude hardware dan om elke hoek van het oude systeem te controleren om ervoor te zorgen dat het schoon is voordat het terug wordt geplaatst online opnieuw. Als je het daar niet mee eens bent, weet je waarschijnlijk niet wat het werkelijk betekent om ervoor te zorgen dat een systeem volledig wordt schoongemaakt, of de procedures voor de implementatie van je website zijn een onheilspellende puinhoop. U hebt waarschijnlijk back-ups en testimplementaties van uw site die u gewoon kunt gebruiken om de live site te bouwen en als u dat niet doet, is het niet uw grootste probleem om gehackt te worden.
  4. Wees zeer voorzichtig met het hergebruiken van gegevens die op het moment van de hack "live" waren op het systeem. Ik zal niet zeggen "doe het nooit" omdat je me gewoon negeert, maar eerlijk gezegd denk ik dat je de gevolgen van het bijhouden van gegevens moet overdenken als je weet dat je de integriteit ervan niet kunt garanderen. In het ideale geval zou u dit moeten herstellen van een back-up gemaakt voorafgaand aan de inbraak. Als je dat niet kunt of wilt doen, moet je heel voorzichtig zijn met die gegevens omdat het besmet is. U moet vooral op de hoogte zijn van de gevolgen voor anderen als deze gegevens eigendom zijn van klanten of bezoekers van de site in plaats van rechtstreeks aan u.
  5. Controleer het systeem / de systemen zorgvuldig. U moet besluiten dit als een doorlopend proces in de toekomst te doen (meer hieronder), maar u neemt extra inspanningen om waakzaam te zijn gedurende de periode onmiddellijk volgend op uw site die weer online komt. De indringers zullen bijna zeker terugkomen, en als je ze kunt zien proberen opnieuw in te breken, zul je zeker in staat zijn om snel te zien of je echt alle gaten die ze eerder hebben gebruikt plus ze hebben gemaakt voor jezelf, en je zou nuttig kunnen verzamelen informatie die u kunt doorgeven aan uw lokale rechtshandhavingsinstantie.

Het risico in de toekomst verminderen.

Het eerste dat je moet begrijpen, is dat beveiliging een proces is dat je moet toepassen gedurende de hele levenscyclus van het ontwerpen, implementeren en onderhouden van een internetgericht systeem, niet iets dat je achteraf als het ware een paar lagen over je code kunt slaan. verf. Om goed beveiligd te zijn, moeten een dienst en een applicatie vanaf het begin worden ontworpen met dit in gedachten als een van de belangrijkste doelen van het project. Ik realiseer me dat dat saai is en je hebt het allemaal al eerder gehoord en dat ik "de drukte man" niet realiseer om jouw beta web2.0 (bèta) -service in bètastatus op het web te krijgen, maar het feit is dat dit blijft herhaald worden omdat het waar was de eerste keer dat het werd gezegd en het is nog geen leugen geworden.

Je kunt het risico niet elimineren. Je zou zelfs niet moeten proberen dat te doen. Wat u echter wel moet doen, is begrijpen welke beveiligingsrisico's voor u belangrijk zijn en begrijpen hoe u beide kunt beheren en verminderen impact van het risico en de waarschijnlijkheiddat het risico zal optreden.

Welke stappen kunt u nemen om de kans te verkleinen dat een aanval succesvol is?

Bijvoorbeeld:

  1. Was de fout die mensen toestond om op uw site in te breken een bekende fout in leverancierscode, waarvoor een patch beschikbaar was? Als dat zo is, moet u dan opnieuw nadenken over uw aanpak van het patchen van toepassingen op uw internetservers?
  2. Was de fout die mensen toestond om op uw site in te breken een onbekende fout in leverancierscode, waarvoor een patch niet beschikbaar was? Ik ben zeker niet voorstander van het veranderen van leverancier wanneer iets als dit je bijt omdat ze allemaal hun problemen hebben en je binnen een jaar maximaal geen platforms meer hebt als je deze aanpak kiest. Als een systeem u echter voortdurend in de steek laat, moet u ofwel migreren naar iets robuuster of op zijn minst uw systeem opnieuw ontwerpen, zodat kwetsbare componenten in watten worden gewikkeld en zo ver mogelijk weg van vijandige ogen.
  3. Was de fout een fout in de door u ontwikkelde code (of een aannemer die voor u werkte)? Als dat het geval is, moet u dan opnieuw nadenken over hoe u de code goedkeurt voor implementatie op uw live site? Is de bug gevangen met een verbeterd testsysteem of met wijzigingen in uw coderingsnorm (bijvoorbeeld, terwijl technologie geen wondermiddel is, kunt u de kans op een geslaagde SQL-injectie-aanval verminderen door goed gedocumenteerde coderingstechnieken te gebruiken ).
  4. Was de fout te wijten aan een probleem met de implementatie van de server of toepassingssoftware? Als dat zo is, gebruikt u dan geautomatiseerde procedures om servers te bouwen en waar mogelijk te implementeren? Deze zijn een grote hulp bij het handhaven van een consistente "baseline" -status op al uw servers, waardoor de hoeveelheid aangepast werk die op elke server moet worden gedaan wordt geminimaliseerd en waardoor hopelijk de kans op een fout wordt geminimaliseerd. Hetzelfde geldt voor de inzet van code - als u iets "speciaal" wilt doen om de nieuwste versie van uw web-app te implementeren, probeer dan hard om het te automatiseren en zorg ervoor dat het altijd op een consistente manier gebeurt.
  5. Is de inbraak eerder betrapt met betere bewaking van uw systemen? Natuurlijk is 24-uurs bewaking of een "oproepbaar" -systeem voor uw personeel mogelijk niet rendabel, maar er zijn bedrijven die uw web-gerichte services voor u kunnen controleren en u kunnen waarschuwen als zich een probleem voordoet. Je zou kunnen besluiten dat je dit niet kunt betalen of het niet nodig hebt en dat is prima, neem het gewoon in overweging.
  6. Gebruik waar nodig tools zoals tripwire en nessus - maar gebruik ze niet blindelings, omdat ik het zeg. Neem de tijd om te leren hoe u enkele goede beveiligingshulpmiddelen gebruikt die geschikt zijn voor uw omgeving, houd deze hulpprogramma's bij en gebruik ze regelmatig.
  7. Overweeg beveiligingsdeskundigen in te huren om uw websitebeveiliging regelmatig te 'auditen'. Nogmaals, je zou kunnen beslissen dat je dit niet kunt betalen of het niet nodig hebt en dat is prima, neem het gewoon in overweging.

Welke stappen kunt u nemen om de gevolgen van een geslaagde aanval te verminderen?

Als je besluit dat het "risico" van de benedenverdieping van je woningoverstroming hoog is, maar niet hoog genoeg om bewegen te rechtvaardigen, moet je op zijn minst de onvervangbare familietradities verplaatsen naar boven. Rechts?

  1. Kunt u het aantal services verminderen dat rechtstreeks wordt blootgesteld aan internet? Kun je een kloof overbruggen tussen je interne diensten en je op internet gerichte diensten? Dit zorgt ervoor dat, zelfs als uw externe systemen worden aangetast, de kansen om dit te gebruiken als springplank om uw interne systemen aan te vallen, beperkt zijn.
  2. Bewaart u informatie die u niet hoeft op te slaan? Bewaar je dergelijke informatie 'online' wanneer deze ergens anders kan worden gearchiveerd? Er zijn twee punten aan dit onderdeel; het voor de hand liggende is dat mensen geen informatie van u kunnen stelen die u niet hebt, en het tweede punt is dat hoe minder u opslaat, hoe minder u hoeft te onderhouden en te coderen, en dus er minder kans is dat bugs mislopen uw code of systeemontwerp.
  3. Gebruikt u de "least access" -principes voor uw web-app? Als gebruikers alleen uit een database hoeven te lezen, zorg er dan voor dat het account dat de web-app gebruikt voor service, alleen leestoegang heeft, schrijftoegang niet toestaat en zeker geen toegang op systeemniveau.
  4. Als u niet erg ervaren bent in iets en het niet centraal staat in uw bedrijf, overweeg dan om het uit te besteden. Met andere woorden: als u een kleine website draait over het schrijven van de desktoptoepassingscode en besluit om kleine desktoptoepassingen vanaf de site te verkopen, overweeg dan om uw creditcardbestelsysteem uit te besteden aan iemand als Paypal.
  5. Maak, indien mogelijk, het uitvoeren van herstel van besmette systemen onderdeel van uw Rampenherstelplan. Dit is aantoonbaar gewoon een ander "rampscenario" dat je zou kunnen tegenkomen, gewoon eentje met een eigen reeks problemen en problemen die anders zijn dan de gebruikelijke 'serverruimte gevangen' / 'werd binnengevallen door gigantische server-eat-furbies'. (bewerken, per XTZ)

... En tenslotte

Ik heb waarschijnlijk geen einde gemaakt aan dingen die anderen belangrijk vinden, maar de bovenstaande stappen moeten je op zijn minst helpen om dingen uit te zoeken als je de pech hebt om het slachtoffer te worden van hackers.

Bovenal: geen paniek. Denk na voordat je iets doet. Handel goed nadat u een beslissing hebt genomen en laat een opmerking achter als u iets toe te voegen heeft aan mijn lijst met stappen.


28
2018-06-14 21:00



+1, erg leuk, erg uitgebreid. - Avery Payne
Bedankt Avery, ik weet niet zeker of je foto niet veel veel sneller zegt, maar ik heb geen stemmen meer! - Rob Moir
Ik zou willen dat SF de mogelijkheid zou hebben om antwoorden als favorieten te markeren. Het lijkt er ook op dat er veel antwoorden zijn die ik heb gezien en die ik graag zou willen doorgeven of dat ik een cross-posting zou moeten plaatsen. Hoe dan ook, ik ben een fan van gedegen antwoorden - je kunt beter alles weten in plaats van er slechts een deel van te kennen. - Avery Payne
Eén ding dat je moet toevoegen, MAAK DIT EEN DEEL VAN JE DR PLAN !!! Kleine bedrijven hebben misschien maar een paar servers, dit moet worden bedacht voordat het gebeurt, alles wat je kunt doen als het doet is isoleren, evalueren, nuke, herbouwen. - XTZ
Leuke XTZ, die op de lijst staat. - Rob Moir


Altijd vernietig het uit een baan. Het is de enige manier om zeker te zijn.

alt text

De meeste systemen zijn holistische entiteiten die een innerlijk, impliciet vertrouwen hebben. Vertrouwen op een gecompromitteerd systeem is een impliciete verklaring dat je vertrouwt op degene die de inbreuk op je systeem deed om mee te beginnen. Met andere woorden:

Je kunt het niet vertrouwen. Doe geen moeite met schoonmaken. Koppel de machine los en isoleer hem onmiddellijk. Begrijp de aard van de overtreding voordat je verder gaat, anders nodig je hetzelfde opnieuw uit. Probeer, indien mogelijk, de datum en het tijdstip van de overtreding op te geven, zodat je een referentiekader hebt. U hebt dit nodig, want als u de back-up herstelt, moet u er zeker van zijn dat de back-up zelf geen kopie van het compromis bevat. Veeg voordat je herstelt - neem geen snelkoppelingen.


18
2018-06-14 20:50





Praktisch gezien doen de meeste mensen het niet omdat ze denken dat het te lang zal duren of te storend zal zijn. Ik heb talloze klanten geadviseerd over de kans op aanhoudende problemen, maar een herinstallatie wordt vaak door een beslissingsmaker om een ​​van die redenen neergeschoten.

Dat gezegd hebbende, op systemen waarvan ik zeker weet dat ik de invoermethode en de volledige omvang van de schade ken (vaste off-machine logs, meestal met een IDS, misschien SELinux of iets dergelijks dat de reikwijdte van de indringing beperkt), een opruiming gedaan hebben zonder opnieuw te installeren zonder je schuldig te voelen.


5
2018-05-08 09:40





Hoogstwaarschijnlijk hebben ze geen noodherstelroutine die genoeg is getest om zeker te zijn van een heropbouw, of het is onduidelijk hoe lang het zou duren of wat de impact zou zijn ... of back-ups zijn onbetrouwbaar of hun risicoanalisten begrijp de omvang van een gecompromitteerd systeem niet. Ik kan veel redenen bedenken.

Ik zou zeggen dat het vooral iets mis is in de basisroutines en het beleid en dat is niet iets dat je openlijk zou willen toegeven - en in plaats daarvan neem je een defensieve houding aan. Ik kan in ieder geval niet zien of verdedigen als ik een gecompromitteerd systeem niet afveeg, ongeacht in welke hoek je het bekijkt.


2
2018-05-08 09:59





Ik heb eerder het systeem niet nuked zodat ik een analyse kan maken van de vector waar ze op zijn gekomen en de daaropvolgende anaylysis van het gebruik en om te zien waar ze binnen kwamen.

Als je eenmaal bent geroot - je hebt een live honeypot en het kan veel meer bieden dan alleen de hack. - speciaal voor de politie.

  • dat zei dat ik in de voorhoede was om in staat te zijn om een ​​schoon systeem op stand-by te zetten en om snel verbeterde netwerkbeveiliging te kunnen bieden om de gerootte box te isoleren.

2
2018-05-08 11:16