Re: timeout mit ppp und dsl

On Wed, Nov 13, 2002 at 09:02:23PM +0100, Oliver Schneider wrote:
> Moin,
>
> Also schrieb Bernd Walter am Wed, Nov 13, 2002 at 08:09:23PM +0100:
> > On Wed, Nov 13, 2002 at 06:48:35PM +0100, Oliver Schneider wrote:
> > > Also schrieb Bernd Walter am Wed, Nov 13, 2002 at 09:51:15AM +0100:
> > > > Folgende Filterregeln haben sich bei mir bewährt:
> > > > set filter dial 0 permit MYADDR 0/0 tcp
> > > > set filter dial 1 permit MYADDR 0/0 udp
> > > > set filter dial 2 permit MYADDR 0/0 icmp src eq 8
> > > > set filter dial 3 permit 10.1.0.0/16 0/0 tcp
> > > > set filter dial 4 permit 10.1.0.0/16 0/0 udp
> > > > set filter dial 5 permit 10.1.0.0/16 0/0 icmp src eq 8
> > > > set filter dial 9 deny 0/0 0/0
> > > > set filter alive 0 permit MYADDR 0/0 tcp
> > > > set filter alive 1 permit MYADDR 0/0 udp
> > > > set filter alive 2 permit MYADDR 0/0 icmp src eq 8
> > > > set filter alive 3 permit 10.1.0.0/16 0/0 tcp
> > > > set filter alive 4 permit 10.1.0.0/16 0/0 udp
> > > > set filter alive 5 permit 10.1.0.0/16 0/0 icmp src eq 8
> > > > set filter alive 9 deny 0/0 0/0
> > >
> > > imo greift das zu kurz:
> > >
> > > set filter dial 0 deny udp src eq 513 # rwhod
> > > set filter dial 1 deny udp src eq 525 # timed
> > > set filter dial 2 deny udp src eq 137 # NetBIOS name service
> > > set filter dial 3 deny udp src eq 138 # NetBIOS datagram service
> > > set filter dial 4 deny tcp src eq 139 # NetBIOS session service
> > > set filter dial 5 deny udp dst eq 137 # NetBIOS name service
> > > set filter dial 6 deny udp dst eq 138 # NetBIOS datagram service
> > > set filter dial 7 deny tcp dst eq 139 # NetBIOS session service
> > > set filter dial 8 deny tcp finrst # Badly closed TCP channels
> >
> > Verstehe ich nicht.
> > reingehend ist bei mir alles auf deny.
> > Ebenso rausgehende ICMP - Außnahme ist lediglich echo request.
> >
> > Warum sollte ich die verbleibenden Packete noch weiter runterfiltern,
> > ob z.B. Absenderport = 137 ist?
> > Das macht nur Sinn, wenn du auf den beschriebenen Ports einen von
> > draußen ereichbaren Service anbietest.
> > Wenn kein Service läuft geht nur ein icmp raus, der ja ebenfalls
> > deny ist.
>
> nope, aber Windows Rechner Broadcasten gerne für alles mögliche.

Wenns die Brodcasts das Netz verlässen sind ist der zugehörige Rechner
falsch konfiguriert.

> > > insbesonder Nummer 9 aus dem Beispiel ist da interessant. Wenn die
> > > Nummer 1-8 nicht per Firewall begrenzt werden, die je nach Netzwerk
> > > auch. Ntp, rip und konsorten kann man auch noch dazu nehmen.
> > >
> > > Wie gesagt tcpdump -ni :)
> >
> > Wenn du einen tcpdump -ni braucht, um festzustellen was für Services
> > du anbietest, dann machst du eindeutig was falsch :)
>
> sehe ich nicht so. Das kann viele Ursachen haben. Ein Rechner im lokalen
> Netzwerk versucht aufgrund einer Fehlkonfiguration ständig mit Hilfe des
> Internets einen Namen aufzulösen, ein ICQ Client oder etliche andere
> Sachen. Die Broadcast kommen zwar erstmal nicht weiter, aber sie sollten
> reichen um eine Verbindung aufzumachen.

Genau das sollen die aber.
Ich kann nun mal erst dann z.B. einen http connect aufmachen, wenn der
DNS geklappt hat.
Also muss der DNS immer die Leitung aufmachen können.
Einen Caching DNS zu betreiben hilft aber hier.

> Die Regel 8 (9 war ein Vertipper) verhindert schließlich, das zum Abbau
> einer TCP-Verbindung nochmals eingewählt wird. Wäre eh sinnlos bei einer
> dynamischen IP. Das wäre bei Dir bei Regel
> set filter dial 3 permit 10.1.0.0/16 0/0 tcp erlaubt.

Stimmt - die sollte man bei einer dynamischen IP für dial auf syn
Packete reduzieren.
Bei einer statischen IP macht es allerdings durchaus Sinn.

Du versuchst mit den Filtern falsch konfigurierte Rechner davon
abzuhalten die Leitung aufzuhalten - ich konfiguriere die lieber
richtig.
Allerdings bleibt das Problem, daß man alle Nase lang, insbesonders bei
den dyn Pools, Packete von draußen bekommt, die die Leitung aufhalten
würden.

-- 
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