Virtual Tunnel Interface
Zpracoval "kapka"
Virtual Tunnel Interface IPsec (VTI) je směrovatelný typ virtuálního rozhraní pro ukončení tunelů IPsec a poskytuje jednoduchý způsob, jak vytvořit zabezpečení mezi lokalitami a vytvořit překryvnou síť. Virtual Tunnel Interface IPsec zlepšují a zjednodušují konfiguraci protokolu IPsec pomocí tunelů VPN (Virtual Private Network).
ab04: Rocky Linux 8.7 (Green Obsidian)
Libreswan
Amerika
ab05: Rocky Linux 8.7 (Green Obsidian)
Libreswan
Singapore
V tomto příkladě si ukážeme VTI připojení mezi dvěma hosty “ab04” a “ab05”.
Instalování balíčku `libreswan` na obou hostech a následné spuštění IPsec:
dnf install libreswan; |
Pro autorizaci budeme v tomto příkladě používat PSK, tudíž si ho vygenerujeme pomocí `openssl` (samozřejmě nemusí být vygenerován, ale pro větší bezpečnost je to lepší):
openssl rand -base64 48 |
Vygeneruje se string např: b64-stringvygenerovanypomociopenssl, který následně vložíme do souboru ipsec.secrets na obou hostech, který se nachází v /etc/ipsec.secrets.
1.2.3.4 - Source IP
5.6.7.8 - Destination IP
Musíme myslet na správný formát:
# /etc/ipsec.secrets |
Nyní si vytvoříme konfigurační soubor v /etc/ipsec.d/vtitunnel-vti01.conf, ve kterém nakonfigurujeme náš VTI tunnel:
@ab04 # interní IP adresa @ab05 |
# /etc/ipsec.d/vtitunnel-vti01.conf conn vtiab05 # interní IP adresa |
Jakmile máme hotovou konfiguraci restartujeme IPsec na obou hostech, pomocí:
ipsec restart |
Poté se ujistěte, jestli se připojení načetlo na obou hostech:
ipsec auto --add vtiab04 ipsec auto --add vtiab05 |
Následně zapněte tunnel na obou hostech:
ipsec auto --up vtiab04 ipsec auto --up vtiab05 |
Pokud vše proběhlo v pořádku, měli byste vidět něco jako:
# ipsec auto --up vtiab04 |
na vtiab05 to samé.
Ověříme si, jestli všechno funguje tím, že si pingneme z “ab04” na “ab05” pomocí interní sítě:
@ab04 |
Jakmile pakety projdou, máme úspěšně vytvořený VTI tunnel mezi “ab04” a “ab05”.
Ossec je nyní plně integrován do systému s Elastic Stack. Nově zde přibývá důležitá kontrola CIS a SCAP, která se vyvinula do komplexnějšího řešení. Níže je uveden stručný popis těchto nástrojů.
OSSEC HIDS je hostitelský systém
detekce narušení (HIDS) používaný jak pro detekci zabezpečení, tak pro
sledování stavu a pro sledování dodržování předpisů. Je založen na
multiplatformním agentu, který předává požadované údaje (např. Protokolové
zprávy, hash souborů a zjištěné anomálie) centrálnímu správci, kde je dále
analyzován a zpracováván, což vede k bezpečnostním výstrahám. Agenti předávají
data události centrálnímu manažerovi prostřednictvím zabezpečeného a ověřeného
kanálu.
OSSEC HIDS navíc poskytuje centralizovaný server syslog a systém pro monitorování konfigurace bez agenta, který poskytuje bezpečnostní informace o událostech a změnách na zařízeních bez prostředku, jako jsou brány firewall, přepínače, směrovače, přístupové body, síťové zařízení atd.
Nově je vylepšena část systému pro komunikaci s ELK, kde je komunikace prováděna ve formátu JSON, který nahrazuje syslog. Tento formát má výhodu v tom, že drží všechny informace od vzniku v systému, až po jeho uložení do systému ELK. Znamená to pak více vizualizací a také přehledný odhad příchozích problémů. Je to veliká a podstatná výhoda pro další zpracování v systému.
SCAP je dlouho známý systém, který se teď nově implementuje do systému Ossec. Zajišťuje implementaci protokolu OVAL (Open Vulnerability Assessment Language) a XCCDF (Extensible Configuration Checklist Description Format). Slouží ke kontrole konfigurace systému a detekci zranitelných aplikací. Tento systém podporuje RedHat/Centos přímo ve svých distribucích.
Je to dobře známý nástroj určený k ověření shody s bezpečnostními požadavky jednotlivých OS a obrany systémů pomocí průmyslových bezpečnostních standardů pro podniková prostředí.
Elastic Stack je softwarová sada (Logstash, Elasticsearch, Kibana), která slouží k shromažďování, analyzování, indexování, ukládání, vyhledávání a zobrazování dat protokolu. Poskytuje webový frontend užitečný pro získání přehledného zobrazení událostí na vysoké úrovni a také pro realizaci pokročilé analýzy a uchování dat hluboko ve vašem úložišti událostí.
Nově po vygenerování správcem jsou výstrahy odeslány do složky Elastic Stack, kde jsou obohaceny například informacemi o geolokaci atd. a zaindexovány. Kibanu lze pak použít k vyhledávání, analýze a vizualizaci dat. Viz níže:
Systém také zavádí nové monitorovací aktivity a je zde
patrné, jak je propojen ossec z Elastic stackem.
Je to vidět na přiloženém obrázku:
SCAP je standardizované řešení kontroly souladu pro podnikovou infrastrukturu. Jedná se o řadu specifikací, které udržuje Národní institut pro normy a technologie (NIST) za účelem zajištění bezpečnosti podnikových systémů.
OpenSCAP je nástroj auditu, který využívá Formát popisného seznamu (XCCDF) pro rozšíření konfigurace. XCCDF je standardním způsobem vyjádření obsahu kontrolního seznamu a definuje kontrolní seznamy zabezpečení. V kombinaci s dalšími specifikacemi, jako jsou CPE, CVE, CCE a OVAL, vytváří kontrolní seznam ve SCAP, který je zpracován ověřeným řešení SCAP.
Všechny účty s prázdnými hesly by měly být okamžitě zakázány a konfigurace PAM by měla zabránit tomu, aby uživatelé mohli přiřadit prázdná hesla.
Kontroly SCAP se provádějí pravidelně (výchozí je jednou za den) a výsledky jsou nastaveny na server Ossec, kde jsou zpracovávány dekodéry a pravidly OpenSCAP. Níže je uveden příklad výstrahy vygenerované, když zásady auditu Linux (auditd) nejsou nakonfigurovány pro sledování uživatelských akcí:
Ossec WUI lze navíc použít k vizualizaci a analýze výsledků sledování
Komplexnost systému je také patrna z obrázku jak se změnil datový tok systému.
Nově jsou přidány zálohy dat JSON v textovém režimu pro obnovení Elastic stacku. Data jsou pak možné použít pro znovu oživení Elastic stacku. Jsou umístěny v těchto adresářích.
Soubor /var/ossec/logs/archives/archives.json zálohovány jsou všechny události v systému.
Soubor /var/ossec/logs/alerts/alerts.json má všechy aktuální eventy do elasticsearch.
Nově je také upravena verze CIS systému. Jsou to pravidla instalace nových systémů a jejich zabezpečení.
Nákres mezi dvěmi BGP konfiguracemi a s dvěmi Autonomními systémy
Náčrt dvou autonomních systémů (AS)
R1: Router in AS 1
R2: Router in AS 2
Poznámka: Přidělené IP adresy pro dva routery:
R1 IP address: 192.0.2.1
R2 IP address: 203.0.113.1
· Základní konfigurace routeru R1 v AS 1. Užívá parametry druhého routeru jako cílový router R2 v AS 2:
ubnt@R1:~$ configure
[edit]
ubnt@R1# set protocols bgp 1 parameters router-id 192.0.2.1
[edit]
ubnt@R1# set protocols bgp 1 neighbor 203.0.113.1 remote-as 2
[edit]
ubnt@R1# commit
[ protocols bgp 1 ]
Starting routing daemon: bgpd.
[edit]
ubnt@R1# save ; exit
Saving configuration to '/config/config.boot'...
Done
exit
· Základní konfigurace routeru R2 v AS 2. Užívá parametry prvního routeru R1 in AS 1:
ubnt@R2:~$ configure
[edit]
ubnt@R2# set protocols bgp 2 parameters router-id 203.0.113.1
[edit]
ubnt@R2# set protocols bgp 2 neighbor 192.0.2.1 remote-as 1
[edit]
ubnt@R2# commit
[ protocols bgp 2 ]
Starting routing daemon: bgpd.
[edit]
ubnt@R2# save; exit
Saving configuration to '/config/config.boot'...
Done
exit
ubnt@R2:~$
Pro verifikaci užíváme příkaz „show ip bgp neighbors” jestli máme protější stranu (peera) ve stavu established.
ubnt@R1:~$ show ip bgp neighbors
BGP neighbor is 203.0.113.1, remote AS 2, local AS 1, external link
BGP version 4, remote router ID 203.0.113.1
BGP state = Established, up for 00:00:13
Last read 00:55:04, hold time is 180, keepalive interval is 60 seconds
Neighbor capabilities:
4 Byte AS: advertised and received
Route refresh: advertised and received(old & new)
Address family IPv4 Unicast: advertised and received
Message statistics:
Inq depth is 0
Outq depth is 0
Sent Rcvd
Opens: 7 1
Notifications: 0 0
Updates: 0 0
Keepalives: 2 1
Route Refresh: 0 0
Capability: 0 0
Total: 9 2
Minimum time between advertisement runs is 30 seconds
Update source is 192.0.2.1
For address family: IPv4 Unicast
Community attribute sent to this neighbor(both)
0 accepted prefixes
Connections established 1; dropped 0
Last reset never
Local host: 192.0.2.1, Local port: 60047
Foreign host: 203.0.113.1, Foreign port: 179
Nexthop: 192.0.2.1
Nexthop global: fe80::de9f:dbff:fe29:5f7
Nexthop local: ::
BGP connection: non shared network
Read thread: on Write thread: off
Po té musíme zkontrolovat pomocí parametru „show” router R1 jestli má dostupné routy. Pro redistibuci musíme použít spravný příkaz.
· Použíjte příkaz „show ip route bgp” pro kontrolu routeru R1 zda má bgp routy z peeru R2 přístupny.
ubnt@R1:~$ show ip route bgp
ubnt@R1:~$
· Žádné routy nejsou posílány. Na routeru R2, musíme použít příkaz redistribuce statických route:
ubnt@R2:~$ configure
[edit]
ubnt@R2# set protocols bgp 2 redistribute static
[edit]
ubnt@R2# commit
[edit]
ubnt@R2# save; exit
Saving configuration to '/config/config.boot'...
Done
exit
· Kontrola routeru R1 ještě jednou a vidíme routy, které jsou propagovány z peeru R2.
ubnt@R1:~$ show ip route bgp
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
I - ISIS, B - BGP, > - selected route, * - FIB route
B>* 0.0.0.0/0 [20/0] via 203.0.113.1, eth2, 00:00:03
B>* 1.0.0.0/24 [20/0] via 203.0.113.1, eth2, 00:00:03
Poznámka: Pro příjem plných route je potřeba aby zařízení mělo dostatek paměti pro provoz všech route. Je doporučeno mít minimálně 512 MB RAM, optimum pro provoz je 768 MB. V našem případě používáme 2GB RAM paměti.
Po té je vhodné pro test použít tento příkaz a to počet route v systému „show ip route summary”.
admin@ubnt-bgp-test:~$ show ip route summary
Route Source Routes FIB
connected 3 3
static 3 2
ebgp 405543 405541
ibgp 0 0
------
Totals 405549 405546