Ursprungligen från serverfel. Tack till Robert Moir (RobM)

Det är svårt att ge specifika råd från vad du har lagt upp här men jag har några generiska råd baserat på ett inlägg som jag skrev för evigt sedan när jag fortfarande kunde bry mig om att blogga.

Don't Panic

Först och främst, det finns inga "snabbkorrigeringar" förutom att återställa ditt system från en säkerhetskopia som tagits före intrånget, och detta har minst två problem.

1. Det är svårt för att hitta när intrånget inträffade.
2. Det hjälper dig inte att stänga "hålet" som gjorde det möjligt för dem att bryta in förra gången eller hantera konsekvenserna av "datastöld" som också kan ha tagit plats.

Denna fråga ställs ständigt upprepade gånger av offren för hackare som bryter sig in på deras webbserver. Svaren förändras mycket sällan, men folk ställer ständigt frågan. Jag är inte säker på varför. Kanske gillar folk inte svaren de har sett när de söker efter hjälp, eller så kan de inte hitta någon de litar på för att ge dem råd. Eller kanske människor läser ett svar på den här frågan och fokuserar för mycket på de 5% av varför deras fall är speciella och skiljer sig från svaren de kan hitta online och saknar 95% av frågan och svaret där deras fall är nära nog samma som den de läser online.

Det leder mig till den första viktiga informationen. Jag uppskattar verkligen att du är en speciell unik snöflinga. Jag uppskattar att din webbplats också är, eftersom den återspeglar dig och ditt företag eller åtminstone ditt hårda arbete för en arbetsgivares räkning. Men för någon på utsidan som tittar in, oavsett om en datasäkerhetsperson som tittar på problemet för att försöka hjälpa dig eller till och med angriparen själv, är det mycket troligt att ditt problem kommer att vara minst 95% identiskt med alla andra fall de har någonsin tittat på.

Ta inte attacken personligt och ta inte personligen de rekommendationer som följer här eller som du får från andra människor. Om du läser detta efter att bara ha blivit offer för en webbplatshack så är jag verkligen ledsen, och jag hoppas verkligen att du kan hitta något användbart här, men det är inte dags att låta ditt ego komma i vägen för vad du behöver gör det.

Du har precis fått reda på att din server har hackats. Vad nu?

Var inte panik. Handla absolut inte i bråttom, och försök absolut inte att låtsas att saker aldrig har hänt och inte alls.

Först: förstå att katastrofen redan har hänt. Det är inte dags för förnekelse; det är dags att acceptera vad som har hänt, att vara realistisk och att vidta åtgärder för att hantera konsekvenserna av påverkan.

Några av dessa steg kommer att skada, och (om inte din webbplats innehåller en kopia av mina uppgifter) Jag bryr mig verkligen inte om du ignorerar alla eller några av dessa steg, men om du gör det kommer det att bli bättre i slutändan. Läkemedlet kan smaka hemskt men ibland måste du förbise det om du verkligen vill att botemedlet ska fungera.

Stoppa problemet från att bli värre än det redan är:

1. det första du bör göra är att koppla bort de drabbade systemen från Internet. Oavsett vilka andra problem du har, om du lämnar systemet anslutet till webben kan bara attacken fortsätta. Jag menar detta bokstavligen; få någon att besöka servern fysiskt och koppla bort nätverkskablar om det är vad som krävs, men koppla bort offret från mugggarna innan du försöker göra något annat.
2. Ändra alla dina lösenord för alla konton på alla datorer som är i samma nätverk som de komprometterade systemen. Nej verkligen. Alla konton. Alla datorer. Ja, du har rätt, det här kan vara överdrivet; å andra sidan kanske det inte. Du vet inte hur som helst, eller hur?
3. Kontrollera dina andra system. Var särskilt uppmärksam på andra tjänster som Internet står inför och till de som har finansiell eller annan kommersiellt känslig information.
4. Om systemet innehåller någons personuppgifter, informera omedelbart den person som är ansvarig för dataskyddet (om det inte är du) och URGE en fullständig information. Jag vet att den här är tuff. Jag vet att den här kommer att göra ont. Jag vet att många företag vill sopa denna typ av problem under mattan, men verksamheten kommer att behöva hantera det - och måste göra det med ett öga på alla relevanta sekretesslagar.
ol >

Hur irriterade dina kunder kan vara att låta dig berätta för dem om ett problem, de kommer att bli mycket mer irriterade om du inte berättar för dem, och de får bara reda på det själva efter att någon har debiterat 8 000 dollar i varor med hjälp av kreditkortsuppgifter som de stal från din webbplats.

Kommer du ihåg vad jag sa tidigare? Det dåliga har redan hänt. Den enda frågan nu är hur bra du hanterar det.

Förstå problemet helt:

1. Sätt INTE de drabbade systemen tillbaka online förrän det här steget är helt klart, såvida du inte vill vara den person vars inlägg var tipppunkten för att jag faktiskt bestämde mig för att skriva den här artikeln. Jag kommer inte att länka till det inlägget så att människor kan få ett billigt skratt, men den verkliga tragedin är när människor inte lär sig av sina misstag.
2. Undersök de "attackerade" systemen för att förstå hur attacker lyckades äventyra din säkerhet. Ansträng dig för att ta reda på var attackerna "kom ifrån" så att du förstår vilka problem du har och behöver ta itu med för att göra ditt system säkert i framtiden.
3. Undersök de "attackerade" systemen igen, den här gången för att förstå var attackerna gick, så att du förstår vilka system som komprometterades i attacken. Se till att du följer upp några pekare som föreslår att komprometterade system kan bli en språngbräda för att attackera dina system ytterligare.
4. Se till att "gateways" som används i alla attacker är fullständigt förstådda, så att du kan börja stänga dem ordentligt. (t.ex. om dina system komprometteras av en SQL-injektionsattack, behöver du inte bara stänga den specifika felaktiga kodraden som de bröt in genom, du skulle vilja granska all din kod för att se om samma typ av misstag gjordes någon annanstans).
5. Förstå att attacker kan lyckas på grund av mer än en brist. Ofta lyckas attacker inte genom att hitta en större bugg i ett system utan genom att stränga ihop flera problem (ibland mindre och triviala i sig) för att kompromissa med ett system. Om du till exempel använder SQL-injektionsattacker för att skicka kommandon till en databasserver, upptäcker webbplatsen / applikationen du attackerar i samband med en administrativ användare och använder rättigheterna för det kontot som en språngbräda för att kompromissa med andra delar av ett system. Eller som hackare vill kalla det: "en annan dag på kontoret som utnyttjar vanliga misstag som människor gör".

Varför inte bara "reparera" den exploatering eller rootkit du har upptäckt och sätta tillbaka systemet online?

I sådana situationer är problemet att du inte längre har kontroll över systemet. Det är inte din dator längre.

Det enda sättet att vara säker på att du har kontroll över systemet är att bygga om systemet. Även om det finns mycket värde i att hitta och fixa det utnyttjande som används för att bryta sig in i systemet, kan du inte vara säker på vad mer har gjorts med systemet när inkräktarna fått kontroll (det är faktiskt inte okänt för hackare som rekryterar system i ett botnet för att korrigera de exploater de själva använde, för att skydda "deras" nya dator från andra hackare samt installera deras rootkit).

Gör en plan för återhämtning och ta med din webbplatsen tillbaka online och håll dig till den:

Ingen vill vara offline längre än vad de behöver vara. Det är givet. Om den här webbplatsen är en inkomstgenererande mekanism kommer trycket att snabbt ta tillbaka den online att bli intensivt. Även om det enda som står på spel är ditt / ditt företags rykte, kommer det fortfarande att generera mycket tryck för att snabbt sätta upp saker igen.

Men ge inte efter för frestelsen att gå tillbaka online för snabbt. Rör dig istället så fort som möjligt för att förstå vad som orsakade problemet och för att lösa det innan du går tillbaka online, annars kommer du nästan säkert att bli offer för ett intrång igen och kom ihåg, "att bli hackad en gång kan klassas som olycka; att bli hackad igen direkt efteråt ser ut som slarv "" (med ursäkter till Oscar Wilde).

1. Jag antar att du förstår alla frågor som ledde till framgångsrikt intrång i första hand före dig starta till och med det här avsnittet. Jag vill inte överdriva ärendet, men om du inte har gjort det först måste du verkligen. Tyvärr.
2. Betala aldrig utpressning / skyddspengar. Detta är ett tecken på ett enkelt märke och du vill inte att den frasen någonsin används för att beskriva dig.
3. Låt dig inte frestas att sätta tillbaka samma server (er) online utan en fullständig ombyggnad. Det borde vara mycket snabbare att bygga en ny ruta eller "nocka servern från omloppsbana och göra en ren installation" på den gamla hårdvaran än det skulle vara att granska varje enskilt hörn i det gamla systemet för att se till att det är rent innan du sätter tillbaka det online igen. Om du inte håller med det vet du förmodligen inte vad det egentligen innebär att se till att ett system är helt städat, eller att dina webbplatsdistributionsprocedurer är en ohelig röra. Du har förmodligen säkerhetskopior och testdistributioner av din webbplats som du bara kan använda för att bygga den levande webbplatsen, och om du inte gör det är inte ditt hacka ditt största problem.
4. Var mycket försiktig med att återanvända data som var "live" i systemet vid hackningstidpunkten. Jag kommer inte att säga "aldrig någonsin göra det" eftersom du bara ignorerar mig, men uppriktigt sagt tror jag att du måste överväga konsekvenserna av att hålla data kvar när du vet att du inte kan garantera dess integritet. Helst bör du återställa detta från en säkerhetskopia som gjorts före intrånget. Om du inte kan eller inte gör det bör du vara mycket försiktig med den informationen eftersom den är smutsad. Du bör särskilt vara medveten om konsekvenserna för andra om dessa uppgifter tillhör kunder eller webbplatsbesökare snarare än direkt till dig.
5. Övervaka systemet noggrant. Du bör bestämma dig för att göra detta som en pågående process i framtiden (mer nedan) men du tar extra ansträngningar för att vara vaksam under perioden direkt efter att din webbplats kommer tillbaka online. Inkräktarna kommer nästan säkert att vara tillbaka, och om du kan se dem försöka bryta in igen kommer du säkert att kunna se snabbt om du verkligen har stängt alla hål de använde tidigare plus alla de gjorde för sig själva, och du kan samla användbara information som du kan vidarebefordra till din lokala brottsbekämpning.

---

Minska risken i framtiden.

Det första du måste förstå är att säkerhet är en process som du måste tillämpa under hela livscykeln för att designa, distribuera och underhålla ett Internet-riktat system, inte något du kan slå några lager över din kod efteråt som billig färg. För att vara ordentligt säker måste en tjänst och en applikation utformas från början med detta i åtanke som ett av de viktigaste målen för projektet. Jag inser att det är tråkigt och du har hört allt förut och att jag "bara inte inser trycket mannen" att få din beta web2.0 (beta) -tjänst till beta-status på webben, men faktum är att detta håller blir upprepad eftersom det var sant första gången det sa och det har ännu inte blivit en lögn.

Du kan inte eliminera risken. Du ska inte ens försöka göra det. Vad du bör göra är dock att förstå vilka säkerhetsrisker som är viktiga för dig och förstå hur man hanterar och minskar både riskens påverkan och sannolikheten för att risken uppstår.

Vilka steg kan du göra för att minska sannolikheten för att en attack lyckas?

Till exempel:

1. Var det fel som gjorde att människor kunde bryta sig in på din webbplats en känd fel i leverantörskod, för vilken en patch var tillgänglig? Om så är fallet, måste du tänka om din inställning till hur du lappar applikationer på dina Internet-vända servrar?
2. Var felet som gjorde att människor kunde bryta sig in på din webbplats ett okänt fel i leverantörskoden, för vilken patch var inte tillgänglig? Jag förespråkar verkligen inte byte av leverantör när något som detta biter dig för att de alla har sina problem och att du får slut på plattformar på högst ett år om du tar det. Men om ett system ständigt sviker dig bör du antingen migrera till något mer robust eller åtminstone, omarkitekturera ditt system så att sårbara komponenter förblir insvept i bomullsull och så långt bort från fientliga ögon. / li>
3. Var felet ett kodfel som utvecklats av dig (eller någon som arbetar för dig)? Om så är fallet, behöver du ompröva din inställning till hur du godkänner kod för distribution till din live-webbplats? Kunde felet ha fångats med ett förbättrat testsystem eller med ändringar av din kodningsstandard (till exempel, medan teknik inte är ett universalmedel, kan du minska sannolikheten för en framgångsrik SQL-injektionsattack genom att använda väldokumenterade kodningstekniker ).
4. Berod felet på ett problem med hur servern eller applikationsprogramvaran distribuerades? Om så är fallet använder du automatiserade procedurer för att bygga och distribuera servrar där det är möjligt? Dessa är till stor hjälp för att upprätthålla ett konsekvent "baslinjetillstånd" på alla dina servrar, vilket minimerar mängden anpassat arbete som måste göras på var och en och därmed förhoppningsvis minimerar möjligheten att ett misstag görs. Samma sak gäller koddistribution - om du behöver göra något "speciellt" för att distribuera den senaste versionen av din webbapp, försök sedan hårt att automatisera den och se till att den alltid görs på ett konsekvent sätt.
5. Kunde har intrånget fångats tidigare med bättre övervakning av dina system? Naturligtvis kan 24-timmarsövervakning eller ett "bevaknings" -system för din personal inte vara kostnadseffektivt, men det finns företag där ute som kan övervaka dina webbinriktade tjänster åt dig och varna dig vid problem. Du kan bestämma att du inte har råd med det eller inte behöver det och det är bara bra ... ta bara hänsyn till det.
6. Använd verktyg som tripwire och nessus där det är lämpligt - men inte bara använd dem blint eftersom jag sa det. Ta dig tid att lära dig hur du använder några bra säkerhetsverktyg som passar din miljö, håll verktygen uppdaterade och använd dem regelbundet.
7. Överväg att anställa säkerhetsexperter för att "granska" din webbplats säkerhet regelbundet. Återigen kan du bestämma att du inte har råd eller inte behöver det och det är bara bra ... ta bara hänsyn till det.

Vilka steg kan du ta för att minska konsekvenserna av en framgångsrik attack?

Om du bestämmer dig för att "risken" för nedre våningen i ditt hem översvämning är hög, men inte tillräckligt hög för att motivera flyttning, bör du åtminstone flytta den oföränderliga familjens arv på övervåningen. Eller hur?

1. Kan du minska antalet tjänster som exponeras direkt för Internet? Kan du behålla någon form av klyfta mellan dina interna tjänster och dina Internet-riktade tjänster? Detta säkerställer att även om dina externa system äventyras är chanserna att använda detta som en språngbräda för att attackera dina interna system begränsade.
2. Lagrar du information som du inte behöver lagra? Lagrar du sådan information "online" när den kan arkiveras någon annanstans. Det finns två punkter i denna del; det uppenbara är att människor inte kan stjäla information från dig som du inte har, och den andra punkten är att ju mindre du lagrar, desto mindre behöver du underhålla och koda för, så det finns färre chanser för att buggar glider in din kod eller systemdesign.
3. Använder du "minst åtkomst" -principer för din webbapp? Om användare bara behöver läsa från en databas, se till att kontot som webbappen använder för att tillhandahålla detta endast har läsbehörighet, tillåt inte skrivåtkomst och absolut inte åtkomst på systemnivå.
4. Om du är inte särskilt erfaren på något och det är inte centralt för ditt företag, överväg att lägga ut det. Med andra ord, om du driver en liten webbplats som talar om att skriva applikationskod för skrivbordet och bestämmer dig för att börja sälja små skrivbordsapplikationer från webbplatsen, kan du överväga att lägga ut ditt kreditkortssystem till någon som Paypal.
5. Om gör det möjligt att öva återhämtning från komprometterade system till din katastrofåterställningsplan. Detta är förmodligen bara ett annat "katastrofscenario" som du kan stöta på, helt enkelt ett med sina egna problem och problem som skiljer sig från det vanliga "serverrummet tog eld" / "invaderades av jätteservern som äter furbies".

... Och slutligen

Jag har antagligen utelämnat något slut på saker som andra anser vara viktiga, men stegen ovan borde åtminstone hjälpa dig att börja reda ut saker om du har turen att bli offer för hackare.

Framför allt: Var inte panik. Tänk innan du agerar. Handla bestämt när du har fattat ett beslut och lämna en kommentar nedan om du har något att lägga till i min lista över steg.

Making a file "undeletable" in Linux is done with attributes, specifically the "immutable" attribute. See lsattr to see attributes, chattr to change them.

However, this only answers to the proximal cause. The important thing is that your machine was put through hostile control, and the hijacker installed things for his own devious goals. In particular, he most probably installed a rootkit in order to keep the entry open despite cleansing attempts like what you are trying to do. Rootkits may have altered the kernel and/or the system binaries in ways that will not be visible from the machine itself, and which will prevent their own removal. The bottom-line is that your machine cannot be saved; there is no way you can reliably make your machine clean again, save by reformatting the disk and reinstalling from scratch.

Save yourself from future worries and headaches; nuke your system from orbit.

Som jag sa i svaret på tvärposten från ServerFault. Att det är en bra förklaring. Dessutom beror det verkligen på vilken typ av attack; förhoppningsvis eller tyvärr är denna attack högljudd nog att du kände igen den som en attack i processen. Eller, på vad du kan vara rimligt säker på är de tidiga stadierna av en attack, skulle jag säga att denna orderordning är en bra plan att följa.

Men möjligheten finns att indikatorerna för kompromiss du är medveten om kanske inte målar hela bilden av infektionen och att koppla bort den datorn kanske inte är till ditt bästa förrän du förstår omfattningen, jag argumenterar för att det kan vara bättre att ta reda på inträdesställen och vilka system du kanske inte har kontroll över innan du börjar ta bort berörda system / enheter från nätverket.

Sanningen i saken kan vara att dessa aktörer har varit i dina system längre än du trodde och att visa din hand för tidigt (dvs jag har äntligen märkt att du sitter i mina system) kan göra det mycket svårare att utrota.

Det finns inget riktigt enkelt svar , men den som tillhandahålls av RobM är en mer än tillräcklig startpunkt. Med alla påtryckningar finns det flera rätta svar som lika gärna kan vara fel svar. Nästan som osäkerhetsprincipen gäller, du vet inte om svaret kommer att vara exakt tills du försöker.

Även (PDF) NIST Computer Security Incident Handling Guide bör också granskas.

Säkerhetskopiera allt - så att du kan genomföra kriminalteknik i en sandlådamiljö.

Sedan - börja från 0 - ja från INGENTING.

Ny O / S - helt patched.Applications - aktuella uppdaterade datafiler .... från dina säkerhetskopior (Innan du komprometteras om möjligt). Om inte måste du skanna innehåll och behörigheter ALLT.

Gör sedan en genomgång av hur hackarna kom in och se till att det inte händer igen.

När du får reda på vad har hänt - vidta åtgärder för att säkerställa att det inte kan inträffa igen och publicera (internt och / eller externt) vad du har hittat (Du kan välja att utelämna motåtgärderna).

Om du inte lär dig av detta - du kommer att drabbas av samma öde igen.

Metoden är utsatt för det exakta verklighetsscenariot men nedan skulle vara ett möjligt tillvägagångssätt.

• Vilka är mina första steg? När jag kommer till webbplatsen ska jag koppla bort servern, bevara "bevis", finns det andra inledande överväganden?

Svar: Du måste naturligtvis koppla bort servern från nätverket men ska inte stänga av / stänga av servern, eftersom du kan behöva göra kriminalteknik för att förstå situationen, effekterna av händelsen och måste bevara bevis (data i ditt minne kan raderas om du stänger av servern).

Krishantering och kommunikation - Om du har en krishantering och DR / BCP-policy följer du procedurerna som anges. Detta utsätts igen för scenariot i det här fallet kan detta vara en virusutbredning, så du kan behöva följa din process.

• Hur går jag åt för att få tjänster tillbaka online?

Ans: Som anges ovan, följ dina krishanterings- / DR / BCP-instruktioner. Detta kan variera beroende på situationen.

Till exempel, om detta virus var en tidsbomb eller utlöstes med någon åtgärd på servern och en Ransomware-attack, är det bättre att inte ta upp din DR omedelbart (detta kan utlösa en annan skadlig kod sprids från din DR-server). Bästa metoden skulle vara att bedöma händelsens inverkan på ditt nätverk och sedan vidta nödvändiga åtgärder för att få tillbaka dina tjänster.

• Hur förhindrar jag att samma sak händer omedelbart igen?

Ans: Grundorsaken till händelsen ska bestämmas snarast för att förhindra att samma händelse inträffar igen. Som anges i svaret ovan kan du i ett Ransomware-scenario behöva se till att skadlig programvara inte sprids till din DR / Backup.

Om incidenten har hänt på grund av en sårbarhet i ditt nätverk (till exempel en brandväggsport öppnades felaktigt och attacken kom genom den här porten, omedelbara åtgärder för att stänga den kända / identifierade sårbarheten för att undvika att händelsen inträffar igen.

• Finns det bästa metoder eller metoder för att lära av denna incident?

Ans: Ja, varje incident kan vara unik till sin natur. Så uppdatera dina krishanterings- / DR / BCP-procedurer för att återspegla inlärningen av sådana incidenter.

Det rekommenderas alltid att ha proaktiv övervakning / incidentidentifiering på plats för att undvika / tidig upptäckt av till exempel kan du distribuera ett SOC (Security Operations Center) eller SIEM (Security Incident Event Management) -verktyg.

• Om jag ville sätta en Incident Response Plan, var skulle jag bör detta vara en del av min katastrofåterställning eller kontinuitetsplanering?

Svar: Den här sho Du bör vara en del av din BCP / DR-plan och vanligtvis omfattas av krishantering (del av BCP-planen).