Re: timeout mit ppp und dsl

From: Oliver Schneider <os(at)kobo.de>
Date: Wed, 13 Nov 2002 21:02:23 +0100

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.

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

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.

Gruß
Oliver

-- 
------------------------------------------------------------------
   Wie man weiss, ist "Windows" ebenfalls indianisch und heisst
      ,,Weisser Mann starren durch Glasscheibe auf Sanduhr``
------------------------------------------------------------------
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Wed 13 Nov 2002 - 21:02:45 CET

search this site