Dicemu una storia fresca nantu à cumu "terzi" anu pruvatu à interferiscenu cù u travagliu di i nostri clienti, è cumu si risolve stu prublema.
Cumu tuttu principia
Tuttu hà cuminciatu à a matina di u 31 d'ottobre, l'ultimu ghjornu di u mese, quandu parechji anu bisognu à avè u tempu di risolve i prublemi urgenti è impurtanti.
Unu di i partenarii, chì mantene parechje macchine virtuale di i clienti chì serve in u nostru nuvulu, hà dettu chì da 9:10 à 9:20 parechji servitori Windows in esecuzione in u nostru situ ucrainu ùn accettanu micca cunnessione à u serviziu d'accessu remoto, l'utilizatori ùn anu pussutu. per accede à i so desktop, ma dopu à uni pochi di minuti, u prublema paria chì si risolve.
Avemu risuscitatu e statistiche nantu à u funziunamentu di i canali di cumunicazione, ma ùn truvamu nisuna crescita di trafficu o fallimenti. Avemu guardatu e statistiche nantu à a carica nantu à e risorse di l'informatica - senza anomalie. È chì era questu?
Allora un altru cumpagnu, chì ospitu circa un centu più di servitori in u nostru nuvulu, hà riportatu i stessi prublemi chì alcuni di i so clienti anu nutatu, è hè statu chì in generale i servitori eranu accessibili (rispondenu bè à a prova di ping è altre dumande), ma l'accessu remotu di u serviziu nantu à questi servitori o accetta novi cunnessione o li rifiuta, è avemu parlatu di servitori in siti diversi, u trafficu à quale vene da diversi canali di trasmissione di dati.
Fighjemu stu trafficu. Un pacchettu cù una dumanda di cunnessione arriva à u servitore:
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
U servitore riceve stu pacchettu, ma rifiuta a cunnessione:
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
Questu significa chì u prublema ùn hè chjaramente micca causatu da qualsiasi prublemi in u funziunamentu di l'infrastruttura, ma da qualcosa altru. Forsi tutti l'utilizatori anu prublemi cù licenze di desktop remoto? Forsi un tipu di malware hà sappiutu penetrà in i so sistemi, è oghje hè stata attivata, cum'è cù un paru d'anni fà. XData и Petia?
Mentre eramu a sorte, avemu ricevutu richieste simili da parechji più clienti è partenarii.
Cosa succede veramente in queste macchine?
I logs di l'avvenimenti sò pieni di missaghji nantu à i tentativi di invintà a password:
Di genere, tali tentativi sò registrati in tutti i servitori induve u portu standard (3389) hè utilizatu per u serviziu di accessu remoto è l'accessu hè permessu da ogni locu. L'Internet hè pienu di bots chì scannanu constantemente tutti i punti di cunnessione dispunibili è pruvate d'invintà a password (hè per quessa chì ricumandemu fermamente l'usu di password cumplessi invece di "123"). Tuttavia, l'intensità di sti tentativi quellu ghjornu era troppu altu.
Chì deve fà?
Hè ricumandemu chì i clienti passanu assai tempu per cambià i paràmetri per un gran numaru d'utilizatori finali per cambià à un portu diversu? Ùn hè micca una bona idea, i clienti ùn saranu micca felici. Cunsigliu di permette l'accessu solu via VPN? In fretta è in panicu, aumentà e cunnessione IPSec per quelli chì ùn l'anu micca criatu - forse una tale felicità ùn sorridi ancu à i clienti. Ancu s'ellu, devi dì, questu hè una cosa divina in ogni casu, ricumandemu sempre di ammuccià u servitore in una reta privata è sò pronti à aiutà cù i paràmetri, è per quelli chì piacenu à capisce da sè stessu, spartemu istruzzioni. per stallà IPSec/L2TP in u nostru nuvulu in modu situ-à-situ o strada -warrior, è se qualcunu vole stabilisce un serviziu VPN in u so servitore Windows, sò sempre pronti à sparte cunsiglii nantu à cumu cunfigurà un RAS standard o OpenVPN. Ma, ùn importa micca quantu eramu cool, questu ùn era micca u megliu tempu per fà u travagliu educativu trà i clienti, postu chì avemu bisognu di risolve u prublema u più prestu pussibule cun un minimu stress per l'utilizatori.
A suluzione chì avemu implementatu hè stata a siguenti. Avemu stabilitu un analisi di u trafficu chì passa in modu di monitorà tutti i tentativi di stabilisce una cunnessione TCP à u portu 3389 è selezziunate da ellu indirizzi chì, in 150 seconde, pruvate à stabilisce cunnessione cù più di 16 servitori diffirenti in a nostra reta. - Quessi sò e fonti di l'attaccu (Di sicuru, se unu di i clienti o partenarii hà un veru bisognu di stabilisce cunnessione cù tanti servitori da a listessa fonte, pudete sempre aghjunghje tali fonti à a "lista bianca". se in una rete di classi C per questi 150. seconde, più di 32 indirizzi sò identificati, hè sensu per bluccà a reta sanu U bluccatu hè stabilitu per 3 ghjorni, è se durante stu tempu ùn sò micca stati attacchi da una fonte , sta fonte hè sguassata da a "lista nera" è a lista di fonti bluccati hè aghjurnata ogni 300 seconde.
Questa lista hè dispunibule à questu indirizzu: , pudete custruisce i vostri ACL basatu annantu à questu.
Semu pronti à sparte u codice fonte di un tali sistema ùn ci hè nunda troppu cumplicatu in questu (questi sò parechji scripti simplici compilati in literalmente un paru d'ore nantu à u ghjinochju), è à u stessu tempu pò esse adattatu è micca usatu; solu per pruteggiri contr'à un tali attaccu, ma ancu per detectà è bluccà ogni tentativu di scansà a reta:
In più, avemu fattu qualchi cambiamenti à i paràmetri di u sistema di surviglianza, chì avà più attentamente monitoreghja a reazione di un gruppu di cuntrollu di servitori virtuali in u nostru nuvulu à un tentativu di stabilisce una cunnessione RDP: se a reazione ùn seguita micca in un tempu. secondu, questu hè un mutivu per attentu.
A suluzione hè stata abbastanza efficace: ùn ci hè più lagnanza da i clienti è i partenarii, è da u sistema di surviglianza. I novi indirizzi è e rete intere sò regularmente aghjuntu à a lista negra, chì indica chì l'attaccu cuntinueghja, ma ùn afecta più u travagliu di i nostri clienti.
Ci hè sicurezza in numeri
Oghje avemu amparatu chì altri operatori anu scontru un prublema simili. Qualchissia crede sempre chì Microsoft hà fattu alcuni cambiamenti à u codice di u serviziu d'accessu remotu (se vi ricordate, avemu suspettatu a stessa cosa u primu ghjornu, ma avemu rifiutatu assai rapidamente sta versione) è prumetti di fà tuttu ciò chì hè pussibule per truvà una suluzione rapidamente. . Certi pirsuni simpricamente ignoranu u prublema è cunsiglianu à i clienti per pruteggiri per sè stessu (cambià u portu di cunnessione, oculta u servitore in una reta privata, etc.). È u primu ghjornu, ùn solu solu risolviu stu prublema, ma ancu criatu un pocu di basi per un sistema di deteczione di minaccia più globale chì avemu pensatu à sviluppà.
Un ringraziu speciale à i clienti è i partenarii chì ùn sò micca stati in silenziu è ùn si sò micca pusatu nantu à a riva di u fiumu aspittendu chì u cadaveru di un nemicu flotterà longu à ellu un ghjornu, ma hà subitu attiratu a nostra attenzione à u prublema, chì ci hà datu l'uppurtunità di eliminà. u listessu ghjornu.
Source: www.habr.com