---
title: "NIS 2: instalacja i skanowanie oprogramowaniem anti-rootkit i antywirusowym za pomocą Ansible"
url: https://michalasobczak.pl/pl/posts/nis-2-anti-rootkit-anti-virus-installation-and-scanning-with-ansible.html
author: "Michał Sobczak"
description: "Jeśli prowadzisz platformę usług cyfrowych lub infrastrukturę krytyczną, to najprawdopodobniej obejmuje Cię NIS 2 wraz z wymaganiami, w tym dotyczącymi bezpieczeństwa informacji."
published: 2024-09-02T15:22:29.000Z
updated: 2024-09-02T15:30:55.000Z
language: pl
categories: ["Security"]
tags: ["DevOps & Automation", "Security", "Ethical Hacking", "Proxmox"]
license: CC BY-NC-ND 4.0 (https://creativecommons.org/licenses/by-nc-nd/4.0/)
---
# NIS 2: instalacja i skanowanie oprogramowaniem anti-rootkit i antywirusowym za pomocą Ansible

> Jeśli prowadzisz platformę usług cyfrowych lub infrastrukturę krytyczną, to najprawdopodobniej obejmuje Cię NIS 2 wraz z jej wymaganiami, w tym tymi dotyczącymi bezpieczeństwa informacji. Nawet jeśli NIS 2 Cię nie obejmuje, nadal możesz skorzystać z jej regulacji, które wydają się podobne do tych wynikających z ISO 27001. **W tym artykule pokazuję, jak automatycznie wdrożyć oprogramowanie anti-rootkit i antywirusowe na stacjach roboczych i serwerach z systemem Linux.**

## TLDR

Korzystając z anti-rootkita rkhunter i antywirusa ClamAV, jesteś bliżej NIS 2 i ISO 27001, a dalej od zagrożeń takich jak koparki kryptowalut i ransomware. Wdrożenie możesz zautomatyzować za pomocą Ansible.

## Plan działania

-   Przygotowanie serwera wirtualizacji Proxmox
-   Utworzenie 200 kontenerów LXC
-   Uruchomienie i konfiguracja kontenerów
-   Instalacja rkhunter i skanowanie systemów
-   Instalacja ClamAV i skanowanie systemów

## Czym jest NIS 2?

> Dyrektywa NIS 2 (Dyrektywa (UE) 2022/2555) to **akt prawny, którego celem jest osiągnięcie wysokiego wspólnego poziomu cyberbezpieczeństwa** w całej Unii Europejskiej. Państwa członkowskie muszą zapewnić, aby podmioty kluczowe i ważne stosowały odpowiednie i proporcjonalne środki techniczne, operacyjne i organizacyjne w celu **zarządzania ryzykiem dla bezpieczeństwa sieci i systemów informatycznych** oraz zapobiegania incydentom lub **minimalizowania ich wpływu** na odbiorców ich usług i na inne usługi. Środki te muszą opierać się na podejściu uwzględniającym wszystkie zagrożenia.
> 
> źródło: [https://www.nis-2-directive.com/](https://www.nis-2-directive.com/)

Poza tym, że jest regulacją prawną UE, NIS 2 może przynieść korzyści z punktu widzenia bezpieczeństwa. Jednak brak zgodności z regulacjami NIS 2 spowoduje znaczne straty w budżecie organizacji.

> **Brak zgodności z NIS2 może prowadzić do znaczących kar**. Podmioty kluczowe mogą zostać ukarane grzywną do 10 mln euro lub 2% globalnego obrotu, a podmioty ważne – do 7 mln euro lub 1,4%. Istnieje także przepis, który czyni kadrę zarządzającą osobiście odpowiedzialną za zaniedbania w zakresie cyberbezpieczeństwa.
> 
> źródło: [https://metomic.io/resource-centre/a-complete-guide-to-nis2](https://metomic.io/resource-centre/a-complete-guide-to-nis2)

## Jakie są główne założenia NIS 2?

Aby wdrożyć NIS 2, trzeba będzie objąć różne obszary dotyczące technologii i jej eksploatacji, takie jak:

-   Przeprowadzenie oceny ryzyka
-   Wdrożenie środków bezpieczeństwa
-   Zapewnienie bezpieczeństwa łańcucha dostaw
-   Opracowanie planu reagowania na incydenty
-   Regularne podnoszenie świadomości i szkolenia z cyberbezpieczeństwa
-   Regularny monitoring i raportowanie
-   Planowanie i przeprowadzanie regularnych audytów
-   Dokumentowanie procesów (w tym DRS, BCP itp.)
-   Utrzymywanie zgodności poprzez przeglądy i doskonalenie w celu osiągnięcia kompletności

## Kto powinien się tym zainteresować?

Ponieważ wdrożenie wymagań NIS 2 wpływa na całe przedsiębiorstwo, zainteresowanie powinno dotyczyć różnych działów organizacji – nie tylko IT, ale technologii w ogóle, a także biznesu i operacji. Pracownicy będą musieli brać udział w szkoleniach z zakresu świadomości cyberbezpieczeństwa. Innymi słowy, NIS 2 wpływa na całą organizację.

## Jak zdefiniować bezpieczeństwo stacji roboczych i serwerów

**Stację roboczą** możemy zdefiniować jako komputer stacjonarny lub laptop, do którego użytkownik ma fizyczny dostęp. Z kolei **serwer** możemy zdefiniować jako jednostkę obliczeniową, której zadaniem jest odciążenie stacji roboczych oraz zapewnienie możliwości pracy wielu użytkowników. Serwerem możemy więc nazwać także maszynę wirtualną lub instancję kontenera systemowego (np. LXC).

Koncepcje bezpieczeństwa stacji roboczych i serwerów są w zasadzie takie same, ponieważ **mają wiele wspólnego**. Na obu działa jakiś system operacyjny z jakimś jądrem. Na obu działa oprogramowanie systemowe oraz oprogramowanie użytkowe. Oba są podatne na złośliwy ruch, oprogramowanie i przychodzące dane, zwłaszcza w postaci stron internetowych. Istnieje jednak zasadnicza różnica, która najbardziej dotyczy użytkowników stacji roboczych. Jest to większa zmienność zadań wykonywanych na komputerze. Jednak nawet przy mniej zmiennym charakterze zadań serwerowych, ukryta natura instancji serwerowych może prowadzić do braku widoczności oczywistych zagrożeń.

Zarówno stacja robocza, jak i serwer powinny więc mieć uruchomione **EDR (Endpoint Detection and Response) albo oprogramowanie antywirusowe oraz anti-rootkit**. Dyski komputerów powinny być szyfrowane za pomocą LUKS (lub BitLockera w przypadku Windows). Użytkownicy powinni pracować na kontach z minimalnymi uprawnieniami, nie łączyć się z nieznanymi sieciami bezprzewodowymi i nie podłączać nieznanych urządzeń do portów komputera (np. urządzeń USB, które mogą być na przykład keyloggerami).

## Przygotowanie 200 kontenerów LXC na serwerze Proxmox

Dowiedz się, jak zainstalować **200 kontenerów LXC** do celów testowych, a następnie, za pomocą Ansible, jak zainstalować i uruchomić oprogramowanie anti-rootkit i antywirusowe – odpowiednio rkhunter i ClamAV. Możesz zapytać, po co testować na tak wielu kontenerach? W przypadku automatyzacji konieczne jest sprawdzenie wydajności na zdalnych hostach oraz tego, jak identyfikujemy wyniki automatyzacji po naszej stronie. W naszym przypadku te 200 kontenerów zostanie umieszczonych na jednym węźle Proxmox, więc kluczowe jest sprawdzenie, czy poradzi on sobie z taką ich liczbą.

Pakiet Ansible daje nam **możliwość automatyzacji pracy** poprzez definiowanie „playbooków”, czyli grup zadań korzystających z różnych komponentów integracyjnych. Oprócz uruchamiania playbooków możesz także uruchamiać polecenia bez definicji w plikach. Możesz na przykład użyć modułu shell i wysyłać polecenia do zdalnych hostów. Dostępna jest szeroka gama rozszerzeń Ansible.

### Przygotowanie systemu

Aby zacząć korzystać z Ansible z Proxmoxem, musisz zainstalować pakiet Pythona „proxmoxer”. Do tego potrzebny jest Python PIP.

```bash
apt update
apt install pip
pip install proxmoxer
```

Aby zainstalować Ansible (w Ubuntu):

```bash
sudo apt-add-repository ppa:ansible/ansible
sudo apt update
sudo apt install ansible
```

Następnie w /etc/ansible/ansible.cfg ustaw poniższe ustawienie, które pomija sprawdzanie klucza hosta podczas połączenia SSH.

```ini
[defaults]
host_key_checking = False
```

### Tworzenie kontenerów

Następnie **zdefiniuj playbook do instalacji kontenerów**. Musisz przekazać dane API Proxmoxa, konfigurację sieci, magazyn dyskowy oraz nazwę wybranego szablonu systemu operacyjnego. Użyłem Ubuntu 22.04, który znajduje się w magazynie o nazwie „local”. Jako docelowy magazyn dla kontenerów wybrałem „vms1” z 1 GB przestrzeni na każdy kontener. Iteruję od 20 do 221.

Inventory dla tego playbooka powinno zawierać wyłącznie serwer Proxmox, na którym zainstalujemy 200 kontenerów LXC.

```yaml
---
- name: Proxmox API
  hosts: proxmox-box
  vars:
    ansible_ssh_common_args: '-o ServerAliveInterval=60'
  serial: 1
  tasks:
  - name: Create new container with minimal options
    community.general.proxmox:
      node: lab
      api_host: 192.168.2.10:8006
      api_user: root@pam
      api_token_id: root-token
      api_token_secret: TOKEN-GOES-HERE
      password: PASSWORD-GOES-HERE
      hostname: "container-{{ item }}"
      ostemplate: 'local:vztmpl/ubuntu-22.04-standard_22.04-1_amd64.tar.zst'
      force: true
      disk: "vms1:1"
      netif:
        net0: "name=eth0,gw=192.168.1.1,ip=192.168.2.{{item}}/22,bridge=vmbr0"
      cores: 2
      memory: 4000
    loop: "{{ range(20, 221) }}"
```

A następnie uruchom ten playbook, aby zainstalować kontenery:

```bash
ansible-playbook containers-create.yml -i inventory.ini -u root
```

### Uruchomienie i konfiguracja kontenerów

Aby uruchomić nowo utworzone kontenery (uruchom to na serwerze Proxmox), użyj pętli powłoki z poleceniem pct:

```text
for i in `pct list | grep -v "VMID" | cut -d " " -f1 `; 
do 
  pct start $i; 
  echo $i; 
done
```

Do wygenerowania adresów IP dla kontenerów możesz posłużyć się narzędziem „prips”:

```bash
apt install prips
prips 192.168.2.0/24 > hosts.txt
```

**Wyłącznie do celów demonstracyjnych:** następnie włączasz logowanie użytkownika root przez SSH, ponieważ jest to jak dotąd nasz jedyny użytkownik i nie może się zalogować. Na co dzień powinieneś używać użytkownika bez uprawnień administracyjnych. Użyj pętli powłoki i polecenia „pct”:

```bash
for i in `pct list | grep -v "VMID" | cut -d " " -f1 `; 
do 
  pct exec $i -- sed -i 's/#PermitRootLogin prohibit-password/PermitRootLogin yes/g' /etc/ssh/sshd_config; 
  echo $i; 
done

for i in `pct list | grep -v "VMID" | cut -d " " -f1 `; 
do 
  pct exec $i -- service ssh restart; 
  echo $i; 
done
```

Punkt kontrolny: **Do tej pory utworzyliśmy, uruchomiliśmy i skonfigurowaliśmy 200 kontenerów LXC, gotowych do dalszej instalacji oprogramowania.**

## rkhunter: wdrożenie oprogramowania anti-rootkit

Możesz zapytać, czy ten anti-rootkit to rzeczywisty przypadek użycia? Zdecydowanie tak. Z własnego doświadczenia mogę powiedzieć, że nawet korzystając (a raczej zwłaszcza korzystając) z dobrze znanych marek dla warstwy systemowej, takich jak operatorzy chmury publicznej, możesz zetknąć się z ryzykiem otwartych podatności. Operatorzy chmury czy inni dostawcy usług cyfrowych często polegają na treściach od zewnętrznych dostawców. W efekcie jakość i poziom bezpieczeństwa są tak dobre, jak to, co dostarczyły te podmioty zewnętrzne. Możesz spodziewać się nieaktualnego i niezałatanego oprogramowania, otwartych kont użytkowników itp. Może to prowadzić do włamań do systemów, a te z kolei do **kradzieży danych, ransomware, oprogramowania szpiegującego lub kopania kryptowalut** i wielu innych.

Między oprogramowaniem anti-rootkit a antywirusowym istnieją podobieństwa. rkhunter jest znacznie bardziej ukierunkowany na konkretne przypadki użycia, więc zamiast sprawdzać setki tysięcy sygnatur wirusów, szuka setek dobrze znanych oznak obecności rootkitów w systemie. Można więc powiedzieć, że jest to wyspecjalizowana forma oprogramowania antywirusowego.

### Instalacja anti-rootkita

Najpierw **zainstaluj** rkhunter za pomocą poniższego playbooka:

```yaml
---
- name: install rkhunter
   hosts: all
   tasks:
     - name: Install rkhunter Ubuntu
       when: ansible_distribution == "Ubuntu"
       ansible.builtin.apt:
         name: rkhunter
         state: present
     - name: Install epel-release CentOS
       when: ansible_distribution == "CentOS"
       ansible.builtin.yum:
         name: epel-release
         state: present
     - name: Install rkhunter CentOS
       when: ansible_distribution == "CentOS"
       ansible.builtin.yum:
         name: rkhunter
         state: present
```

Uruchom go za pomocą Ansible:

```bash
ansible-playbook rkhunter-install.yml -i hosts.txt -u root
```

### Skanowanie systemów anti-rootkitem

A następnie **przeskanuj** systemy rkhunterem:

```yaml
---
- name: Run rkhunter
   hosts: all
   tasks:
     - name: Run rkhunter
       ansible.builtin.command: rkhunter -c --sk -q
       register: rkrun
       ignore_errors: true
       failed_when: "rkrun.rc not in [ 0, 1 ]"
```

Uruchom go za pomocą Ansible:

```bash
ansible-playbook rkhunter-run.yml -i hosts.txt -u root
```

Aby **zweryfikować wyniki**, znacznie łatwiej jest uruchomić to osobno poleceniem ansible zamiast ansible-playbook, które uruchamia playbooki:

```bash
ansible all -i hosts.txt -m shell -a "cat /var/log/rkhunter.log | grep Possible | wc -l" -u root -f 12 -o
```

### Interpretacja wyników i reakcja

Co zrobić, jeśli zobaczysz jakieś „Possible rootkits”? Przede wszystkim zachowaj spokój i postępuj zgodnie z procedurą zarządzania incydentami, jeśli taką masz.

```text
192.168.2.23 | CHANGED | rc=0 | (stdout) 0
192.168.2.31 | CHANGED | rc=0 | (stdout) 0
192.168.2.26 | CHANGED | rc=0 | (stdout) 0
192.168.2.29 | CHANGED | rc=0 | (stdout) 0
192.168.2.24 | CHANGED | rc=0 | (stdout) 0
192.168.2.27 | CHANGED | rc=0 | (stdout) 0
192.168.2.22 | CHANGED | rc=0 | (stdout) 0
192.168.2.28 | CHANGED | rc=0 | (stdout) 0
192.168.2.21 | CHANGED | rc=0 | (stdout) 0
192.168.2.20 | CHANGED | rc=0 | (stdout) 0
192.168.2.25 | CHANGED | rc=0 | (stdout) 0
```

Jeśli nie masz odpowiedniej procedury, postępuj zgodnie z podstawową ścieżką eskalacji w swoim zespole inżynierskim. Zanim odizolujesz potencjalnie zainfekowany system, najpierw sprawdź, czy nie jest to fałszywy alarm. Jest wiele sytuacji, w których narzędzia takie jak rkhunter wykryją coś nietypowego. Może to być proces Zabbix Proxy z jakimś wyrównaniem pamięci albo skrypt zastępujący podstawowe narzędzia systemowe, takie jak wget. Jeśli jednak rkhunter znajdzie dobrze znany rootkit, powinieneś zacząć wyłączać system lub przynajmniej go odizolować. Albo podjąć inne zaplanowane działanie na takie sytuacje.

Jeśli znalazłeś pojedynczą infekcję w swoim środowisku, istnieje duże prawdopodobieństwo, że inne systemy również mogą być zainfekowane, i powinieneś być gotów przeskanować wszystko, do czego masz tam dostęp, zwłaszcza jeśli masz połączenia bezhasłowe między serwerami. Więcej o możliwych scenariuszach znajdziesz w bazie wiedzy i frameworku MITRE ATT&CK.

## ClamAV: wdrożenie antywirusa

Jaki jest cel posiadania antywirusa w systemach? Podobnie jak oprogramowanie anti-rootkit, narzędzie antywirusowe chroni nasz system przed popularnymi zagrożeniami, takimi jak malware, adware, keyloggery itp. Ma jednak znacznie więcej sygnatur i skanuje wszystko, więc pełne skanowanie trwa dużo dłużej niż w przypadku oprogramowania anti-rootkit.

### Instalacja antywirusa

Najpierw zainstaluj ClamAV za pomocą poniższego playbooka:

```yaml
---
- name: ClamAV
  hosts: all
  vars:
    ansible_ssh_common_args: '-o ServerAliveInterval=60'

  tasks:
     - name: Install ClamAV
       when: ansible_distribution == "Ubuntu"
       ansible.builtin.apt:
         name: clamav
         state: present
     - name: Install epel-release CentOS
       when: ansible_distribution == "CentOS"
       ansible.builtin.yum:
         name: epel-release
         state: present
     - name: Install ClamAV CentOS
       when: ansible_distribution == "CentOS"
       ansible.builtin.yum:
         name: clamav
         state: present
```

Następnie uruchom ten playbook:

```bash
ansible-playbook clamav-install.yml -i hosts.txt -u root
```

Na każdym hoście z ClamAV działa usługa clamav-freshclam, która służy do lokalnej aktualizacji baz sygnatur wirusów. Obowiązują limity zapytań. Zalecane jest postawienie prywatnego mirrora za pomocą narzędzia „cvdupdate”. Jeśli zostawisz to tak, jak jest, może pojawić się problem, gdy wszystkie hosty zapytają jednocześnie, co skutkuje sytuacją wyścigu. Zostaniesz wtedy zablokowany na pewien czas. Jeśli Twoja infrastruktura składa się z różnych dostawców, powinieneś postawić kilka prywatnych mirrorów.

### Skanowanie systemów antywirusem

Możesz przeskanować konkretny katalog albo cały system plików. Skanowanie możesz uruchomić z playbooka, ale możesz też uruchomić je od ręki poleceniem ansible, bez pisania playbooka. Wygląda na to, że antywirus ClamAV, w przeciwieństwie do rkhuntera, zwraca mniej ostrzeżeń, dzięki czemu znacznie łatwiej jest ręcznie interpretować wyniki bez polegania na kodach powrotu.

```bash
ansible all -i hosts.txt -m shell -a "clamscan --infected -r /usr | grep Infected" -v -f 24 -u root -o
```

Możesz także uruchomić ClamAV z pominięciem katalogów /proc i /sys, które zawierają wirtualny system plików służący komunikacji między sprzętem a oprogramowaniem.

```text
clamscan --exclude-dir=/proc/* --exclude-dir=/sys/* -i -r /
```

Istnieje możliwość zainstalowania ClamAV jako usługi systemowej (demona), jednak będzie to znacznie trudniejsze do osiągnięcia, ponieważ mogą wystąpić trudności z AppArmorem (lub podobnym rozwiązaniem) i uprawnieniami do plików. Będzie to losowo obciążać systemy, czego niekoniecznie chcielibyśmy doświadczać. Zamiast tego możesz woleć umieścić skanowania w harmonogramie crona.

*Uwaga: nie będę Cię namawiał do wyłączenia AppArmora, ponieważ byłoby to sprzeczne z NIS 2. Co więcej, zachęcam do nauczenia się, jak radzić sobie z AppArmorem i SELinuksem, ponieważ są one wymagane przez różne standardy, takie jak DISA STIG.*

Do uruchomienia demona ClamAV wymagana jest obecność w systemie głównej bazy wirusów. Jej brak uniemożliwia start tej usługi i jest to bezpośrednio powiązane z usługą freshclam.

```text
○ clamav-daemon.service - Clam AntiVirus userspace daemon
     Loaded: loaded (/lib/systemd/system/clamav-daemon.service; enabled; vendor preset: enabled)
    Drop-In: /etc/systemd/system/clamav-daemon.service.d
             └─extend.conf
     Active: inactive (dead)
  Condition: start condition failed at Mon 2024-09-02 15:24:40 CEST; 1s ago
             └─ ConditionPathExistsGlob=/var/lib/clamav/main.{c[vl]d,inc} was not met
       Docs: man:clamd(8)
             man:clamd.conf(5)
             https://docs.clamav.net/
```

### Interpretacja wyników i reakcja

Uruchomienie clamscan da nam takie przykładowe wyniki:

```text
Using /etc/ansible/ansible.cfg as config file
192.168.2.33 | CHANGED | rc=0 | (stdout) Infected files: 0
192.168.2.23 | CHANGED | rc=0 | (stdout) Infected files: 0
192.168.2.28 | CHANGED | rc=0 | (stdout) Infected files: 0
192.168.2.42 | CHANGED | rc=0 | (stdout) Infected files: 0
192.168.2.26 | CHANGED | rc=0 | (stdout) Infected files: 0
192.168.2.29 | CHANGED | rc=0 | (stdout) Infected files: 0
192.168.2.38 | CHANGED | rc=0 | (stdout) Infected files: 0
192.168.2.45 | CHANGED | rc=0 | (stdout) Infected files: 0
192.168.2.40 | CHANGED | rc=0 | (stdout) Infected files: 0
192.168.2.32 | CHANGED | rc=0 | (stdout) Infected files: 0
```

Ponieważ jest to skanowanie ręczne, identyfikacja potencjalnych zagrożeń będzie prosta. W przypadku skanowania automatycznego lub integracji z Zabbixem trzeba będzie poznać, co clamscan może zwracać na wyjściu – tak samo jak w przypadku wyników rkhuntera.

## Podsumowanie

Automatyzacja w postaci Ansible może znacznie pomóc we wdrażaniu oprogramowania anti-rootkit i antywirusowego – odpowiednio rkhunter i ClamAV. Narzędzia te z pewnością podniosą poziom bezpieczeństwa w Twoim środowisku, jeśli obejmą wszystkie działające systemy. Sama automatyzacja nie jest bezpośrednio wymagana przez NIS 2, jednak ma pozytywny wpływ na przyszłe wykorzystanie.

## Dalsza lektura

-   [pve.proxmox.com/wiki/Linux\_Container](https://pve.proxmox.com/wiki/Linux_Container)
-   [ansible.com](https://www.ansible.com)
-   [sourceforge.net/projects/rkhunter](https://sourceforge.net/projects/rkhunter)
-   [clamav.net](https://www.clamav.net)
