[linux-l] IP tables

[Peter Ross]

Hi,

On Tue, 17 Dec 2002, Kendy Kutzner wrote:

> > Chain FORWARD (policy ACCEPT 4700 packets, 232K bytes)
> >  pkts bytes target     prot opt in     out     source               destination
> > # Stop spoofing
> >     0     0 LOG        all  --  eth1   *       192.168.0.0/16       0.0.0.0/0          LOG flags 0 level 4
> >     0     0 LOG        all  --  eth1   *       192.168.0.0/16       0.0.0.0/0          LOG flags 0 level 4
>
> Doubletten, sollte aber nicht stoeren.

Stimmt, aber prinzipbedingt. Ich habe Shellprozeduren geschrieben, z.B.
eine gegen's Einschleusen von Paketen, die behaupten, von "meinen"
Adressen drinnen zu stammen, eine fuer's Stoppen von RFC 1918-Netzwerken.

In diesem Fall hier ist das interne Netz gleichzeitig ein RFC 1918-Netz,
daher die Dopplung.

Der Ursprung dieses Skriptes ist mein alter FreeBSD-Code, ich habe halt
die Logik uebernommen und die einzelnen Prozeduren und das Rahmenskript
der iptables-Logik und -Syntax angepasst und ein bisschen verbessert
(mache jetzt mehr Dinge stateful)

> > # Wirf NetBIOS weg, ausser MS weiss eh keiner, warum die Kisten das
> > # immerzu wollen
>
> Vielleicht nach innen besser Reject statt Drop, damit keine
> Timeouts auftreten.

Ja. <MS Bashing> Wobei MS zuzutrauen ist, dass sie dann nach einem anderen
Port suchen, um Deine Adressliste zu uebertragen</MS Bashing>

> > Also: Default-Policy auf DROP gesetzt und..
> >
> > Z.B. kein ping mehr nach aussen, obwohl ich ICMP-Type 0 und 8 explizit
> > erlaube (siehe ICMP-Filter oben..)
>
> Ping von der Firewall-Maschine aus, oder einem beliebiger Rechner
> intern? Kann man den Firewall von innen und aussen pingen?

Also, ich bekam von einem Komputer im internen Netz nichts "nach
draussen", nicht einmal ein ping. Andere Dienste (ssh z.B.), die ich
"freigeschaltet" habe, waren auch tot.

Der Firewall selbst ist auch ping-bar, aber daran sind ja INPUT und OUTPUT
"schuld".

> Versuche doch die default-policy auf reject zu stellen und schaue
> ob Du eine Fehlermeldung bekommst.

Okay, ich werde sehen. Ich muss das machen, wenn hier keiner arbeitet,
also jetzt gerade nicht..

> Andere Moeglichkeit: an das Ende jeder Kette ein Log-and-Reject
> stellen. Mit verschiedenen --log-prefix 'xxx' sieht man dann an
> welcher Stelle das Packet weggeworfen wurde.

Jede Drop-Regel hat bereis eine gleichlautende Logregel, und eben auch
"ganz unten" das "Auffanglager":

> # Der Rest soll geloggt werden
>  4642  224K LOG        all  --  *      *       0.0.0.0/0
> 0.0.0.0/0   LOG flags 0 level 4

Da tauchte aber kein ping-Paket auf.. Ich habe vorher kern.log gecheckt
und was ich da fand, war wirklich nur Zeugs, von dem ich auch nicht will,
dass es uebertragen wird. Portscans, Netbios etc. Und wie gesagt,
wirklich jede Regel hat erst ein LOG und dann ein DROP..

> Hast Du die default-policy der anderen Tabellen/Ketten auch auf
> Drop umgestellt?

Ja. Diese Funktion wird am Anfang des Firewallskripts aufgerufen (danach
alle anderen Regeln)

# Clear the filter table
# Parameter:
# $1 policy (ACCEPT/DROP) default: ${firewallpolicy}

reset_firewall ()
{
  if [ "${firewallverbose}" = "YES" ]; then
     echo "reset_firewall $*"
  fi
  if [ "X$1" != "X" ]; then
    policy=$1
  else
    policy="${firewallpolicy}"
  fi

  $fwcmd --flush
  $fwcmd --policy INPUT ${policy}
  $fwcmd --policy OUTPUT ${policy}
  $fwcmd --policy FORWARD ${policy}

  $fwcmd -t nat --flush
  $fwcmd -t nat --policy PREROUTING ${policy}
  $fwcmd -t nat --policy OUTPUT ${policy}
  $fwcmd -t nat --policy POSTROUTING ${policy}
}

Ich habe also das gesamte Firewallskript mit geaenderter Variable
${firewallpolicy} aufgerufen.

Wenn ich mir das jetzt so angucke, weiss ich nicht so recht, ob das fuer
die nat-table noetig sein sollte oder gar zum Problem wird.

Wobei ich annehme, dass die Policyregel hier gar keine Rolle spielt.
Schliesslich ist nat fuer Network Address Translation und nicht fuer's
Filtern da?

Und INPUT und OUTPUT haben hoffentlich nichts mit FORWARD zu tun.

> > Ich habe danach den Verdacht gehabt, dass ich irgendwo einen prinzipiellen
> > Denkfehler mache.
>
> Ich habe keinen gefunden, was natuerlich nichts heissen muss.
>
> > Was blockt hier das Ping?
>
> Ich vermute das Zusammenspiel von Filter und NAT. Vielleicht ist
> SNAT besser als MASQUERADE, oder ist eure Aussenverbindung
> dynamisch? .. Noch eine Frage: wie ist eth0 und eth2 belegt?

Nun, es gibt eth0 fuers interne Netz und eth1 und eth2 fuer extern. Wobei
eth2 eine Backuploesung ist und eine dynamische Adresse. Ich teste
regelmaessig eth1 und wenn das nicht mehr geht, geht eth1 down und eth2
hoch. Danach versuche ich regelmaessig eth1 hochzubekommen und zu testen.
Ist das okay, lege ich eth2 wieder schlafen.

Da eth2 ein DHCP-Interface ist, habe ich MASQUERADE verwendet. Ohnehin
erzeugen meine Skripte die Regeln jeweils fuer eth1 und eth2. Ich habe
lediglich eth1 geschrieben, um Tinte zu sparen;-)

Um nach SNAT umzustellen, muesste ich das Firewallskript in die
DHCP-up/down-Skripte integrieren und jedes mal aufrufen, wenn eth2 ins
Spiel kommt.

> Wirf doch mal einen Packetsniffer (ethereal ist ein
> tolles Programm) an, um zu sehen ob die Packete korrekt umgesetzt
> werden.

Danke fuer den Tip. Ich verwende bis jetzt immer tcpdump.

Es gruesst
Peter