Anem a explicar-vos una història fantàstica sobre com "tercers" van intentar interferir en el treball dels nostres clients i com es va resoldre aquest problema.
Com va començar tot
Tot va començar el matí del 31 d'octubre, l'últim dia del mes, quan molts necessiten desesperadament tenir temps per resoldre problemes urgents i importants.
Un dels socis, que manté diverses màquines virtuals dels clients als quals serveix al nostre núvol, va informar que de 9:10 a 9:20 diversos servidors de Windows que s'executen al nostre lloc ucraïnès no acceptaven connexions al servei d'accés remot, els usuaris no van poder per iniciar sessió als seus escriptoris, però després d'uns minuts el problema semblava que s'havia resolt.
Vam plantejar les estadístiques sobre el funcionament dels canals de comunicació, però no vam trobar cap sobrecàrrega ni fallada de trànsit. Hem analitzat les estadístiques sobre la càrrega dels recursos informàtics, sense anomalies. I això què era?
Aleshores, un altre soci, que allotja un centenar de servidors més al nostre núvol, va informar dels mateixos problemes que alguns dels seus clients van observar, i va resultar que, en general, els servidors eren accessibles (responent correctament a la prova de ping i altres peticions), però el servei d'accés remot en aquests servidors o bé accepta noves connexions o les rebutja, i estàvem parlant de servidors de diferents llocs, el trànsit als quals prové de diferents canals de transmissió de dades.
Mirem aquest trànsit. Un paquet amb una sol·licitud de connexió arriba al servidor:
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
El servidor rep aquest paquet, però rebutja la connexió:
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
Això vol dir que el problema no és evidentment causat per cap problema en el funcionament de la infraestructura, sinó per una altra cosa. Potser tots els usuaris tenen problemes amb les llicències d'escriptori remot? Potser algun tipus de programari maliciós va aconseguir penetrar en els seus sistemes, i avui s'ha activat, com va passar fa un parell d'anys. XData и Petya?
Mentre ho estàvem resolent, vam rebre peticions similars de diversos clients i socis més.
Què passa realment amb aquestes màquines?
Els registres d'esdeveniments estan plens de missatges sobre intents d'endevinar la contrasenya:
Normalment, aquests intents es registren a tots els servidors on s'utilitza el port estàndard (3389) per al servei d'accés remot i es permet l'accés des de qualsevol lloc. Internet està ple de bots que escanegen constantment tots els punts de connexió disponibles i intenten endevinar la contrasenya (per això us recomanem fermament utilitzar contrasenyes complexes en lloc de "123"). Tanmateix, la intensitat d'aquests intents aquell dia va ser massa alta.
Què he de fer?
Recomaneu que els clients passin molt de temps canviant la configuració d'un gran nombre d'usuaris finals per canviar a un port diferent? No és una bona idea, els clients no estaran contents. Recomaneu permetre l'accés només mitjançant VPN? Amb pressa i pànic, augmentar les connexions IPSec per a aquells que no les tenen, potser aquesta felicitat tampoc somriu als clients. Tot i que, he de dir, això és una cosa divina en qualsevol cas, sempre recomanem amagar el servidor en una xarxa privada i estem preparats per ajudar amb la configuració, i per a aquells que els agrada esbrinar-ho sols, compartim instruccions. per configurar IPSec/L2TP al nostre núvol en mode lloc a lloc o carretera -guerrer, i si algú vol configurar un servei VPN al seu propi servidor de Windows, sempre està preparat per compartir consells sobre com configurar un RAS estàndard o OpenVPN. Però, per molt genials que fóssim, aquest no era el millor moment per dur a terme un treball educatiu entre els clients, ja que necessitàvem solucionar el problema el més ràpidament possible amb el mínim estrès per als usuaris.
La solució que vam implementar va ser la següent. Hem realitzat una anàlisi del trànsit de pas de manera que controlem tots els intents d'establir una connexió TCP al port 3389 i seleccionem d'ella adreces que, en 150 segons, intentin establir connexions amb més de 16 servidors diferents de la nostra xarxa. - aquestes són les fonts de l'atac (Per descomptat, si un dels clients o socis té una necessitat real d'establir connexions amb tants servidors des de la mateixa font, sempre podeu afegir aquestes fonts a la "llista blanca". si en una xarxa de classe C durant aquests 150 segons s'identifiquen més de 32 adreces, té sentit bloquejar tota la xarxa. El bloqueig està establert per a 3 dies, i si durant aquest temps no s'han dut a terme atacs des d'una font determinada, aquesta font s'elimina automàticament de la "llista negra". La llista de fonts bloquejades s'actualitza cada 300 segons.
Aquesta llista està disponible a aquesta adreça: , podeu crear les vostres ACL basant-s'hi.
Estem preparats per compartir el codi font d'aquest sistema; no hi ha res massa complex (es tracta de diversos scripts senzills compilats literalment en un parell d'hores al genoll) i, al mateix temps, es pot adaptar i utilitzar no només per protegir-se d'aquest atac, però també per detectar i bloquejar qualsevol intent d'escanejar la xarxa:
A més, hem fet alguns canvis en la configuració del sistema de monitorització, que ara fa un seguiment més a prop de la reacció d'un grup de control de servidors virtuals al nostre núvol davant un intent d'establir una connexió RDP: si la reacció no segueix en un termini segon, aquest és un motiu per prestar atenció.
La solució va resultar força eficaç: no hi ha més queixes tant de clients com de socis, i del sistema de seguiment. Periòdicament s'afegeixen noves adreces i xarxes senceres a la llista negra, la qual cosa indica que l'atac continua, però ja no afecta el treball dels nostres clients.
Hi ha seguretat en els números
Avui hem après que altres operadors s'han trobat amb un problema similar. Algú encara creu que Microsoft va fer alguns canvis al codi del servei d'accés remot (si recordeu, vam sospitar el mateix el primer dia, però vam rebutjar molt ràpidament aquesta versió) i es compromet a fer tot el possible per trobar una solució ràpidament. . Algunes persones simplement ignoren el problema i aconsellen als clients que es protegeixin per si mateixos (canviar el port de connexió, amagar el servidor en una xarxa privada, etc.). I el primer dia, no només vam resoldre aquest problema, sinó que també vam crear algunes bases per a un sistema de detecció d'amenaces més global, que tenim previst desenvolupar.
Un agraïment especial als clients i socis que no es van quedar en silenci i no es van asseure a la vora del riu esperant que el cadàver d'un enemic surés per ell algun dia, però de seguida ens van cridar l'atenció sobre el problema, que ens va donar l'oportunitat d'eliminar el mateix dia.
Font: www.habr.com