Re: Was beachten bei IPv6 Firewall?
- From: "Juergen P. Meier" <nospam-1984@xxxxxxxx>
- Date: Wed, 05 Aug 2009 05:43:50 +0000 (UTC)
Peter Mairhofer <63832452@xxxxxxx>:
Hmm, schade :-( Hat wirklich noch keiner eine IPv6 Firewall gebaut?
Doch:
1:root@hal:~# ip6tables-save
# Generated by ip6tables-save v1.3.6 on Wed Aug 5 07:44:29 2009
*filter
:INPUT ACCEPT [901919:291128098]
:FORWARD ACCEPT [64701742:39075625325]
:OUTPUT ACCEPT [825429:70219491]
-A INPUT -s ::/0 -d ::/0 -m rt --rt-type 0 -j DROP
-A FORWARD -s ::/0 -d ::/0 -m rt --rt-type 0 -j DROP
-A OUTPUT -s ::/0 -d ::/0 -m rt --rt-type 0 -j DROP
COMMIT
# Completed on Wed Aug 5 07:44:29 2009
Da ich keine IPv6 Cliens oder Server laufen habe, denen ich nicht auch
volle Konnektivitaet geben moechte, existiert bei mir schlicht keine
Sicherheitstechnische Notwendigkeit fuer weitere Regeln.
Bei IPv6 funktionert mein Sicherheitskonzept der Absicherung aller
Anwendungen aufgrund der Ueberschaubarkeit der IPv6-faehigen Programme
noch.
ip6tables -P INPUT DROP
ip6tables -P OUTPUT DROP
ip6tables -P FORWARD DROP
ip6tables -N answers
ip6tables -A answers -p udp --dport 32768:60999 -j ACCEPT
Wieso diese Portrange? Was ist wenn $UNGEWOLLTES_PROGRAMM auf Port
50000/UDP lauscht?
Was ist wenn dein Client intern einen lower Source-UDP port verwendet?
ip6tables -A answers -p tcp ! --syn -j ACCEPT
Das deckt dann auch TCP ab. Was ist mit SCTP?
# Disable processing of any RH0 packet
# Which could allow a ping-pong of packets
auch andere Poese Tinge.
#ip6tables -A INPUT -m rt --rt-type 0 -j DROP
#ip6tables -A OUTPUT -m rt --rt-type 0 -j DROP
#ip6tables -A FORWARD -m rt --rt-type 0 -j DROP
# Allow anything on the local link
ip6tables -A INPUT -i lo -j ACCEPT
ip6tables -A OUTPUT -o lo -j ACCEPT
Ist bei Drop-Default noetig, ja.
# Allow Link-Local addresses
ip6tables -A INPUT -s fe80::/10 -j ACCEPT
ip6tables -A OUTPUT -s fe80::/10 -j ACCEPT
# Allow multicast
ip6tables -A INPUT -s ff00::/8 -j ACCEPT
ip6tables -A OUTPUT -s ff00::/8 -j ACCEPT
ip6tables -A FORWARD -s ff00::/8 -j ACCEPT
Es fehlt dir noch fc00::/7 (ULA, RFC 4193), ff02::1:0:0/96 (Solicied
Multicast), Falls du auf Linux Dual-mashed-mixer-Stack stehst, auch
noch ::ffff:0.0/96 (kannste dir echt sparen wenn du net.ipv6.bindv6only
auf 1 stellst)
# Allow ICMP
ip6tables -A INPUT -p icmpv6 -j ACCEPT
ip6tables -A OUTPUT -p icmpv6 -j ACCEPT
ip6tables -A FORWARD -p icmpv6 -j ACCEPT
Somit funktionert das schonmal grundsaetzlich.
# Raus darf alles
ip6tables -A OUTPUT -j ACCEPT
# Antwortpakete dürfen von überall rein
ip6tables -A INPUT -j answers
s.o. Insbesondere DNS-lookups funktioneren damit nicht.
# Lokales Netz darf uneingeschraenkt rein
ip6tables -A INPUT -i ${LAN} -j ACCEPT
Ok, Interface-basiert. Mit VLAN-interfaces kann netfilter ja auch
umgehen, nicht so wie mit diesen schwachsinnigen
Pseudo-wir-verpacken-secondary-addressen-einfach-als-pseudo-interface
mit ethX:Y.
# Und SSH darf von überall rein
ip6tables -A INPUT -p tcp --dport 22 -j ACCEPT
Siehe $DISKUSSION_UEBER_SSH.
# LAN --> DMZ
ip6tables -A FORWARD -i ${LAN} -o ${DMZ} -j ACCEPT
ip6tables -A FORWARD -i ${DMZ} -o ${LAN} -j answers
S.o.
# DMZ --> LAN
# Alle: Interner DNS Server, syslog, apt-proxy
ip6tables -A FORWARD -i ${DMZ} -o ${LAN} -d $INT_SERV -p tcp --dport 53
-j ACCEPT
ip6tables -A FORWARD -i ${DMZ} -o ${LAN} -d $INT_SERV -p udp --dport 53
-j ACCEPT
ip6tables -A FORWARD -i ${DMZ} -o ${LAN} -d $INT_SERV -p tcp --dport
9999 -j ACCEPT
ip6tables -A FORWARD -i ${DMZ} -o ${LAN} -d $INT_SERV -p udp --dport 514
-j ACCEPT
Serviecs innen, DMZ-server als Clients. Unsauber aber oft nicht ohne
aufwand anders realisierbar.
Ich wuerde zumindest den DNS server und den Apt-Proxy in die DMZ stellen.
# DMZ --> Internet
ip6tables -A FORWARD -i ${DMZ} -o ${EXT} -j ACCEPT
ip6tables -A FORWARD -i ${EXT} -o ${DMZ} -j answers
# LAN --> Internet
ip6tables -A FORWARD -i ${LAN} -o ${EXT} -j ACCEPT
ip6tables -A FORWARD -i ${EXT} -o ${LAN} -j answers
Soweit kein Unterschied zwischen DMZ und LAN.
# public services (DMZ)1984?
# ns: 1984, 53
ip6tables -A FORWARD -d $NS_SERV -p tcp --dport 1984 -j ACCEPT
ip6tables -A FORWARD -d $NS_SERV -p tcp --dport 53 -j ACCEPT
ip6tables -A FORWARD -d $NS_SERV -p udp --dport 53 -j ACCEPT
Brav. TCP gehoert zu DNS wie Kiemen zum Fisch.
(Ohne Kiemen hat man auch Fisch, nur faengt der schnell an zu Stinken)
Der DNS Server, steht der in der DMZ? oder wo? Du schraenkst hier nix
weiter per -i /-o ein. Diese Regeln gelten also fuer LAN-> Internet,
Internet -> LAN, Internet->DMZ etc.pp.
# mail: 1984, 25, 465, 993SMTP, Submission und imaps?
ip6tables -A FORWARD -d $MX_SERV -p tcp --dport 1984 -j ACCEPT
ip6tables -A FORWARD -d $MX_SERV -p tcp --dport 25 -j ACCEPT
ip6tables -A FORWARD -d $MX_SERV -p tcp --dport 465 -j ACCEPT
ip6tables -A FORWARD -d v -p tcp --dport 993 -j ACCEPT
Das v sollte $IMAP_SERV heissen?
# web: 1984, 21, 80, 443
ip6tables -A FORWARD -d $WEB_SERV -p tcp --dport 1984 -j ACCEPT
ip6tables -A FORWARD -d $WEB_SERV -p tcp --dport 80 -j ACCEPT
ip6tables -A FORWARD -d $WEB_SERV -p tcp --dport 443 -j ACCEPT
ip6tables -A FORWARD -d $WEB_SERV -p tcp --dport 21 -j ACCEPT
WWW laeuft nicht nur ueber diese Ports. Und FTP blockierst du die
Datenkanele solande es noch kein FTP-Helpermodul fuer ipv6 gibt.
(IIRC, bitte sagen wenn es eines gibt)
ip6tables -A FORWARD -j LOG --log-prefix "FORWARD:REJ:"
ip6tables -A FORWARD -j DROP
Uh oh, Denial-Of-Service!
Logging sollte immer rate-limitiert werden.
Die letzte Regel würde ich sehr gerne REJECT machen, aber OpenWRT hat
das Modul leider nicht.
Distro-Schrott. Selber bauen und draufkopieren.
Die Regeln mit den RH0-Paketen funktionieren leider auch nicht. Wie
schlimm ist das bzw. für was sind die überhaupt?
Der Route-header ist bei IPv6 sowas wie source-routing unter IPv4.
Er laest sich zu allerlei Schabernack misbrauchen. Darum ist die
offizielle Empfehlung fuer IPv6 an Netzgrenzen Pakete mit diesem
Header einfach zu verwerfen.
Ist in diesem Anwendungsfall die explizite Behandlung der
link-local/multicast Pakete überhaupt noch notwendig?
Ja. Andernfalls kannst du IPV6 gleich ganz abschalten.
Ist es schlecht wenn ich generisch alle ICMP von überall passieren
lasse? Oder sollte man hier noch feiner granulieren und wenn ja, wie?
Zwingend notwendig sind bei ICMPv6 die Typen 1, 2, 3, 4 und 127.
Sinnvoll (sonst klemmt dich sixxs ab!) sind die Typen 128 und 129.
(Echo request und echo reply) Schon alleine fuers trouble shooting.
Alle anderen sind /derzeit/ nicht notwendig. Es gibt aber (Ausser
den "private experimentation") auch sonst keine definierten Typen, von
daher kann man sich das Filtern auch sparen.
(Anders als bei IPv4 gibt es keine potentiell sicherheitskritischen
Typen/Funktionen, das hat man bei IPv6 von vorneherein garnicht
vorgesehen).
Du kannst das also so lassen.
Passt die Behandlung der Antwortpakete für UDP nun oder gibts da bessere
Lösungen?
Das passt nur, wenn du auf /allen/ Rechnern in deinem LAN/DMZ
folgendes umsetzt:
1) Es darf kein "client-Programm" einen UDP Socket mit Portnummer
kleiner 32768 aufmachen.
2) Es darf kein unauthorisiertes "Server-Programm" einen UDP Socket
mit Portnummer groesser 32767 aufmachen.
Wie du das umsetzt waere spannend. Ich wuerde sagen: Das passt so nicht
ganz.
(Bei UDP kannst du technisch gesehen nicht zwischen Client und Server
differnzieren).
HTH,
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
.
- Prev by Date: Re: Zweite LAN-Karte und iSCSI
- Next by Date: Re: Was beachten bei IPv6 Firewall?
- Previous by thread: Zweite LAN-Karte und iSCSI
- Next by thread: Re: Was beachten bei IPv6 Firewall?
- Index(es):
Relevant Pages
|
