Låt oss berätta en cool historia om hur "tredje parter" försökte störa våra kunders arbete och hur detta problem löstes.
Hur allt började
Allt började på morgonen den 31 oktober, den sista dagen i månaden, då många desperat behöver hinna lösa akuta och viktiga frågor.
En av partnerna, som håller flera virtuella maskiner för klienterna han betjänar i vårt moln, rapporterade att från 9:10 till 9:20 flera Windows-servrar som kördes på vår ukrainska webbplats inte accepterade anslutningar till fjärråtkomsttjänsten , användare kunde inte att logga in på sina skrivbord, men efter några minuter verkade problemet lösa sig av sig själv.
Vi höjde statistiken över driften av kommunikationskanaler, men hittade inga trafikstörningar eller fel. Vi tittade på statistiken över belastningen på datorresurser – inga anomalier. Och vad var det?
Sedan rapporterade en annan partner, som är värd för ett hundratal fler servrar i vårt moln, samma problem som vissa av deras klienter noterade, och det visade sig att servrarna i allmänhet var tillgängliga (svarade korrekt på pingtestet och andra förfrågningar), men tjänsten fjärråtkomst på dessa servrar accepterar antingen nya anslutningar eller avvisar dem, och vi pratade om servrar på olika platser, vars trafik kommer från olika dataöverföringskanaler.
Låt oss titta på den här trafiken. Ett paket med en anslutningsbegäran kommer till servern:
xx:xx:xx.xxxxxx IP xxx.xxx.xxx.xxx.58355 > 192.168.xxx.xxx.3389: Flags [S], seq 467744439, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
Servern tar emot detta paket, men avvisar anslutningen:
xx:xx:xx.xxxxxx IP 192.168.xxx.xxx.3389 > xxx.xxx.xxx.xxx.58355: Flags [R.], seq 0, ack 467744440, win 0, length 0
Det betyder att problemet uppenbarligen inte orsakas av några problem i driften av infrastrukturen, utan av något annat. Kanske har alla användare problem med fjärrskrivbordslicenser? Kanske lyckades någon sorts skadlig kod tränga in i deras system, och idag aktiverades den, som för ett par år sedan XData и Petya?
Medan vi red ut det fick vi liknande förfrågningar från flera kunder och partners.
Vad händer egentligen på dessa maskiner?
Händelseloggarna är fulla av meddelanden om försök att gissa lösenordet:
Vanligtvis registreras sådana försök på alla servrar där standardporten (3389) används för fjärråtkomsttjänsten och åtkomst tillåts överallt. Internet är fullt av bots som ständigt skannar alla tillgängliga anslutningspunkter och försöker gissa lösenordet (det är därför vi starkt rekommenderar att du använder komplexa lösenord istället för "123"). Intensiteten i dessa försök den dagen var dock för hög.
Vad ska jag göra?
Rekommenderar kunderna att lägga mycket tid på att ändra inställningar för att ett stort antal slutanvändare ska byta till en annan port? Ingen bra idé, kunderna kommer inte att vara nöjda. Rekommenderar du att endast tillåta åtkomst via VPN? I all hast och panik, höja IPSec-anslutningar för dem som inte har dem uppfostrade - kanske en sådan lycka ler inte heller mot klienterna. Även om jag måste säga att detta är en gudomlig sak i alla fall, rekommenderar vi alltid att du gömmer servern i ett privat nätverk och är redo att hjälpa till med inställningarna, och för de som gillar att lista ut det på egen hand delar vi instruktioner för att ställa in IPSec/L2TP i vårt moln i plats-till-plats- eller vägläge -warrior, och om någon vill sätta upp en VPN-tjänst på sin egen Windows-server är de alltid redo att dela med sig av tips om hur man ställer in en standard RAS eller OpenVPN. Men oavsett hur coola vi var, var detta inte den bästa tiden att bedriva utbildningsarbete bland kunderna, eftersom vi behövde åtgärda problemet så snabbt som möjligt med minimal stress för användarna.
Lösningen vi implementerade var följande. Vi har satt upp en analys av passerande trafik på ett sådant sätt att vi övervakar alla försök att upprätta en TCP-anslutning till port 3389 och väljer adresser från den som inom 150 sekunder försöker upprätta anslutningar med mer än 16 olika servrar i vårt nätverk - det här är källorna till attacken ( Naturligtvis, om en av klienterna eller partnerna har ett verkligt behov av att upprätta förbindelser med så många servrar från samma källa, kan du alltid lägga till sådana källor till den "vita listan." Dessutom, om i ett klass C-nätverk under dessa 150 sekunder, mer än 32 adresser identifieras, är det vettigt att blockera hela nätverket. Blockeringen är inställd på 3 dagar, och om under denna tid inga attacker utfördes från en given källa, denna källa tas automatiskt bort från den "svarta listan". Listan över blockerade källor uppdateras var 300:e sekund.
Denna lista finns på denna adress: , kan du bygga dina ACL baserat på det.
Vi är redo att dela källkoden för ett sådant system; det finns inget alltför komplicerat i det (detta är flera enkla skript sammanställda på bokstavligen ett par timmar på knäet), och samtidigt kan den anpassas och användas inte bara för att skydda mot en sådan attack, men också för att upptäcka och blockera alla försök att skanna nätverket:
Dessutom har vi gjort några ändringar i inställningarna för övervakningssystemet, som nu mer noggrant övervakar reaktionen från en kontrollgrupp av virtuella servrar i vårt moln på ett försök att upprätta en RDP-anslutning: om reaktionen inte följer inom en för det andra är detta en anledning att vara uppmärksam.
Lösningen visade sig vara ganska effektiv: det finns inga fler klagomål från både kunder och partners och från övervakningssystemet. Nya adresser och hela nätverk läggs regelbundet till på den svarta listan, vilket indikerar att attacken fortsätter, men inte längre påverkar våra klienters arbete.
Det finns säkerhet i siffror
Idag fick vi veta att andra operatörer har stött på ett liknande problem. Någon tror fortfarande att Microsoft gjorde några ändringar i koden för fjärråtkomsttjänsten (om du kommer ihåg, misstänkte vi samma sak första dagen, men vi avvisade mycket snabbt den här versionen) och lovar att göra allt för att snabbt hitta en lösning . Vissa människor ignorerar helt enkelt problemet och råder klienter att skydda sig själva (ändra anslutningsporten, dölja servern i ett privat nätverk och så vidare). Och redan första dagen löste vi inte bara det här problemet, utan skapade också en del grund för ett mer globalt hotdetektionssystem som vi planerar att utveckla.
Speciellt tack till kunderna och partners som inte förblev tysta och inte satt på flodstranden och väntade på att liket av en fiende skulle flyta längs den en dag, utan omedelbart uppmärksammade problemet, vilket gav oss möjlighet att eliminera det samma dag.
Källa: will.com