Re: IPFW-Frage

Hallo Olli,

On Thu, 21 Nov 2013, Oliver Fromme wrote:

>
> Grundsätzlich spielen hier zwei Fakten eine Rolle:
>
> 1. Geroutete Pakete gehen _zweimal_ durch den IPFW-Regelsatz,
> einmal beim Hereinkommen und einmal beim Herausschicken.
> Will man sie durchlassen, muss beides erlaubt sein.
>
> 2. Beim Hereinkommen weiß IPFW noch nicht, was der Routing-
> Code später mit dem Paket anstellt, d.h. bei welchem
> Interface es später wieder herauskommt (wenn überhaupt).
> IPFW kann ja nicht in die Zukunft schauen. Daher kann
> bei hereinkommenden Paketen nur das "recv"-Interface
> geprüft werden, nicht das "xmit"-Interface. Letzteres
> geht nur bei Paketen, die auf dem Weg nach draußen sind.

Ja, das stimmt. Allerdings ist ipfw nur das Konfigurationswerkzeug, muß
meiner Meinung nicht 1:1 in Kernelfunktionen übersetzt werden. Wir
programmieren schließlich auch nicht mehr Assembler (meistens)..

Wenn ich z.B.

   ipfw add pass ip from any to any recv ed0 xmit ed1

schreiben könnte und dann nicht "versehentlich" Pakete an der Fuirewall
"hängenbleiben", wäre das doch gut.

Ich könnte auch nicht sehen, wie das "mißverstanden" werden könnte.

> Peter Ross wrote:

>
> > ipfw add pass ip from any to any out recv ed0 xmit ed1
> > ipfw add deny ip from any to me in recv ed0
> > ipfw add pass ip from any to any in recv ed0
>
> Die letzten beiden kannst Du zusammenfassen (vorausgesetzt,
> es kommt später noch eine deny-default-Regel):
>
> ipfw add pass ip from any to not me in recv ed0

Ja, danke. Ich habe auch schon geguckt, wie ich was mit "not und "and" und
so hinkriege, habe das aber bis jetzt nie verwendet.. Man kann sich bei
0/1/and/or/not Logik so schön vertun;-)

Die Regeln werden auch nicht manuell geschrieben, da macht 'ne Regel mehr
oder weniger nicht so viel. Es sei denn, der Durchsatz leidet. Das habe
ich bisher aber noch nicht bemerken können.

Das Skript habe ich seit etlichen Jahren, da ich immer mal wieder
Firewalls schreiben mußte, mal mit ipfw, mal mit iptables, mal pf
(manchmal am selben Ort an zwei Systemen), ich aber doch immer wieder die
gleichen Funktionen hatte.

Ich habs nur lange nicht für IPFW verwendet und hatte eine "fix mal"
handgeschriebene Firewall (im internen Netz), die ich nun doch auf
"ordentlichen Standard" bringen will.

(Der Google-Logik folgend, ist mein VPN sicher, da der Provider VPN
verspricht.. well, wer weiß.. siehe Google, wobei, wer sich bei uns
umsieht, langweilt sich zu Tode;-)

So saugt das Skript sich eine Konfiguratonsdatei rein, die etwa so
aussieht:

# Basics to access the machine itself
vlan300_in_tcp_connections="ssh nrpe"
vlan300_in_tcp_ssh_dst_port="22"
..
out_vlan300_udp_connections="ntp1 ntp2 dns1 dns2"

out_vlan300_udp_ntp1_dst_ip="${ntp1}"
out_vlan300_udp_ntp1_src_port="123"
out_vlan300_udp_ntp1_dst_port="123"

# From Management to DMZ
vlan200_vlan100_tcp_connections="adminmail"

# Access to adminmail
vlan200_vlan100_tcp_adminmail_dst_ip="${adminmail_ip}"
vlan200_vlan100_tcp_adminmail_dst_port="25"

...

Das geht dann durch eine Schleife:

for s in out ${internal_nets} external; do
     for d in in ${internal_nets} external; do

Und nach ein bißchen "eval" kommt dann derzeit folgendes raus:

if [ ! "${s}" = "out" ]; then
    if [ ! "${d}" = "in" ]; then
       ${fwcmd} add deny ${proto} from ${src_ip} ${src_port} \
                                  to me ${dst_port} \
                                  in recv ${src_if} ${proto_keep}
       ${fwcmd} add deny ${proto} from me ${src_port} \
                                  to ${dst_ip} ${dst_port} \
                                  out xmit ${dst_if} ${proto_keep}
    fi
    ${fwcmd} add pass ${proto} from ${src_ip} ${src_port} \
                               to ${dst_ip} ${dst_port} \
                               in recv ${src_if} ${proto_keep}
fi
if [ ! "${d}" = "in" ]; then
    ${fwcmd} add pass ${proto} from ${src_ip} ${src_port} \
                               to ${dst_ip} ${dst_port} \
                               out xmit ${dst_if} ${proto_keep}
fi

Da "out und "in" zuerst kommt, habe ich ein "pass to me" vor einer
eventuell folgenden "deny to me"-für "Transit.

Ich hoffe, das ist jetzt so richtig.

> > Sorry, das laesst mir gerade keine Ruhe, aber ich bin im Moment von der
> > Konsole kilometerweit weg.. da "spielt" es sich schlecht;-)
>
> Wenn man das remote macht, gibt es zwei Probleme: Erstens
> bricht einem die ssh-Verbindung weg, wenn während des Flush,
> der beim Neuladen der Regeln passiert, eine Ausgabe passiert.
> Das Wegbrechen der ssh-Verbindung wiederum bewirkt, dass
> ipfw(8) ein SIGHUP bekommt und die restlichen Regeln nicht
> mehr lädt. Nicht gut. :-)
>
> Die Lösung ist, die Ausgabe (auch stderr) in eine Logdatei
> umzuleiten. Das sleep sorgt dafür dass nicht zufällig noch
> gepufferte Ein-/Ausgaben im falschen Moment in die Quere kommen.
>
> ( sleep 3; /sbin/ipfw /etc/ipfw.conf; sleep 3 ) >/root/ipfw.log 2>&1
>
> (Syntax für sh, zsh und bash.)

Ja, danke. Darüber bin ich beim Einrichten der Firewall auch schon
gestolpert, aber nur beim ersten Laden (d.h. ich starte ohne
firewall_enable=yes und mache ein "service ipfw onestart")

Bis jetzt nahm ich an, es liegt am Modulladen.

> echo /sbin/ipfw add 1 allow ip from any to any | at HH:MM

Ja.

Ich habe übrigens auch meine /etc/rc.conf "zerlegt" (die wird von einem
Programm configure_system.sh geschrieben), so daß ich eine Datei /simple
anlegen kann und dann wird bei Reboot nur das Netz und ssh hochgefahren.

Manchmal sind runlevels doch ganz gut;-) Sperrt man sich bei BSD aus
religiösen Gründen dagegen?;-) Immerhin gibt es jetzt ein /etc/rc.d - und
ich will immer /etc/init.d tippen..

Meine Remote-Rechner sind alle in Büros (und müssen nur laufen, wenn Leute
da sind), so kann ich im Notfall einen Mitarbeiter zum Einloggen, touch
/simple, reboot bringen.

Dankeschön für die Antworten, und friert nicht so viel;-)

Peter

(P.S. Das mit dem Frieren kriegen wir hier schon bei 10 Grad plus hin..
die meisten Häuser hier sind zugig, schlecht isoliert und neigen dazu,
ohne Heizer/Kühlung schnell Außentemperatur anzunehmen..Nothing is perfect
in God's perfect plan;-)

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Fri 22 Nov 2013 - 01:04:08 CET