Jest to kontynuacja poprzedniego wpisu. Tym razem przyjrzymy się zakładce Detections w Elastic SIEM. Naszym celem jest automatyzacja wykrywania IOC wykorzystując sprawdzone reguły. Przypomnijmy: Zainstalowaliśmy Elasticsearch + Kibana na jednej z maszyn. Monitorujemy maszynę z Ubuntu (Auditbeat, Filebeat, Packetbeat) i Windows 10 (Winlogbeat), choć w tym wpisie skupimy się na tej drugiej.
Jak odblokować Detections w Elastic SIEM?
Według dokumentacji należy:
- Zapewnić komunikacje Elasticsearch – Kibana po TLS
- Włączyć xpack.security w Elasticsearch
- Skonfigurować xpack.encryptedSavedObjects.encryptionKey w Kibanie
Konfiguracja security w Elasticsearch
W tym przypadku mamy jedno-węzłowy klaster Elasticsearch, więc wystarczy tylko dopisać na koniec pliku /etc/elasticsearch/elasticsearch.yml linijkę
xpack.security.enabled: true
i zrestartować serwis Elasticsearch
service elasticsearch restart
Uwaga: W przypadku normalnego klastra nie będzie tak łatwo. Trzeba zabezpieczyć komunikację między węzłami. Tutaj znajdziesz szczegóły.
Właśnie zepsuliśmy cały system zbierania logów, ponieważ od teraz wymagane jest uwierzytelnianie ?.
root@ELK:/etc/elasticsearch# curl localhost:9200?pretty
{
"error" : {
"root_cause" : [
{
"type" : "security_exception",
"reason" : "missing authentication credentials for REST request [/?pretty]",
"header" : {
"WWW-Authenticate" : "Basic realm=\"security\" charset=\"UTF-8\""
}
}
],
"type" : "security_exception",
"reason" : "missing authentication credentials for REST request [/?pretty]",
"header" : {
"WWW-Authenticate" : "Basic realm=\"security\" charset=\"UTF-8\""
}
},
"status" : 401
}
Musimy wygenerować domyślne konta oraz hasła. Służy do tego specjalne narzędzie elasticsearch-setup-passwords znajdujące się w katalogu binarek Elasticsearch czyli /usr/share/elasticsearch/bin/. Dla ułatwienia wszędzie wpisałem to samo (elastic), ale nie powtarzaj tego kroku ?.
root@ELK:/etc/elasticsearch# cd /usr/share/elasticsearch/
root@ELK:/usr/share/elasticsearch# bin/elasticsearch-setup-passwords interactive
Initiating the setup of passwords for reserved users elastic,apm_system,kibana,kibana_system,logstash_system,beats_system,remote_monitoring_user.
You will be prompted to enter passwords as the process progresses.
Please confirm that you would like to continue [y/N]y
Enter password for [elastic]:
Reenter password for [elastic]:
Enter password for [apm_system]:
Reenter password for [apm_system]:
Enter password for [kibana_system]:
Reenter password for [kibana_system]:
Enter password for [logstash_system]:
Reenter password for [logstash_system]:
Enter password for [beats_system]:
Reenter password for [beats_system]:
Enter password for [remote_monitoring_user]:
Reenter password for [remote_monitoring_user]:
Changed password for user [apm_system]
Changed password for user [kibana_system]
Changed password for user [kibana]
Changed password for user [logstash_system]
Changed password for user [beats_system]
Changed password for user [remote_monitoring_user]
Changed password for user [elastic]
Teraz Elasticsearch odpowie nam gdy przekażemy login oraz hasło.
root@ELK:/usr/share/elasticsearch# curl -u elastic:elastic localhost:9200?pretty
{
"name" : "ELK",
"cluster_name" : "siem",
"cluster_uuid" : "u6FDeHNsTmWJcnf-jYUH7Q",
"version" : {
"number" : "7.8.1",
"build_flavor" : "default",
"build_type" : "deb",
"build_hash" : "b5ca9c58fb664ca8bf9e4057fc229b3396bf3a89",
"build_date" : "2020-07-21T16:40:44.668009Z",
"build_snapshot" : false,
"lucene_version" : "8.5.1",
"minimum_wire_compatibility_version" : "6.8.0",
"minimum_index_compatibility_version" : "6.0.0-beta1"
},
"tagline" : "You Know, for Search"
}
Musimy też “naprawić” Kibanę dodając login i hasło do /etc/kibana/kibana.yml
...
elasticsearch.username: "kibana_system"
elasticsearch.password: "elastic"
...
Konfiguracja TLS między Elasticsearch i Kibana
Do konfiguracji TLS potrzebne jest nam CA i certyfikat. Jeśli masz swoje PKI – świetnie – jeśli nie masz, to trzeba wygenerować CA. Elasticsearch ma do tego specjalne narzędzie elasticsearch-certutil, które ułatwi ten proces.
root@ELK:/usr/share/elasticsearch# ./bin/elasticsearch-certutil ca
This tool assists you in the generation of X.509 certificates and certificate
signing requests for use with SSL/TLS in the Elastic stack.
The 'ca' mode generates a new 'certificate authority'
This will create a new X.509 certificate and private key that can be used
to sign certificate when running in 'cert' mode.
Use the 'ca-dn' option if you wish to configure the 'distinguished name'
of the certificate authority
By default the 'ca' mode produces a single PKCS#12 output file which holds:
* The CA certificate
* The CA's private key
If you elect to generate PEM format certificates (the -pem option), then the output will
be a zip file containing individual files for the CA certificate and private key
Please enter the desired output file [elastic-stack-ca.p12]:
Enter password for elastic-stack-ca.p12 :
Po wygenerowaniu CA (elastic-stack-ca.p12) możemy utworzyć certyfikat.
./bin/elasticsearch-certutil cert --ca elastic-stack-ca.p./bin/elasticsearch-certutil cert \
> --ca elastic-stack-ca.p12 \
> --dns localhost \
> --ip 127.0.0.1 \
> --out http.p12
Wygenerowany http.12 umieszczam w /etc/elasticsearch/certs/ i ustawiam prawa do folderu.
mkdir /etc/elasticsearch/certs
cp elastic-stack-ca.p12 /etc/elasticsearch/certs/
cp http.p12 /etc/elasticsearch/certs/
chown -R elasticsearch:elasticsearch /etc/elasticsearch/certs/
Teraz w /etc/elasticsearch/elasticsearch.yml możemy dodać utworzony certyfikat do komunikacji http. Jak nie pasuje Ci podawanie jawnie hasła w pliku konfiguracyjnym, jest też opcja z keystore’em.
...
xpack.security.http.ssl.enabled: true
xpack.security.http.ssl.keystore.path: "./certs/http.p12"
xpack.security.http.ssl.keystore.password: "elastic"
Po zrestartowaniu serwisu poprzedni curl nie będzie nic zwracać.
root@ELK:/etc/elasticsearch# curl -u elastic:elastic localhost:9200?pretty
curl: (52) Empty reply from server
Trzeba zmienic url na https://…, będzie jednak problem z niezaufanym CA.
root@ELK:/etc/elasticsearch# curl -u elastic:elastic https://localhost:9200?pretty
curl: (60) SSL certificate problem: self signed certificate in certificate chain
More details here: https://curl.haxx.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
…który możemy zignorować –insecure ?.
root@ELK:/etc/elasticsearch# curl -u elastic:elastic --insecure https://localhost:9200?pretty
{
"name" : "ELK",
"cluster_name" : "siem",
"cluster_uuid" : "u6FDeHNsTmWJcnf-
"version" : {
"number" : "7.8.1",
"build_flavor" : "default",
"build_type" : "deb",
"build_hash" : "b5ca9c58fb664ca8
"build_date" : "2020-07-21T16:40
"build_snapshot" : false,
"lucene_version" : "8.5.1",
"minimum_wire_compatibility_vers
"minimum_index_compatibility_ver
},
"tagline" : "You Know, for Search"
}
Naprawa Kibana – zaufanie CA
Musimy jeszcze przywrócić do porządku Kibane. Zamiast PKCS12, wciągniemy CA w postaci pliku PEM i wrzucimy go do katalogu z konfiguracją Kibana.
openssl pkcs12 -in elastic-stack-ca.p12 -out ca.pem -clcerts -noke ys
cp cert.pem /etc/kibana
chown kibana:kibana /etc/kibana/ca.pem
Teraz pozostaje nam tylko dodać wpisy do /etc/kibana/kibana.yml i zrestartować serwis kibana.
...
elasticsearch.hosts: ["https://localhost:9200"]
elasticsearch.ssl.certificateAuthorities: ["/etc/kibana/ca.pem"]
...
xpack.encryptedSavedObjects.encryptionKey: 'fhjskloppd678ehkdfdlliverpoolfcr'
Naprawa Beats’ów
Pewnie myślałeś, że to już koniec. Niespodzianka ?. Elasticsearch wymaga teraz uwierzytelniania. Pójdziemy trochę na skróty i użyjemy konta superusera i zignorujemy weryfikację CA. Nie rób tego na produkcji!
Naprawa polega na odpowiedniej konfigracji sekcji output.elasticsearch.
...
output.elasticsearch:
# Array of hosts to connect to.
hosts: ["10.0.0.4:9200"]
# Protocol - either `http` (default) or `https`.
protocol: "https"
ssl.verification_mode: "none"
# Authentication credentials - either API key or username/password.
#api_key: "id:api_key"
username: "elastic"
password: "elastic"
Plik konfiguracyjny Winlogbeat znajdziesz tutaj C:\ProgramData\Elastic\Beats\winlogbeat\winlogbeat.yml.
Zrestartować serwis Winlogbeat możesz wpisując poniższą komendę w PowerShell’u.
Restart-Service winlogbeat
Wczytanie domyślnych reguł detekcji Elastic SIEM
W końcu mamy dostęp do modułu detekcji. Możemy wczytać domyslne reguły.
Lista domyślnych reguł jest dość spora. W celu testu aktywowałem wszystkie.
Każda reguła ma opis i zależności. Część z nich wymaga funkcjonalności Machine Learning (czytaj: jest płatna).
W darmowej wersji nie mamy możliwości wysyłania powiadomień o zidentyfikowanych detekcjach.
Weryfikacja wykrywania reguł
APTSimulator
Wykorzystamy maszynę z Windows 10. Pomoże nam w tym APTSimulator. Po ściągnięciu wystarczy rozpakować i odpalić APTSimulator.bat.
![Administrator: Windows PowerSheII
l/
Florian Roth, Nextron
Sys tems, vO.
Select the test—set that you want
8.0
to run:
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
RUN EVERY TEST
Col 1 ecti on
Command and Control
Credential Access
Defense Evasion
Di s cove ry
Executi on
Lateral Movement
persistence
privilege Escalation
Apply AV Exclusions in Registry
Settings
Exit
our selection (then press ENTER) :](https://wiadrodanych.pl/wp-content/uploads/2020/08/image-30-1024x699.png)
I teraz zaskoczenie. Wygenerowane ataki nie zostały wykryte.
Konfiguracja Sysmon
Winlogbeat zbiera tyle danych, ile udostępnia mu system operacyjny. Musimy zwiększyć obszar interesujących nas zdarzeń w systemie. Sysmon jest to monitor wewnętrznej aktywności Windowsa. Jest to usługa systemowa, która śledzi aktywność systemu plików, rejestru, sieci i działających aplikacji.
Po ściągnięciu możemy przystąpić do instalacji
Sysmon64.exe -i -accepteula -h md5,sha256,imphash -l -n
W tym przypadku będziemy chcieli zbierać wszystko. W praktyce powinniśmy zastanowić się, które zdarzenia są dla nas istotne. Posłużymy się konfiguracją z projektu HELK. Tutaj link do konfiguracji.
Sysmon64.exe -c config.xml
Wykryte zagrożenia
Po ponownym odpaleniu APTSimulator już widać efekty. Oprócz samego zdarzenia, widzimy poziom ryzyka oraz skąd pochodzi informacja.
Z poziomu wykrytych reguł możemy utworzyć nowy timeline i zacząć dochodzenie.
Kurs Elastic Stack
Jestem w trakcie tworzenia kursu z Elastic Stack. Przejdziesz tam drogę od postawienia klastra, wypełnienia go danymi, zabezpieczenia, administracji i wyszukiwania. Wszystko to oparte o darmową licencję. W przyszłości planuję również rozszerzenie go o moduł związany z cyberbezpieczeństwem. Jeśli jesteś zainteresowany, kliknij tutaj.
Wnioski
Widzimy, że SIEM całkiem nieźle spisuje się już w darmowej wersji. Jest dużo wbudowanych reguł, a jeśli nam nie wystarczają, możemy dodawać własne. Niestety nie wykorzystamy funkcjonalności Machine Learning. Problematyczny jest też brak możliwości wysyłania powiadomień o detekcjach, aczkolwiek coś czuję, że można to obejść stawiając obok ElastAlert. Zgaduję, że te detekcje siedzą po prostu gdzieś w jakimś wewnętrznym indeksie.
Uwaga
Pamiętaj, że w tym artykule nie zabezpieczyliśmy komunikacji między węzłami (bo to jedno-węzłowy klaster) oraz nie zabezpieczyliśmy komunikacji HTTP Kibana <-> Klient. Nie należy też używać superusera do komunikacji z Elasticsearch’em w Beats’ach.
Co dalej?
Myślałem o pokazaniu możliwości ElastAlert + Sigma. Daj znać co o tym myślisz. Może masz jakiś pomysł?
Chciałbym zapytać, czy ElastAlert + Sigma rozszerza możliwości ‘Detections’? Czy to jest zupełnie inne rozwiązanie, które nie potrzebuje ‘Detections’? Co jest łatwiejsze w implementacji, jeżeli chodzi o wdrożenie prostych zasad korelacji?
Jest to inne rozwiązanie (czasów, gdy modulu detections nie było). Jeden i drugi pełni podobną funkcję, czyli pyta o coś klaster i jeśli spełnione są warunki to wykonuje akcje.
Łatwiej iść wg mnie w detections, ale trzeba pokombinować, aby alert wyszedł poza kibane (np. Na slacka)