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 ; exitSaving configuration to '/config/config.boot'...Doneexit
· 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; exitSaving configuration to '/config/config.boot'...Doneexitubnt@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 bgpubnt@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; exitSaving configuration to '/config/config.boot'...Doneexit
· Kontrola routeru R1 ještě jednou a vidíme routy, které jsou propagovány z peeru R2.
ubnt@R1:~$ show ip route bgpCodes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - ISIS, B - BGP, > - selected route, * - FIB routeB>* 0.0.0.0/0 [20/0] via 203.0.113.1, eth2, 00:00:03B>* 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 summaryRoute Source Routes FIBconnected 3 3static 3 2ebgp 405543 405541ibgp 0 0------Totals 405549 405546