Linux Netflow zdanie, niedoko czone zdanie ń

Linux Netflow
zdanie, niedokończone zdanie
Piotr Chytła <[email protected]>
Netflow - definicja
Firmowy protokół firmy Cisco Systems – patent 6,243,667.
● Opracowany przez Darena Kerra i Berry Bruinsa z Cisco Systems
w 1996 roku.
● Wersje protokołu netflow 1,5,7 (Specyficzna dla Catalyst 6500,7600),
8 (uwzględnia agregacje), 9 (najnowsza, najbardziej rozszerzalna).
●
Netflow – definicja cd.
Podstawową jednostką jaką operuje netflow jest 'flow' – przepływ lub
strumień.
● Flow – ma charakter jednokierunkowy, zdefinowowany jest przez
7 unikalnych wartości.
● Źródłowy adres IP.
● Docelowy adres IP.
● Port źródłowy.
● Port docelowy.
● Protokół warstwy transportu – TCP/UDP/ICMP/inne.
● TOS/DSCP.
● Ifindex interfejsu wejściowego.
● Odpowiada na podstawowe pytania dotyczące ruchu przechodzącego
przez sieć - kto, co, kiedy, gdzie i jak.
●
Jakie informacje udostępnia nam netflow w wersji 5?
200.0.10.20/26 ( ASN 88 )
4.5.6.7.8/24 ( ASN 66 )
Dst IP
Dst IP Dst prefix length
R1
Dst prefix length
Dst ASN
65.98.200.32/30 (ASN 99)
R2
R3
Nexthop Address
Output Interface
R4
Input Interface
Pozatym
Start/Stop sysUptime
Packet/Byte Count
Source/Destination Port (TCP,UDP)
TOS
TCP Flags
Protocol
100.0.14.56/27(ASN 100)
Src IP
Src prefix length
Src ASN
Po co potrzebujemy netflow ?
Analiza ruchu sieciowego (np. Ile wysyłamy/odbieramy ruchu
do okreśonlych numerów ASN).
● Planowanie rozbudowy sieci.
● Wykrywanie i monitorowanie ataków sieciowych,
propagacja wirusów, robaków.
● Wykrywanie ataków DDoS.
● Monitorowanie zużycia zasobów sieciowych przez określone
protokoły, porty, adresy IP, podsieci.
● Monitoring użytkowników – np. przed translacją NAT.
● Inne zastosowania.
●
Netflow na systemach OpenSource,
krótki przegląd sond Netflow.
pmacct
http://www.pmacct.net
Metoda zbierania danych o ruchu sieciowym : libpcap
●
Zalety
●
●
●
●
●
●
●
●
Export w formatach - v1/v5/v7/v8/v9.
Obsługiwane wersje IP – v4,v6.
Export danych do MySQL,PostgreSQL, SQLite, IMT (memory tables) .
Rozdzielony odbiornik - nfacctd od sondy – pmacctd.
Pluginy rozpoznające - SIP/RTSP/FTP/IRC (dla wersji v9).
Agregacje – src_mac/host/net/port/as , dst_mac/host/net/port/as/, vlan, proto,
tos – wiele innych.
Możliwość rozszerzania funkcjonalności poprzez Pluginy.
Wady
●
●
Brak exportu danych do pliku rozpoznawalnego przez flow-toolsy.
Statyczny plik zawierający mapowanie podsieci na numery ASN jest używany
jedynie przy exporcie do IMT w miejscu gdzie uruchomiona jest sonda.
fprobe/fprobe-ulog
http://fprobe.sourceforge.net
Metoda zbierania danych o ruchu sieciowym :
fprobe : libpcap
fprobe-ulog : ULOG
●
Zalety
●
●
●
●
●
●
●
●
Wady
●
Export w formatach - v1/v5/v7.
Obsługiwane wersje IP - v4.
Możliwość filtrowania ruchu przekazywanego na sondę:
● Fprobe – filtry bpf.
● Fprobe-ulog – reguły firewalla.
Fprobe jest tylko sondą, dane można eksportować np. do flow-capture z
flow-toolsów.
(fprobe-ulog) – informacje o ruchu sieciowym pobierane z natywnego
mechanizmu kernela.
fprobe-ulog) – porównywalne zużycie procesora przy pracy w kernel space,
dużo mniejsze w user land.
(fprobe-ulog ) - natywny support dla interfejsów IN/OUT.
Brak pól zawierających numery ASN, długości podsieci, adresu kolejnego
routera.
fprobe/fprobe-ulog cd.
fprobe-ulog (uruchomienie)
Iptables -A FORWARD -j ULOG – Cały ruch w łańcuchu FORWARD kierujemy do
ULOGa.
fprobe/fprobe-ulog ( wyniki )
srcIP
dstIP
prot srcPort dstPort octets
packets
85.186.1.84
87.99.51.11
17 21228 10518 129
1
Brak numerów ASN,
194.9.24.55
87.99.32.164 6 80
3748 363
3
długości podsieci
87.99.60.9
195.117.151.40 6 3846 36945 96
2
src/dst
87.99.63.100 210.42.244.156 17 2002 4677 63
1
87.99.32.167 4.79.66.194
1 0
0
112
4
87.99.63.195 85.221.182.192 17 4672 4672 34
1
87.99.62.52
24.99.36.14
17 30221 3362 55
1
87.99.63.97
79.113.16.238 17 47053 15323 244
2
[..]
srcIP
dstIP
prot srcAS dstAS octets
packets
85.186.1.84/0
87.99.51.11/0
17 0
0
129
1
194.9.24.55/0
87.99.32.164/0 6 0
0
363
3
87.99.60.9/0
195.117.151.40/0 6 0
0
96
2
87.99.63.100/0 210.42.244.156/0 17 0
0
63
1
87.99.32.167/0 4.79.66.194/0
1 0
0
112
4
87.99.63.195/0 85.221.182.192/0 17 0
0
34
1
87.99.62.52/0
24.99.36.14/0
17 0
0
55
1
87.99.63.97/0
79.113.16.238/0 17 0
0
244
2
fprobe/fprobe-ulog cd.
fprobe
Przepustowość
fprobe-ulog
CPU
PPS
● 6kpps utrzymujące się w godz. 12-23.
PPS
● 8kpps w szczycie.
Softflowd
http://mindrot.org/projects/softflowd/
Metoda zbierania danych o ruchu sieciowym : libpcap
●
Zalety
●
●
●
●
●
●
●
●
●
Wady
●
●
Export w formatach - v1/v5/v9.
Obsługiwane wersje IP – v4, v6.
Możliwość filtrowania ruchu przekazywanego na sondę poprzez filtry bpf.
Softflowd jest tylko sondą.
Udostępnia interfejs poprzez, który można sterować pracą sondy (softflowctl).
Statystyki libpcap – pakiety przetworzone, odrzucone przez libpcap.
Statystyki wygasania 'flowów'.
Statystyki per protokół.
Brak pól zawierających numery ASN, długości podsieci, adresu kolejnego
routera.
Duże zużycie zasobów systemowych.
Softflowd cd.
Statystyki
softflowd[6021]: Accumulated statistics:
Number of active flows: 8192
Packets processed: 6579834
Fragments: 740
Ignored packets: 2965 (2965 non-IP, 0 too short)
Flows expired: 1008318 (1008318 forced)
Flows exported: 1148034 in 1008318 packets (0 failures)
Packets received by libpcap: 1469822
Packets dropped by libpcap: 1334822
Packets dropped by interface:
Expired flow statistics: minimum
average
maximum
Flow bytes:
28
3339
38564069
Flow packets:
1
5
38714
Duration:
0.00s
8.81s
4435.78s
Expired flow reasons:
tcp =
0 tcp.rst =
0 tcp.fin =
0
udp =
0
icmp =
0 general =
0
maxlife =
0
over 2Gb =
0
maxflows = 1008318
flushed =
0
Per-protocol statistics: Octets
Packets Avg Life Max Life
Unknown (1):
2781208
29339
0.03s
47.89s
Unknown (6): 3250101881
4258945
23.20s 4435.78s
Unknown (17):
113237855
617479
0.01s
49.28s
Unknown (47):
38241
60
14.73s
17.76s
Unknown (89):
159684
1470
62.23s 851.93s
libpcap
Wygasanie flowów
per protokół
Softflowd cd.
Przepustowość
PPS
CPU
Statystyka libpcap
nProbe
http://www.ntop.org/nProbe.html
Metoda zbierania danych o ruchu sieciowym : libpcap
●
Zalety
●
●
●
●
●
●
●
●
●
●
●
Wady
●
●
●
Export w formatach - v5/v9/v10(IPFIX).
Obsługiwane wersje IP – v4, v6.
Możliwość filtrowania ruchu przekazywanego na sondę poprzez filtry bpf.
nProbe jest tylko sondą.
Pluginy dla v9.
● Pluginy rozpoznające HTTP/SMTP/RTP/SIP (dla v9).
● Plugin Layer7 – daje możliwość używania paternów rozpoznających
protokoły warstwy aplikacji używane w projekcie L7-filter.
Współpraca z kartami IXP.
4 poziomy agregacji.
Statyczne mapowanie podsieci na numery ASN.
Bezpośrednie zapisywanie strumieni do pliku bez exportu.
Współpraca z nCap/PF_RING.
Brak pól zawierających długości podsieci, adresu kolejnego routera.
Do pobrania kodu źródłowego/binarnego potrzebna jest przymusowa
dotacja 121 EU na rzecz projektu.
Ogólnie dostępna jest tylko wersja 'demo' ograniczona do 2000 strumieni.
nProbe cd.
wyniki
srcIP
dstIP
prot srcAS dstAS octets
87.99.60.185/0 24.127.197.161/0 17 38944 20214 219
24.127.197.161/0 87.99.60.185/0 17 20214 38944 358
124.121.4.153/0 87.99.50.56/0
17 7470 38944 306
87.99.50.56/0
124.121.4.153/0 17 38944 7470 429
82.166.143.74/0 87.99.48.14/0
6 8584 38944 449
87.99.48.14/0
82.166.143.74/0 6 38944 8584 417
151.77.96.8/0
87.99.60.10/0
17 1267 38944 63
87.99.60.10/0
151.77.96.8/0
17 38944 1267 42
70.65.139.130/0 87.99.51.68/0
17 6327 38944 129
87.99.51.68/0
70.65.139.130/0 17 38944 6327 339
87.99.49.81/0
86.213.225.85/0 17 38944 3215 235
86.213.225.85/0 87.99.49.81/0
17 3215 38944 194
87.99.48.108/0 71.68.118.98/0 6 38944 11426 144
83.34.57.8/0
87.99.48.223/0 6 3352 38944 806
87.99.48.223/0 83.34.57.8/0
6 38944 3352 760
87.99.51.213/0 83.27.203.186/0 6 38944 5617 394
83.27.203.186/0 87.99.51.213/0 6 5617 38944 639
87.99.51.213/0 80.48.68.29/0
6 38944 5617 144
80.48.68.29/0
87.99.51.213/0 6 5617 38944 46
87.99.60.140/0 82.2.113.227/0 17 38944 5089 56
87.99.60.198/0 87.13.94.190/0 17 38944 3269 119
87.13.94.190/0 87.99.60.198/0 17 3269 38944 97
packets
2
2
2
2
6
4
1
1
1
1
2
2
3
11
10
6
5
3
1
1
2
1
Brak długości
podsieci
nProbe cd.
Przepustowość
CPU
PPS
LA
Routing w systemach ogólnego przeznaczenia
Na systemach ogólnego przeznaczenia aby uruchomić routing dynamiczny, potrzebne
jest zewnętrzne oprogramowanie, które będzie obsługiwało określony protokół routingu
oraz zarządzało tablicą routingu systemu operacyjnego.
Podstawowe pojęcia
FIB (Forwarding Information Base) – zarządzany przez kernel systemu operacyjnego,
na podstawie informacji z FIB kernel podejmuje decyzje o trasowaniu.
Przechowywane informacje: adres podsieci, interfejs, gateway, metryka, protokół.
● RIB (Routing Information Base) - zarządzany przez daemona routingu dynamicznego
np Quagga, Xorp czy OpenBGPD.
Przechowuje informacje identyczne jak FIB bez protokołu, plus dystans i czas od ostatniej
zmiany ścieżki.
W RIBie mogą występować ścieżki alternatywne dla podsieci od różnych protokołów
routingu.
● BGP-RIB – zarządzany przez bgpd - w przypadku demona routingu Quagga.
Przechowuje informacje o ścieżkach z punktu widzenia protokołu bgp – ASPATH, waga,
lokalna preferencja, communities, czas od ostatniej zmiany, rodzaj ścieżki, inne.
●
Dlaczego sonda netflow nie widzi numerów ASN?
bgpd
12968 3356 7018 15317
62.1.1.1 from 6.1.1.1
Origin IGP, localpref 100, valid, external, best
Community: 3356:3 3356:86 3356:575
Last update: Wed Sep 26 21:06:53 2007
zebra
Routing entry for 12.0.17.0/24
Known via "bgp", distance 20, metric 0, best
Last update 4d00h09m ago
* 62.1.1.1, via eth0
kernel
12.0.17.0 via 62.1.1.1 dev eth0 src 62.1.1.2
cache mtu 1500 advmss 1460 hoplimit 64
Sonda netflow
Sonda netflow jest osobnym procesem w
przestrzeni użytkownika, ma jedynie dostęp do
informacji zawartych w tablicy routingu.
Statyczne mapowanie podsieci na numery ASN.
Najprostrzym rozwiązaniem jest statyczne mapowanie numerów ASN na podsieci,
które obsługują.
ASN
80:3.0.0.0/8
3356:4.0.0.0/8
3356:4.0.0.0/9
21889:4.23.112.0/24
21889:4.23.113.0/24
21889:4.23.114.0/24
21889:4.36.116.0/23
21889:4.36.116.0/24
21889:4.36.117.0/24
[..]
Podsieć.
Wady
● Duże zużycie pamięci - 200k prefixów musi być załadowane do pamięci.
● Nie uwzględnia zmian w tablicy routingu (np. nowo rozgłoszona podsieć, nowy
ASN).
● Brak dokładnych długości podsieci z IGP.
● Zalety
● Rozwiązanie niezależne od używanego daemona routingu, konfiguracji.
● Używane przez sondy netflow: pmacct, nProbe.
●
Czy możemy to zrobić bardziej dynamicznie?
Możemy.
● Więc czego potrzebujemy?
● Potrzebujemy znacznika za pomocą, którego przekażemy informacje
o numerze systemu Autonomicznego od BGP-RIB do RIB ostatecznie
do FIBa.
● Potrzebujemy sondy netflow, która będzie potrafiła odczytać znacznik
z tablicy routingu i poprawnie go zinterpretować.
● Potrzebujemy szybkiej metody odczytu znacznika tak aby odczyt
nie miał znaczącego wpływu na prace sondy netflow.
●
●
Problemy dalej bez odpowiedzi
● Dalej brak długości podsieci.
● Co z adresami IP kolejnego routera.
● Problem z trasami IGP.
● Obciążenie procesora przez sondę dalej jest problemem.
Quagga tags
Quagga-tags – zestaw łatek dla daemona routingu Quagga rozszerzających
funkcjonalność o tagi.
Dodane funkcjonalności
●
●
●
●
●
zebra
Tag w trasach statycznych – ip route 1.2.3.0/24 10.0.0.254 tag 666
show ip route tag XYZ
ospfd
route-map – match/set
Redystrybucja do OSPF z tagiem – redistribute static tag 1234
bgpd
route-map – match/set
Łatki na quagge 0.99.8-9, CVS:
http://packetconsulting.pl/securecon2007/quagga-tags-0.txt
http://packetconsulting.pl/securecon2007/quagga-tags-[1-5].diff
Quagga tags cd.
ip as-path access-list test permit _(1234|5678)_
[..]
route-map TEST permit 10
match as-path test
set tag 1234
!
Access-lista dopasowuje
wyrażenie regularne
do as-patha ścieżki
1.2.0.0/16
Tag zostaje przekazany
do zebry.
bgpd
zebra
BGP routing table entry for 1.2.0.0/16
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Not advertised to any peer`
11961 1234 6970
11.22.32.2 (metric 1) from 11.22.32.2 (62.1.1.1)
Origin IGP, localpref 100, tag 1234, valid, internal, best
Community: 1234:1234
Last update: Sat Sep 15 18:27:00 2007
Routing entry for 1.2.0.0/16
Known via "bgp", distance 200, metric 0 tag 1234, best
Last update 02w2d05h ago
* 11.22.32.2, via eth0
Dopasowanie powoduje
ustawienie taga
kernel
Wszystko fajnie tylko kernel nic nie wie o tagu!!
Linux realms
Realm – 32 bitowy znacznik w tablicy routingu, pozwalający na grupowanie ścieżek.
Mogą być także użyte do zliczania liczby bajtów/pakietów przechodzących
przez daną ścieżkę lub grupę ścieżek.
207.91.246.0/24 via 11.22.32.1 dev eth0 realms 1234/4471
16bitowy realm
źródłowy
32bitowy
realm
16bitowy realm
docelowy
Wynik polecenia – rtacct
Realm
unknown
1
2
[..]
248
BytesTo PktsTo BytesFrom PktsFrom BPSTo
1707M
3185M
4054M
12468K
0
678369K 561527K
3449M 657894K 0
3129M 416876K
2421M 627960K 0
3114M
494344K
1104M
488402K 0
PPSTo
0
0
0
BPSFrom
0
0
0
PPSFrom
0
0
0
0
0
0
Quagga tags + realms
Realmsy pozwalają nam przekazać wartość 'taga' do tablicy routingu, a co za tym idzie
pozwalają dodać informacje o numerze ASN dla każdej ścieżki.
Dodane funkcjonalności
●
●
zebra
ip realm tag – Włącza przekazywanie tagów do tablicy routingu jako
realmów.
bgpd
route-map – set automatic-tag (origin-AS| peer-AS) - Ustawia taga na
podstawie numeru ASN.
Łatki na quagge 0.99.8-9, CVS
http://packetconsulting.pl/securecon2007/quagga-tags-realms-1.diff
http://packetconsulting.pl/securecon2007/quagga-tags-realms-2.diff
Quagga tags + realms cd.
route-map TEST permit 10
set automatic-tag origin-AS
!
ip realm tag
1.2.0.0/16
Tag zostaje przekazany
do zebry.
bgpd
zebra
kernel
Route-mapa ustawia tag
na podstawie numeru
ASN originatora ścieżki.
Src-realm jest ustawiany na
podstawie długości podsieci.
BGP routing table entry for 1.2.0.0/16
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Not advertised to any peer`
11961 1234 6970
11.22.32.2 (metric 1) from 11.22.32.2 (62.1.1.1)
Origin IGP, localpref 100, tag 6970, valid, internal, best
Community: 1234:1234
Last update: Sat Sep 15 18:27:00 2007
Routing entry for 1.2.0.0/16
Known via "bgp", distance 200, metric 0 tag 6970, best
Last update 02w2d05h ago
* 11.22.32.2, via eth0
1.2.0.0/16 via 11.22.32.2 dev eth0 proto zebra realms 16/6970
Zebra ustawia wartość dst-realma na podstawie
wartości taga
Sondy netflow ze wsparciem dla realmsów
fprobe v1.2 / softflow v0.98
Dla każdego zaobserwowanego flowa sonda odpytuje cache routingu o
ścieżki do adresu IP źródłowego/docelowego :
Pobierane są wartości :
● Docelowy ASN.
● Docelowa długość podsieci.
● Adres IP następnego routera.
● Źródłowy ASN.
● Źródłowa długość podsieci.
85.89.175.123 > 87.99.50.74
rtr-666:~# ip r g 85.89.175.123
85.89.175.123 via 87.99.32.2 dev eth0 src 87.99.32.19 realms 20/16342
cache mtu 1500 advmss 1460 hoplimit 64
rtr-666:~# ip r g 87.99.50.74
87.99.50.74 via 172.16.236.28 dev eth1 src 172.16.236.1
cache mtu 1500 advmss 1460 hoplimit 64
Ścieżka od IGP
(brak realma)
Adres IP następnego routera
Źródłowy ASN
Źródłowa długość podsieci
http://packetconsulting.pl/securecon2007/fprobe-realms.diff
http://packetconsulting.pl/securecon2007/softflowd-realms.diff
Problem z trasami IGP.
85.89.175.123/20 ( ASN 16342 )
rtr-666:~# ip r g 85.89.175.123
85.89.175.123 via 87.99.32.2 dev eth0 src 87.99.32.19 realms 20/16342
cache mtu 1500 advmss 1460 hoplimit 64
ścieżka pochodząca od EGP(bgp)
rtr-666:~# ip r g 87.99.50.74
87.99.50.74 via 172.16.236.28 dev eth1 src 172.16.236.1
cache mtu 1500 advmss 1460 hoplimit 64
Ścieżki pochodzące od IGP (ospf)
87.99.50.74/27 ( ASN 38944)
Rozwiązaniem problemu jest default-tag w 'router ospf'
(Prace trwają)
Sondy netflow ze wsparciem dla realmsów cd.
srcIP
dstIP
prot srcAS dstAS octets
74.93.103.221/20 87.99.49.19/0
17 33650 0
302
80.228.183.115/16 87.99.48.179/0 17 9145 0
131
87.99.33.160/0
87.99.51.136/0 17 0
0
130
87.99.33.160/0
87.99.51.136/0 17 0
0
121
87.99.33.160/0
87.99.51.136/0 17 0
0
125
87.99.33.160/0
87.99.51.136/0 17 0
0
119
87.99.32.165/0
217.74.64.40/22 6 0
16138 856
124.243.207.142/18 87.99.63.97/0
17 4812 0
129
87.99.50.56/0
66.69.95.71/17 6 0
11427 128
87.99.49.121/0
84.209.34.214/15 6 0
41164 276
87.245.47.34/18
87.99.51.14/0
17 35776 0
85
41.221.19.161/20 87.99.51.202/0 17 36947 0
131
200.121.153.239/18 87.99.50.141/0 17 6147 0
123
83.250.153.48/13 87.99.60.16/0
17 39651 0
93
87.99.60.89/0
84.153.239.238/10 6
0
3320
93
87.99.62.89/0
220.132.156.137/18 17 0
3462
309
87.99.49.19/0
71.168.66.3/18 17
0
19262 91
87.99.49.115/0
68.228.33.108/19 17
0
22773 91
87.99.49.115/0
86.148.200.80/10 17
0
2856 91
87.99.50.141/0
200.83.172.124/19 17 0
22047 173
packets
1
1
1
1
1
1
5
1
3
5
2
1
2
1
2
1
1
1
1
2
Netflow na systemach *BSD
FreeBSD - ng_netflow
●
●
Zalety
● Export w formatach : v5.
● Obsługiwane wersje protokołu IP : v4, v6.
● Moduł Netgrapha.
● ng_netflow jest sondą pracującą całkowicie na poziomie kernela.
● Exportuje oprócz adresów IP także długości podsieci na podstawie tablicy
routingu.
● Exportuje adresy IP nexthopa.
● Niewielki wzrost zużycia zasobów systemowych.
Wady
● Brak numerów ASN.
uruchomienie(ngctl)
mkpeer fxp0: netflow lower iface0
name fxp0:lower netflow
connect fxp0: netflow: upper out0
mkpeer netflow: ksocket export inet/dgram/udp
msg netflow:export connect inet/10.0.0.1:2100
FreeBSD – ng_netflow cd.
FreeBSD 6.2
FreeBSD 6.2 + ng_netflow
Przepustowość
CPU
FreeBSD – ng_netflow cd.
srcIP
dstIP
prot srcAS dstAS octets
packets
83.197.226.207/16 87.99.48.115/26 6 0
0
646
11
87.20.55.251/16 87.99.63.100/32
6 0
0
716
10
87.204.210.65/15 87.99.60.159/25 6 0
0
25825
22
210.17.197.44/22 87.99.51.171/26 6 0
0
479
6
85.232.233.11/19 87.99.48.45/27
6 0
0
220
4
71.125.81.88/19 87.99.48.194/25
6 0
0
128
3
217.20.129.3/20 87.99.60.36/26
6 0
0
404
6
222.79.104.166/15 87.99.49.245/26 6 0
0
533
6
81.168.163.115/17 87.99.51.13/27
6 0
0
128
3
88.162.209.133/11 87.99.60.66/26
6 0
0
80
2
189.166.12.156/17 87.99.63.100/32 6 0
0
710
10
87.221.38.163/17 87.99.60.246/25 6 0
0
128
3
217.17.45.144/20 87.99.48.45/27
6 0
0
176
4
87.204.210.65/15 87.99.60.159/25 6 0
0
16909 15
85.68.242.175/15 87.99.60.23/26
6 0
0
88
2
86.61.125.98/17 87.99.48.115/26
6 0
0
628
10
210.17.197.44/22 87.99.51.171/26 6 0
0
80
2
82.160.27.101/16 87.99.51.11/27
6 0
0
80
2
81.15.226.6/17 87.99.51.11/27
6 0
0
80
2
64.92.226.203/20 87.99.51.200/26 6 0
0
622
5
209.85.135.99/23 87.99.51.171/26 6 0
0
40
1
222.218.36.13/19 87.99.51.39/27
6 0
0
92
2
OpenBSD – pfflowd
http://mindrot.org/projects/pfflowd/
pfflowd – Flowy są tworzone na podstawie mechanizmu synchronizacji stanów
firewalla PF.
Synchronizacja stanów
firewalla PF1 do PF2
Tablica stanów
Klaster HA
5.6.7.8:1234 -> 1.2.3.4:80
1.2.3.5:4567 -> 10.200.10.10:6667
90.123.11.200:4444 -> 1.2.3.10:21
Wykorzystując wiadomości
sygnalizacyjne pfsynca możemy
budować przepływy bez dodatkowego
oprogramowania.
W przypadku awarii firewalla PF1
firewalla PF2 przejmie ruch
sieciowy z zachowaniem stanów
połączeń.
Podobne rozwiązanie jest możliwe do realizacji na Linuxowym firewallu netfilter przy użyciu
NF_CONNTRACK_NETLINK (libnetfilter_conntrack).
http://people.netfilter.org/~pablo/conntrackd/ - zapewnia podobną funkcjonalność jak pfsync
(synchronizacje stanów firewalla)
Ciekawe Strony
Quagga-tags:
● http://packetconsulting.pl/securecon2007/quagga-tags-0.txt
● http://packetconsulting.pl/securecon2007/quagga-tags-[1-5].diff
Quagga-tags-realms:
● http://packetconsulting.pl/securecon2007/quagga-tags-realms-1.diff
● http://packetconsulting.pl/securecon2007/quagga-tags-realms-2.diff
Netflow :
● http://www.cisco.com/go/netflow
● http://www.pmacct.net
● http://fprobe.sourceforge.net
● http://mindrot.org/projects/softflowd/
● http://www.ntop.org/nProbe.html
● http://mindrot.org/projects/pfflowd/
● http://people.netfilter.org/~pablo/conntrackd/
Realmsy :
● http://www.policyrouting.org/iproute2.doc.html#ss9.9
● http://vcalinus.gemenii.ro/quaggarealms.html
● http://linux.mantech.ro/quagga+realm_en.html
Dziękuję za uwagę.