Re: stateful Firewall und Timeouts

On Mon, Jul 08, 2002 at 02:59:05PM +0200, Christian Lackas wrote:
> * Oliver Brandmueller <ob(at)e-Gitt.NET> [020708 14:36]:
>
> Hallo Oliver,
>
> > > net.inet.ip.fw.dyn_ack_lifetime: 300
> > > (das sollten die Defaults meines FreeBSD 4.6-STABLE 5.7.2002 sein).
> > > Kann ich da jetzt einfach »dyn_syn_lifetime« erhöhen? Bei anderen
> > > Verbindungen (HTTP, FTP, POP, ...). Kann das ja ein vernünftiger Wert
> > > sein. Und ich will auch nicht, dass die Liste mit den dynamischen Regeln
> > > überläuft.
> > Obiges ist der Wert (der aber 5 Minuten steht!), den Du erhöhen
> > möchtest.
>
> Möchte ich das denn wirklich? Für den Großteil der Verbindungen ist
> obiger Wert ja wohl gut gewählt. Und ich möchte nur für einige wenige
> einen etwas höheren.
>
> > Weiterhin möchtest Du die dynamischen Rules natürlich nur
> > mit setup-packets eintragen:
>
>
> mal abgesehen von den Anti-Spoofing-Regeln (siehe /etc/rc.firewall) sieht meine
> Firewall derzeit so aus:
>
> # loopback device
>
> # anti-spoofing
>
> # nat
> ${fwcmd} add divert natd all from any to any via ${natd_interface}

Und da ist schon der Fehler.
Die Zeile verbiegt die Packte vor dem check-state, wodurch dieser dann
nichts vom vollständigen Verbindungsaufbau erfährt.
Du musst die check-state Zeile vorziehen.

> # anti-spoofing die Zweite
>
> ${fwcmd} add check-state
>
> ${fwcmd} add deny tcp from any to any established
>
> # »iff« enthält die internen devices (xl0, xl1, ed0)
> for device in ${iif}; do
> ${fwcmd} add allow tcp from any to any via ${device} setup keep-state
> done

Mit den keep-state musst du jetzt aufpassen, da Packete die durch den
natd gehen nicht mehr mit keep-state mariert werden dürfen.

> # Allow outgoing DNS queries ONLY to the specified servers.
> # Allow them back in with the answers... :)
> for host in 212.185.249.84/24 194.25.2.129/24; do
> $fwcmd add allow udp from any to $host 53 out xmit ${oif} keep-state
> $fwcmd add allow udp from $host 53 to any in recv ${oif} keep-state
> done
>
> # Allow access to some of our services
> for port in 80 443 22 110 143; do
> ${fwcmd} add pass tcp from any to any $port setup keep-state
> done
>
> $fwcmd add allow icmp from any to any icmptype 0,3,4,8,11,12
>
> ${fwcmd} add reset tcp from any to any 113 setup
>
> # Reject&Log all setup of incoming connections from the outside
> ${fwcmd} add 50000 deny log tcp from any to any in via ${oif} setup
>
> ${fwcmd} add 65000 deny log all from any to any
>
> > Ich vermute Deinen Fehler in den Rules: Du triggerst nicht auf setup und
> > machst daher kein deny für established Pakete vorher.
>
> Eigentlich dachte ich schon, dass ich das getan hätte. Der deny für die
> Packete mit RST und ACK ist hier doch eigentlich egal. Später matched
> man doch auch nur noch auf setup, oder nicht?

Genau.
Wenn die Session allerdings teilweise am check-state vorbeiläuft,
dann kommt der dyn Eintrag nach dem ersten Syn nicht weiter.

> > Folglich triggerst Du mit den Paketen der established Connections
> > jeweils wieder neu die dynamische Regel. Bei established connection
> > durchläuft er nicht mehr den Verbindungsaufbau (hat er ja schon hinter
> > sich), also bleibt das dann irgendwo immer bei den 20 Sekunden von
> > dyn_syn_lifetime hängen.
>
> Das klingt zumindest plausibel. Ich werde mir das nochmal anschauen
> (speziell mit dem neugewonnenen Wissen). Fünf Minuten sind natürlich
> auch noch nicht lange (ich habe ssh-Verbindungen oft Tagelang offen).
> Benutzt du dann noch keep-alive? Ich danke dir auf jeden Fall.
>
> BTW: Falls sonst noch jemand etwas zu den Regeln beizutragen hat: ich
> bin für Vorschläge offen.

Schau dir mal folgendes Grundgerüst an:
# deny and log all incoming spoofing packets from external.
ipfw add deny log ip from 10.1.0.0/16 to any in via tun0
ipfw add deny log ip from any to 10.1.0.0/16 in via tun0
ipfw add deny log ip from me to any in via tun0

# Allow internal traffic
ipfw add allow ip from 10.1.0.0/16 to 10.1.0.0/16
ipfw add allow ip from 127.0.0.1 to 127.0.0.1
ipfw add allow ip from any to 255.255.255.255 via 'de*'
ipfw add allow ip from 255.255.255.255 to any via 'de*'

# check states
ipfw add check-state

# refuse auth connects
ipfw add reset tcp from any to me 113

# allow router to inet
ipfw add allow ip from me to any keep-state

# Add masquerading divert rules for tun0/Inet
ipfw add divert 32002 ip from 10.1.0.0/16 to any out via tun0
ipfw add divert 32003 ip from any to any in via tun0

# Deny ping from extern over tun0 and log most
ipfw add deny log icmp from any to any in via tun0 icmptype 8 # icmp echo
ipfw add allow icmp from any to any out via tun0 icmptype 8 # icmp echo
ipfw add allow icmp from any to any in via tun0 icmptype 0 # icmp echo reply
ipfw add allow icmp from any to any via tun0 icmptype 11 # icmp timxeed / traceroute
ipfw add allow icmp from any to any via tun0 icmptype 3 # icmp unreach
ipfw add allow log icmp from any to any via tun0

# Allow all other icmps
ipfw add allow icmp from any to any

# Allow internal Multicast
ipfw add allow ip from 224.0.0.0/8 to any via 'de*'
ipfw add allow ip from any to 224.0.0.0/8 via 'de*'

# Allow Traffic to Inet
ipfw add allow ip from 10.1.0.0/16 to any
ipfw add allow ip from me to any

# Allow Traffic from I-Net
ipfw add allow tcp from any to 10.1.0.0/16
ipfw add allow udp from any to 10.1.0.0/16

# Allow special incoming Traffic

# Allow Traffic from trusted sites

# Log everything else
ipfw add deny log ip from any to any

echo "All done..."

Je nachdem was du von intern können willst wirst du noch Änderungen
einbringen müssen.

Z.B. wirst du interne keep-state »nach« dem check-state definieren.
Die obigen Regeln fürs Interne sind aus Performancegründen vorher.

Die nat ports für rein und raus sind getrennt, weil ich mit dem
Grundregelwerk auch mehrere natd und nat über offizielle IPs
betreiben kann.
In deinem Fall kannst du die Ports gleichsetzen.

-- 
B.Walter              COSMO-Project         http://www.cosmo-project.de
ticso(at)cicely.de         Usergroup           info(at)cosmo-project.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message