Newsgroup: it.comp.sicurezza.varie
Titolo: bloccare IP in accesso RDP

premessa:
un cliente si lamentava che la connessione da fuori al server Windows 
2016 Standard (tramite RDP) andava una volta sì e ventordici no
 
gli ho fatto controllare il log e son saltate fuori un considerevole 
numero di righe Warning:
 
A connection from the client computer with an IP address of 
109.107.166.22 failed because the user name or password is not correct.
 
questo IP è geolocalizzato in Romania per cui qualcuno ci sta provando; 
talvolta finisce con .22, talaltra con .8
 
Premesso che già in partenza la porta aperta sul router NON era quella 
standard 3389 ma una scelta a caso, la prima cosa che gli ho suggerito 
è stata di cambiarla ulteriormente (sul router, port forwarding)
 
tutto ok, fine dei tentativi di accesso e le connessioni lecite son 
tornate a funzionare a meraviglia, ma penso sia questione di tempo e 
prima o poi torneranno all'attacco sulla nuova porta
 
ora vengo al punto: le guide di Windows suggeriscono una policy che 
blocca l'utente RDP dopo un certo numero di accessi falliti, io vorrei 
invece sapere (dato che non ho trovato  nulla a riguardo) se c'è anche 
modo di bloccare l'IP chiamante, mettendolo in una blacklist 
(eventualmente modificabile in caso di reali tentativi di un utente 
autorizzato ma molto distratto) ;o)
 
l'alternativa che suggerirò è quella di mettere in mezzo una VPN, 
magari con un sistema di autenticazione a due fattori o la generazione 
di token “usa e getta”, ma ci vorrà del tempo, qui son tutti chiusi 
ormai, se ne riparla a settembre
 
-- 
/-\ /\/\ /\/\ /-\ /\/\ /\/\ /-\ T /-\
-=- -=- -=- -=- -=- -=- -=- -=- - -=-
........... [ al lavoro ] ...........

 riparla a settembre
 
Ma riparlane, perché RDP esposto su internet è la morte.
 
 
 

 un utente autorizzato ma molto distratto) ;o)
 
Si può fare, ma non so se sia consigliabile, in breve si tratta di
creare nel task scheduler di windows un nuovo job schedulato, come
condizioni di avvio selezioni "al verificarsi di un evento" e poi
imposti l'evento corrispondente al mancato logon RDP, fatto questo
imposti il comando da lanciare ad uno script, quest'ultimo andrà a
ripescare l'IP (o gli IP) e poi usando un comando "netsh" creerà una
regola di blocco nel firewall (oppure aggiungerà l'IP ad una regola di
blocco esistente); il punto è... ne vale la pena ? Considera che tali
tentativi arrivano da bot automatici che hanno una lista di IP/porte
ottenuta da altri bot che hanno effettuato scansioni, ora, tu puoi
bloccare l'IP di un bot, ma a breve, ti arriveranno tentativi da un
altro bot... e così via, quindi a meno di non filtrare per blocchi di
IP, direi che l'idea sia da scartare
 
Ripeto, considera la VPN, una OpenVPN si tira su in breve, ma se non si
vuole installare nulla, si può anche usare il supporto VPN nativo di
windows ed installare una banale PPTP
 
 
 

 Ma riparlane, perché RDP esposto su internet è la morte.
 
Effettivamente ho dovuto rileggere la frase due volte per rendermi conto 
che fosse vera!
 
Saluti.
^Bart
 

 windows ed installare una banale PPTP
 
A mio avviso farei fare da VPN ad una macchina dedicata nello specifico 
una macchina con una qualsiasi distribuzione linux (meglio se Debian) su 
cui installare OpenVPN.
 
In rete ci sono migliaia di guide che nel giro di un paio d'ore di 
permettono di eseguire il tutto e risolvere appunto in un paio d'ore 
tutti i problemi segnalati, se poi ci si aggiunge anche fail2ban pure 
meglio! :)
 
Saluti.
^Bart

 l'utente RDP dopo un certo numero di accessi falliti
 
ripartiamo da qui: mi son fatto mandare un estratto dal registro 
eventi, contenete i record dove è segnalato l'errore (ID 140)
 
in aggiunta alla descrizione riportata in General (A connection from 
the client computer with an IP address of 109.107.166.22 failed because 
the user name or password is not correct.) ci sono altri dati in 
Details, ma tra di essi non vedo il nome utente usato per tentare di 
log-garsi
 
posso supporre che usino admin o administrator, o user o altri 
probabili, ma comunque sia non lo vedo e non vorrei che poi mi 
bloccasse proprio administrator...
 
c'è un Security UserID="S-1-5-20" ma non mi dice nulla (vedi 
https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-identifiers
)
 
se anche lo bloccasse solo come RDP poi avrebbe qualche problema a 
collegarsi quando vuole creare un nuovo utente o disattivarne un altro, 
procedure standard che esegue senza supervisione, il server è nel rack, 
senza monitor e tastiera, anche se sono a disposizione nell'armadietto 
a fianco
 
 
qui sotto sia la versione XML che quella 'Friendly'
 
 
 
- <Event xmlns="
http://schemas.microsoft.com/win/2004/08/events/event
">
- <System>
  <Provider Name="Microsoft-Windows-RemoteDesktopServices-RdpCoreTS" 
Guid="{1139c61b-b549-4251-8ed3-27250a1edec8}" />
  <EventID>140</EventID>
  <Version>0</Version>
  <Level>3</Level>
  <Task>4</Task>
  <Opcode>14</Opcode>
  <Keywords>0x4000000000000000</Keywords>
  <TimeCreated SystemTime="2023-08-03T15:32:36.1557752Z" />
  <EventRecordID>252649937</EventRecordID>
  <Correlation ActivityID="{f420c9e7-4990-4dc3-81cf-cb7f21760000}" />
  <Execution ProcessID="884" ThreadID="3380" />
 
<Channel>Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational</Channel>
  <Computer>server</Computer>
  <Security UserID="S-1-5-20" />
  </System>
- <EventData>
  <Data Name="IPString">109.107.166.22</Data>
  </EventData>
  </Event>
 
 
- System
 
  - Provider
 
   [ Name]  Microsoft-Windows-RemoteDesktopServices-RdpCoreTS
   [ Guid]  {1139c61b-b549-4251-8ed3-27250a1edec8}
 
   EventID 140
 
   Version 0
 
   Level 3
 
   Task 4
 
   Opcode 14
 
   Keywords 0x4000000000000000
 
  - TimeCreated
 
   [ SystemTime]  2023-08-03T15:32:36.1557752Z
 
   EventRecordID 252649937
 
  - Correlation
 
   [ ActivityID]  {f420c9e7-4990-4dc3-81cf-cb7f21760000}
 
  - Execution
 
   [ ProcessID]  884
   [ ThreadID]  3380
 
   Channel 
Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational
 
   Computer server
 
  - Security
 
   [ UserID]  S-1-5-20
 
 
- EventData
 
  IPString 109.107.166.22


 conto che fosse vera!
 
cerca "TSgrinder" e considera che quello è già "datato", vedi tu...
 

 se Debian) su cui installare OpenVPN.
 
Aridaje con Debian, lo può fare con qualsiasi cosa, da un router che
supporti OpenVPN fino ad un Windows, passando per BSD e per millemila
altre piattaforme :) oppure se ha solo Windows, può usare RRAS e tirar
su una VPN direttamente in windows
 
 
 

 di log-garsi
 
Dovresti trovarlo in un altro evento, se ricordo bene, ma alla fine
della fiera, dell'utente ti interessa sino ad un certo punto, e come ho
scritto, bloccare non credo sia una soluzione, anzi potrebbe complicare
le cose, meglio implementare una VPN
 
 

 meglio! :)
 
fail2ban quando hai la vpn a che ti serve? 

 fail2ban quando hai la vpn a che ti serve?
 
Per bloccare l'ip remoto nel momento in cui per "X" volte sbagli nome 
utente e password della VPN.
 
Saluti.
^Bart

> cerca "TSgrinder" e considera che quello è già "datato", vedi tu...
 
Non capisco perché Windows, pur scopiazzando da tempo dai sistemi unix 
like, non riesca finalmente a creare qualcosa tipo ssh ovvero un sistema 
che ti permetta di loggarti non come root\administrator ma come utente 
normale per poi fare escalation...
 
Forse agendo su qualche policy o chiave di registro si potrà disattivare 
l'accesso di default di Administrator... ad onor del vero non ho mai 
approfondito l'argomento.
 
Saluti.
^Bart

 utente e password della VPN.
 
Ma che dici, le VPN si basano su un mutuo scambio di chiavi/certificati. 
Anche se hai una autenticazione username/pwd non ci arrivi se prima non è 
avvenuto l'handshake. 

 utente e password della VPN.
 
Utente e password ? Non so te, ma io di solito uso l'autenticazione
tramite certificati, è molto più comoda, anche perchè se non si ha un
certificato inserito nel keyring, non ci si connette proprio, in più
revocare un certificato è immediato e semplice; ogni client VPN ha il
suo bravo certificato e se per caso rubano un portatile basta soltanto
revocare il certificato associato e via
 

 ci arrivi se prima non è avvenuto l'handshake. 
 
E se poi vuoi blindare meglio il tutto, metti in piedi autenticazione a
tre fattori, in pratica alla richiesta di connessione, arriva un
messaggio sul cellulare che contiene una ID "usa e getta" da usare per
completare l'autenticazione e la connessione, in quel modo per accedere
alla VPN ti servirà rubare anche il telefono :D
 
 
 
 

 a tre fattori
 
in pratica, devi avere il certificato e devi avere il telefono con quel
dato numero, devi conoscere utente e password e devi anche confermare
il tutto usando il codice effimero, sembra complicato ma non lo è
 


Si ma per tornare al discorso suo su fail2ban il primo step è negoziare i 
certificati, quindi un eventuale brute force può passare solo di li. E 
forzare una chiave RSA 4096 bit è una impresa che non richiede di 
preoccuparsi se uno prova più di 5 o 6 volte consecutive :-D

 uno prova più di 5 o 6 volte consecutive :-D
 
corretto, anche se fail2ban potrebbe venire utilizzato ugualmente, in
tal caso dovrebbe andare a monitorare il log per le voci che riportano
"invalid certificate" o simile e poi agire sugli IP relativi alle
stesse, ma sarebbe comunque eccessivo, dato che come hai giustamente
scritto, la vedo dura generare un certificato valido senza avere il
certificato della CA :)
 
 
 
 
 

 numero di righe Warning:
 
Un altro sistema per evitare questi problemi è quello di usare IPsec,
che è nativo da Windows NT, per le connessioni RDP, nelle versioni più
recenti di Windows la configurazione del tutto è stata semplificata
parecchio, basta vedere qui
 
https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/securing-rdp-with-ipsec/ba-p/259108
 
 
e, considerando che IPSec viene considerato abbastanza sicuro da essere
usato anche dai "mil" direi che ci si possa fidare abbastanza, poi ok,
ci possono essere dei problemi a livello tecnico ed infrastutturare, ma
resta comunque un approccio da tenere presente, anche perchè evita di
dover usare una "VPN completa" solo per la connessione RDP ed allo
stesso tempo permette di usare le GPO e gli strumenti di gestione di AD
per gestire e configurare il tutto
 
giusto un'altra idea da valutare :)
 
ciao
 

 farebbe tagliare gli zebedei pur di seguire un mio consiglio. e vabbè...
 
carissimo!
 
sappi che sei nel killfile dell'altro newsreader, qui invece ti leggo 
ancora.
aggiungerei che a parte qualche diversità di vedute, ogni tanto accolgo 
con malcelata gioia le tue annotazioni
 
buone vacanze, se le devi ancora fare ;o)


 infrastutturaLe
 
<fixed> :) :P
 
 

 Si, ma tu sei un "mito" e non fai testo. ^_^
 
Si vabbè, adesso mi manca solo un monumento
così poi mi cagano in testa i piccioni :D !
 
 
 
 
 
 

 di un monumento. ^_^.
 
Preferisco evitare :)