Securitate

Cum blochezi automat IP-urile care încearcă atacuri de tip Brute Force pe portul RDP în Windows Server folosind PowerShell

Deși există soluții comerciale sau software precum w防 (IPBAN), mulți administratori de rețea caută o metodă nativă, curată și rapidă de a bloca IP-urile suspecte direct în Windows Defender Firewall. Serverele Windows cu portul RDP deschis (3389) sunt constant scanate și atacate, ducând la blocarea conturilor de Active Directory sau utilizare intensă de CPU.

[mai mult...]

Instalarea și configurarea Authentik pentru autentificare centralizată (SSO)

În mediile în care sunt utilizate mai multe aplicații web, gestionarea conturilor și autentificării pentru fiecare aplicație în parte poate deveni dificilă. Authentik este o soluție open-source de Identity Provider (IdP) care permite implementarea autentificării centralizate (Single Sign-On – SSO) pentru aplicații interne și servicii self-hosted. În acest articol vom instala și configura Authentik folosind Docker Compose și vom realiza configurarea inițială necesară pentru administrarea platformei.

Cerințe

  • Server Linux (Ubuntu 22.04 sau mai nou)
  • Docker instalat
  • Docker Compose instalat
  • Acces la internet

Verificare Docker:

docker --version
docker compose version
mkdir authentik
cd authentik

Pasul 2 – Crearea fișierului docker-compose.yml

Creăm fișierul:

nano docker-compose.yml

Adăugăm configurația oficială Authentik:

services:
  postgresql:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_PASSWORD: authentik
      POSTGRES_USER: authentik
      POSTGRES_DB: authentik

  redis:
    image: redis:alpine
    restart: unless-stopped

  server:
    image: ghcr.io/goauthentik/server:latest
    restart: unless-stopped
    ports:
      - "9000:9000"
    environment:
      AUTHENTIK_SECRET_KEY: ChangeThisSecretKey
      AUTHENTIK_POSTGRESQL__HOST: postgresql
      AUTHENTIK_POSTGRESQL__USER: authentik
      AUTHENTIK_POSTGRESQL__PASSWORD: authentik
      AUTHENTIK_POSTGRESQL__NAME: authentik
      AUTHENTIK_REDIS__HOST: redis
    depends_on:
      - postgresql
      - redis

Salvăm fișierul.

Pasul 3 – Pornirea serviciilor

Executăm:

docker compose up -d

Verificăm containerele:

docker ps

Toate serviciile trebuie să fie în stare Running.

Pasul 4 – Accesarea interfeței web

În browser accesăm:

http://IP_SERVER:9000

La prima accesare va fi afișat ecranul de configurare inițială.

( captură de ecran )

Pasul 5 – Crearea contului de administrator

Introducem:

  • Username
  • Email
  • Parolă

și finalizăm configurarea inițială.

( captură de ecran )

Pasul 6 – Crearea unui utilizator

Din meniul:

Directory -> Users

selectăm:

Create User

Completăm informațiile necesare și salvăm.

( captură de ecran )

Pasul 7 – Crearea unui grup

Accesăm:

Directory -> Groups

Selectăm:

Create Group

și atribuim utilizatorii necesari.

( captură de ecran )

Pasul 8 – Configurarea unei aplicații

Din meniul:

Applications -> Applications

selectăm:

Create Application

Configurăm aplicația și asociem providerul de autentificare.

( captură de ecran )

Verificare

Ne autentificăm cu utilizatorul creat anterior și verificăm accesul în platformă.

De asemenea, putem verifica starea containerelor:

docker ps

și logurile:

docker compose logs
[mai mult...]

Activarea sau dezactivarea comenzii „sudo” în Windows 11

Ce este Sudo pentru Windows?

Sudo pentru Windows îți permite să execuți comenzi cu drepturi de administrator dintr-o consolă cu drepturi ridicate, adăugând prefixul „sudo” în fața comenzii. De exemplu, „sudo netstat -ab”; atunci când folosești „sudo”, Windows îți solicită în continuare să confirmi cererea de ridicare a drepturilor.

Sudo pentru Windows este funcția integrată de la Microsoft care permite executarea comenzilor cu drepturi ridicate direct dintr-o sesiune de consolă fără drepturi ridicate în Windows 11. Aceasta este concepută pentru fluxurile de lucru din linia de comandă în care doriți să adăugați prefixul „sudo” la o comandă, în loc să deschideți mai întâi o consolă de administrator separată. Sudo pentru Windows este disponibil în Windows 11 versiunea 24H2 și versiunile ulterioare. Pentru mai multe informații, consultați linkul:

https://learn.microsoft.com/en-us/windows/advanced-settings/sudo/   

Setarea Sudo se găsește în meniul Settings > System > Advanced. Pe dispozitivele cu Windows 11 versiunea 25H2 și versiunile ulterioare.

Cerințe preliminare

Înainte de a începe, asigurați-vă că pe computer rulează Windows 11 24H2 sau o versiune ulterioară, deoarece Sudo pentru Windows nu este disponibil pe versiunile anterioare de Windows 11. De asemenea, rețineți că, pe dispozitivele gestionate, opțiunea „Setări avansate” poate lipsi sau poate fi dezactivată dacă organizația dvs. aplică politici care o restricționează. Prin urmare, dacă nu vedeți opțiunea „Advanced settings/Setari avansate” în aplicația Setări pe un dispozitiv gestionat, cel mai probabil aceasta este dezactivată de o politică de grup sau de o politică Intune.

[mai mult...]

Asistent AI pentru clasificarea și rezolvarea automată a ticketelor recurente cu Ollama si PowerShell

Echipele de suport IT primesc zilnic ticket-uri repetitive (resetare parolă, cont blocat, VPN nefuncțional, mapare drive etc.). Triajul manual și redactarea răspunsurilor consumă timp prețios.

Această soluție citește descrierile ticket-urilor dintr-un fișier CSV (exportat din helpdesk), le clasifică automat pe categorii folosind un model AI local (Ollama) și sugerează pașii de rezolvare pe baza unei baze de cunoștințe interne — totul fără ca datele clienților să părăsească rețeaua.

[mai mult...]

Stocarea cheilor de recuperare BitLocker în Active Directory

Baza de date Active Directory poate fi utilizată ca locație centrală pentru stocarea cheilor de recuperare BitLocker. Puteți configura Politica de grup (GPO) pentru a salva automat cheile de recuperare pentru computerele cu BitLocker activat în AD. Administratorii pot apoi recupera în siguranță cheile de recuperare pentru computere din AD și pot debloca unitățile de stocare criptate ale dispozitivelor în cazul în care un utilizator uită parola BitLocker.

Peisajul administrării BitLocker

În prezent, Active Directory nu mai este sistemul principal/recomandat pentru gestionarea cheilor de recuperare BitLocker. Astăzi, pentru administrarea BitLocker, aveți la dispoziție soluții mai bune bazate pe cloud:

Microsoft Endpoint Manager (Intune). Acesta este înlocuitorul principal al MBAM.
Microsoft BitLocker Administration and Monitoring (MBAM) este învechit.
În mediile conectate la Entra ID și în cele hibride, cheile de recuperare BitLocker sunt de obicei depozitate la Entra ID prin intermediul politicilor Intune/de înscriere a dispozitivelor.

Stocarea cheilor BitLocker bazată pe AD este utilizată acum, de obicei, pentru:

  • Mediile locale vechi
  • Dispozitivele hibride alăturate la domeniu
    Rețelele izolate/fără conexiune la internet

Pentru organizațiile care planifică noi implementări, recomandăm să acorde prioritate gestionării BitLocker bazate pe Intune și depozitării cheilor de recuperare în Entra ID în locul stocării de recuperare bazate pe AD DS vechi, ori de câte ori este posibil.

Reguli de decizie

Ar trebui să utilizați copiile de rezervă BitLocker din AD DS în următoarele cazuri:

  • mediu exclusiv Active Directory local
  • nu există o identitate în cloud (Entra ID)
  • rețeaua dvs. este restricționată/izolată

Ar trebui să utilizați Intune/Entra ID în următoarele cazuri:

  • există o identitate în cloud sau hibridă
  • dispozitivele sunt alăturate la Entra ID sau într-un mod hibrid
  • Microsoft Endpoint Manager este disponibil

Nota Bene: Rețineți că Entra ID/Intune este planul de control implicit pentru recuperarea BitLocker în mediile Microsoft moderne. AD DS este o soluție de rezervă mai veche, pe care ar trebui să o utilizați numai în cazul în care identitatea în cloud nu este disponibilă.

În cazul în care utilizați Intune/Entra ID, ar trebui să omiteți toate secțiunile referitoare la schema AD și GPO. În cazul în care utilizați AD DS, omiteți secțiunile referitoare la Intune/Entra.

Cerințe de mediu și validarea schemei Active Directory

Nota Bene: Înainte de a configura backup-ul BitLocker în AD, vă recomandăm să verificați dacă schema AD a fost extinsă corespunzător și dacă atributele legate de BitLocker sunt prezente la nivel de schemă.

Rețineți că metoda de stocare a cheii de recuperare BitLocker depinde de arhitectura mediului. Ar trebui să alegeți una dintre următoarele:

  • AD DS local (vechi/hibrid)
  • Microsoft Entra ID (nativ în cloud)
  • Politici BitLocker gestionate de Intune (aceasta este abordarea modernă recomandată)

Cerințe de sistem

  • Computere cu Windows 10 sau 11 care rulează edițiile Pro, Education sau Enterprise;
  • Schema Active Directory trebuie să conțină un set de atribute personalizate ale obiectelor de tip computer pentru stocarea cheilor de recuperare BitLocker (disponibile în AD începând cu Windows Server 2012).

Pentru a verifica versiunea schemei AD:

(Get-ADObject `
(Get-ADRootDSE).schemaNamingContext `
-Properties objectVersion).objectVersion

Această operațiune verifică versiunea schemei AD pentru a se asigura că extensiile schemei sunt aplicate la nivel de pădure. Rețineți că versiunea schemei are doar caracter informativ (trebuie să verificați compatibilitatea cu BitLocker folosind verificarea prezenței ldapDisplayName).

Pentru a verifica prezența extensiei de schemă BitLocker, executați următoarea comandă:

$schemaNC = (Get-ADRootDSE).schemaNamingContext
Get-ADObject $schemaNC -Property objectVersion, name
Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext `
-Filter “ldapDisplayName -like ‘msFVE*'” `
-Properties ldapDisplayName |
Select-Object ldapDisplayName

Validarea compatibilității BitLocker cu Active Directory ar trebui să includă:

  • Verificarea versiunii schemelor
  • Confirmarea prezenței atributelor legate de BitLocker (msFVE*)
  • În cele din urmă, verificarea stării de funcționare cu ajutorul comenzii:

Get-ADReplicationFailure -Target * -Scope Forest
Get-ADReplicationPartnerMetadata -Target * | Select LastReplicationSuccess

Chiar și în cazul în care atributele de schemă sunt prezente, copierea de rezervă BitLocker poate eșua din următoarele motive:

  • lipsa aplicării GPO
  • lipsa permisiunilor de scriere pe computer
  • direcționarea incorectă către unitatea organizațională (OU)
  • dispozitivul hibrid nu este conectat corespunzător la AD DS

Pentru o implementare reușită a BitLocker, trebuie să îndepliniți toate condițiile următoare:

  • Există o parolă de recuperare
  • Starea protecției BitLocker este activată
  • Obiectul msFVE-RecoveryInformation există în AD
  • Parola de recuperare poate fi recuperată din ADUC/PowerShell

Atribute obligatorii ale schemei Active Directory

Trebuie să existe următoarele cinci atribute:

  • ms-FVE-KeyPackage
  • ms-FVE-RecoveryGuid
  • ms-FVE-RecoveryInformation
  • ms-FVE-RecoveryPassword
  • ms-FVE-VolumeGuid
[mai mult...]

Audit de Cod și Securitate Automatizat în CI/CD folosind Local AI

Echipele de dezvoltare necesită Code Review-uri rapide pe Pull/Merge Requests pentru a detecta vulnerabilități (ex. SQL Injections, OWASP, credențiale hardcodate) și bug-uri logice. Procesul manual este lent și blochează developerii seniori. Trimiterea codului sursă proprietar către soluții de AI din cloud (ex. OpenAI, GitHub Copilot) încalcă politicile interne de confidențialitate și Data Leakage. Este necesară o soluție locală (on-premise) care să auditeze automat codul modificat, fără costuri per apel.

[mai mult...]