Pentru a proteja routerul de incercarile repetate de access prin ssh/telnet, chiar dintr-o retea considerata sigura, putem configura o regula ce tine cont de un anumit pattern ce corespunde unui atac de tip dictionar.

Sa spunem ca este permis in ACL conexiunea de tip telnet/ssh de la un anumit ip public, de exemplu 1.1.1.1. Aceasta reprezinta o protectie basic, dar daca exista un user rau-voitor in reteaua din spatele acestui ip public, care foloseste un soft bun pentru spart parole, este indicat sa configuram un mecanism de prevenire impotriva incercarilor repetate.

Setarea este introdusa din global configuration:

login block-for 3600 attempts 3 within 30

Aici spunem ca daca un host introduce gresit parola de 3 ori intr-un interval de 30 de secunde, toate ip-urile vor fi blocate timp de o ora (3600 secunde) in incercarea de a se loga prin ssh/telnet pe router. Intervalul maxim de blocare este de 65535 secunde, adica aproximativ 19 ore. Ca metode initiale de securizare a accesului este un best-practice sa:

-configuram o parola complexa de minim 15 caractere continand numere, majuscule, caractere speciale etc.
-configuram un ACL standard care sa cuprinda ip-urile permise pentru ssh, atasat liniilor vty:

ip access-list standard SSH
permit host 1.1.1.1
permit host 192.168.1.2
line vty 0 4
access-class SSH in

-configuram numarul de încercări eșuate pentru ssh în urma cărora să se întrerupă sesiunea cu echipamentul:

ip ssh authentication-retries 2

Dacă avem un ip folosit de o singura persoana sau o echipa IT care este de incredere ca nu are intentii malitioase, se poate adauga ip-ul in spatele caruia se afla aceasta echipa intr-un whitelist in care sa nu se aplice aceasta setare:

  1. Configuram acl-ul unde vom mentiona ip-ul respectiv:
    access-list standard DONOT-BLOCK
    permit host 172.16.1.2
  2. Menționam acest acl in setarea de quiet-mode:
    login quiet-mode access-class DNOT_BLOCK

In aceasta setare spun ca ip-ul din acl, 172.16.1.2, va fi adaugat in lista de quiet-mode, adica daca comportamentul mentionat in setarea initiala se observa la acest ip va fi ignorat de device si nu-l va bloca.

Logurile de mai jos arata 3 incercari esuate:

*Jun 9 08:01:48.726: %SEC_LOGIN-4-LOGIN_FAILED: Login failed [user: admin] [Source: 1.1.1.1] [localport: 22] [Reason: Login Authentication Failed] at 08:01:48 UTC Tue Jun 9 2020
*Jun 9 08:01:49.894: %SEC_LOGIN-4-LOGIN_FAILED: Login failed [user: admin] [Source: 1.1.1.1] [localport: 22] [Reason: Login Authentication Failed] at 08:01:49 UTC Tue Jun 9 2020
*Jun 9 08:01:50.510: %SEC_LOGIN-4-LOGIN_FAILED: Login failed [user: admin] [Source: 1.1.1.1] [localport: 22] [Reason: Login Authentication Failed] at 08:01:50 UTC Tue Jun 9 2020

In momentul In care routerul intra in quiet-mode blocand tot traficul apare logul respectiv:

%SEC_LOGIN-1-QUIET_MODE_ON: Still timeleft for watching failures is 2 secs, [user: admin] [Source: 1.1.1.1] [localport: 22] [Reason: Login Authentication Failed] [ACL: DNOT_BLOCK] at 08:01:50 UTC Tue Jun 9 2020

Logul spune clar ca au mai ramas 2 secunde din perioada de veghe a incercărilor eșuate. Este specificat acl-ul de exceptie a ip-ului 1.1.1.1, ceea ce inseamna ca blocam toate ip-urile cu exceptia celor din acl-ul DNOT_BLOCK.

Csnd se termina perioada de blocare globala apare urmatorul log:

%SEC_LOGIN-5-QUIET_MODE_OFF: Quiet Mode is OFF, because block period timed out at 07:47:56 UTC Tue Jun 9 2020

Putem observa setarile de logare prin comanda show login: care prezinta detaliile discutate:

De mentionat ca daca ip-urile din acl-ul DNOT_BLOCK esueaza in autentificare acestea pornesc quiet-mode pe Router blocand pentru restul ip-urilor accesul, doar cele din acl putand sa se logheze in continuare.

Astfel, avem posibilitatea sa activam un mijloc de preventie in plus pe echipamentele noastre de retea impotriva acestui tip de atac.

Articol scris de Bogdan Curduban – Network Engineer