Super User

Super User

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;
ipsec start

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
include /etc/ipsec.d/*.secrets

1.2.3.4 5.6.7.8 : PSK
'b64-stringvygenerovanypomociopenssl'

Nyní si vytvoříme konfigurační soubor v /etc/ipsec.d/vtitunnel-vti01.conf, ve kterém nakonfigurujeme náš VTI tunnel:

@ab04

# /etc/ipsec.d/vtitunnel-vti01.conf
conn vtiab04
   # Libreswan používá k popisu koncových bodů termíny
"left" a      "right".
   left=
1.2.3.4
   right=
5.6.7.8
   authby=secret
   leftsubnet=
0.0.0.0/0
   rightsubnet=
0.0.0.0/0
   auto=add
   # VPN založená na směrování vyžaduje označení a rozhraní
   mark=
5/0xffffffff
   vti-interface=vti01
   # nenastavovat směrování, protože nechceme posílat
0.0.0.0/0 přes tunel.
   vti-routing=no

    # interní IP adresa
   leftvti=
192.168.50.40/24

@ab05

# /etc/ipsec.d/vtitunnel-vti01.conf

conn vtiab05
   # Libreswan používá k popisu koncových bodů termíny
"left" a      "right".
   left=
5.6.7.8
   right=
1.2.3.4
   authby=secret
   leftsubnet=
0.0.0.0/0
   rightsubnet=
0.0.0.0/0
   auto=add
   # VPN založená na směrování vyžaduje označení a rozhraní
   mark=
5/0xffffffff
   vti-interface=vti01
   # nenastavovat směrování, protože nechceme posílat
0.0.0.0/0 přes tunel.
   vti-routing=no

    # interní IP adresa
   leftvti=
192.168.50.50/24

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
002
"vtiab04" #7: initiating Child SA using IKE SA #5
188
"vtiab04" #7: sent CREATE_CHILD_SA request for new IPsec SA
004
"vtiab04" #7: established Child SA; IPsec tunnel [0.0.0.0-255.255.255.255:0-65535 0] -> [0.0.0.0-255.255.255.255:0-65535 0] {ESP=>0x46fd4964 <0x26b3df1f xfrm=AES_CTR_128-HMAC_SHA2_512_256-MODP2048 NATOA=none NATD=none DPD=passive}

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

# ping 192.168.50.50
PING 192.168.50.50 (192.168.50.50) 56(84) bytes of data.
64 bytes from 192.168.50.50: icmp_seq=1 ttl=64 time=290 ms
64 bytes from 192.168.50.50: icmp_seq=2 ttl=64 time=288 ms
64 bytes from 192.168.50.50: icmp_seq=3 ttl=64 time=288 ms
64 bytes from 192.168.50.50: icmp_seq=4 ttl=64 time=288 ms

@ab05

# ping 192.168.50.40
PING 192.168.50.40 (192.168.50.40) 56(84) bytes of data.
64 bytes from 192.168.50.40: icmp_seq=1 ttl=64 time=289 ms
64 bytes from 192.168.50.40: icmp_seq=2 ttl=64 time=293 ms
64 bytes from 192.168.50.40: icmp_seq=3 ttl=64 time=288 ms
64 bytes from 192.168.50.40: icmp_seq=4 ttl=64 time=288 ms

Jakmile pakety projdou, máme úspěšně vytvořený VTI tunnel mezi “ab04” a “ab05”.

IT v praxi prezentace níže v příloze

IT Bezpečnost a auditing

CIS (centre for internet security)

SCAP (Security Content Automation Protocol)

OSSEC (Open Source SECurity)

ELK (Elastic, Logstash, Kibana)

úterý, 19 září 2017 20:48

Implementace systému - Ossec HIDS/NIDS

OSSEC řešení v.3 architektura

 

Popis výhod a změny v systému Ossec v3

 

Ossec a jeho výhody, novinka SCAP v systému logování

 

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 v3

 

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

 

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

 

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í.

 

Vizualizace změny

 

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:

 

File integrity check, Policy Monitoring, SCAP

 

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:

 

Monitorování bezpečnostní politiky

 

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

 

Komplexnost systému je také patrna z obrázku jak se změnil datový tok systému.

 

Přidání zálohy pro textové informace v JSON přímo v ossec

 

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.

 

Monitoring CIS systému v Ossec

 

Nově je také upravena verze CIS systému. Jsou to pravidla instalace nových systémů a jejich zabezpečení.

 

úterý, 19 září 2017 20:02

BGP spojení pro dva routery

EdgeRouter - Border Gateway Protocol

Příklad


Nákres mezi dvěmi BGP konfiguracemi a s dvěmi Autonomními systémy

BGP (Border Gateway Protocol)


Náčrt dvou autonomních systémů (AS)

R1: Router in AS 1

R2: Router in AS 2

Konfigurace


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:~$
 

Verifikace peeru


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
 

Naučené routy


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
 

Plné internetové routy


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
 

 

O nás

Jsme firma se silným technickým zázemím. Disponujeme zkušeným senior týmem. Naše znalosti nám dovolují vstupovat do velkých společností i nadnárodních korporací. Spolupracujeme s leadery produktů IT technologií. Věnujeme se i zabezpečení na bázi IDS/IPS systémů. Certifikace je samozřejmostí.

Search