|
|
 | | From: | Stefan Heidrich | | Subject: | Re: sinnvolle Filterregeln | | Date: | Sun, 29 Feb 2004 20:25:57 +0100 |
|
|
 | Hallo Juergen,
> Dass Squid eine Lösung sein könnte, hatte ich auch schon
> angedacht, aber bin da nicht weitergekommen.
Squid in Verbindung mit SquidGuard ist noch besser.
> Ich habe mich gestern mit dem Router auseinandergesetzt
> und weiß, wie er konfiguriert werden muss. Also setze ich
> die einen Filter, dass alle Pakete aus dem Netz (TCP und
> UDP) und ins Netz außer dem Router auf Drop gesetzt
> werden.
Ohh nein. Erstens muss man nur eingehende, nicht benötigte Ports zwischen 1
und 1023 sperren und zweitens nicht mit "drop", sondern mit "reject".
Ausgehende Ports musst Du gar nicht sperren; Du musst nur dafür Sorge
tragen, dass die ausschließlich der Rechner mit dem Squid drauf nutzen kann.
Ich habe das hier so gelöst:
FLI4L als DSL-Router in einem Netz 192.168.100.252/255.255.255.252. Damit
ist ein Netz geschaffen mit folgenden Eigenschaften:
Netzadresse 192.168.100.252 (nicht nutzbar)
1. freie IP-Adresse (=Squid mit Squidguard) 192.168.100.253
2. freie IP-Adresse (=Router selbst) 192.168.100.254
Broadcast-Adresse 192.168.100.254
Die Clients (Windows ME Rechner mit Daten-Airbag) bekommen per DHCP eine
IP-Adresse des Netzes 192.168.100.0/255.255.255.0 zugewiesen. Einziger
Nachteil an der Sache: Man muss in alle installierten Browser den Squid als
Proxy eintragen - das habe ich noch nicht automatisieren können.
Da der Router aber nicht das ganze Class-C-Netz kennt nimmt er auch keine
Anfragen der Clients entgegen.
Also ein narrensicheres System, in dem Schüler sogar eigene Rechner
mitbringen und trotzdem keinen Blödsinn machen können.
BTW: Squid mit Squidguard läuft auf dem "großen Bruder" vom FLI4L: einem
Eisfair-Server.
Viele Grüße
Stefan
--
PGP verfügbar
|
|
| | From: | Andreas Rittershofer | | Subject: | Re: sinnvolle Filterregeln | | Date: | Mon, 01 Mar 2004 09:11:04 GMT |
|
|
| On Sun, 29 Feb 2004 20:25:57 +0100, "Stefan Heidrich"
wrote:
>> Ich habe mich gestern mit dem Router auseinandergesetzt
>> und weiß, wie er konfiguriert werden muss. Also setze ich
>> die einen Filter, dass alle Pakete aus dem Netz (TCP und
>> UDP) und ins Netz außer dem Router auf Drop gesetzt
>> werden.
>Ohh nein. Erstens muss man nur eingehende, nicht benötigte Ports zwischen 1
>und 1023 sperren und zweitens nicht mit "drop", sondern mit "reject".
Warum müssen nur eingehende privilegierte Ports gesperrt werden? Was
ist, wenn lokal eine Datenbank auf 3306 läuft und diese dann von außen
erreichbar ist? Es müssen zunächst alle eingehenden Ports gesperrt
werden.
Warum müssen ausgehende Ports nicht gesperrt werden? Was ist, wenn
lokal schon Malware läuft und diese Verbindung nach außen aufbauen
will? Da ist es besser, auch ausgehende Ports sind gesperrt.
Warum nicht drop, sondern reject?
>
>Ausgehende Ports musst Du gar nicht sperren; Du musst nur dafür Sorge
>tragen, dass die ausschließlich der Rechner mit dem Squid drauf nutzen kann.
Das halte ich für falsch, s.o..
mfg ar
--
E-Learning mit dem LmTM-Server:
http://www.LmTM.de/
|
|
| | From: | Stefan Heidrich | | Subject: | Re: sinnvolle Filterregeln | | Date: | Mon, 1 Mar 2004 18:43:08 +0100 |
|
|
| Hallo Andreas,
> Warum müssen nur eingehende privilegierte Ports gesperrt
> werden? Was ist, wenn lokal eine Datenbank auf 3306 läuft
> und diese dann von außen erreichbar ist?
wenn die Datenbank auf dem FLI4L läuft hast Du Recht. Mit den gesperrten
Ports schütz Du nur den Router, nicht dahinter liegende Devices. Die sind
sowieso nur per NAT erreichbar und um die aktiv zu erreichen müsste auf dem
Router ein entsprechendes Portforwarding aktiviert sein.
Und eine Datenbank hat auf einem Router nichts zu suchen; ein Router ist ein
Router!
> Es müssen zunächst alle eingehenden Ports gesperrt werden.
Damit würdest Du auch Antwortports sperren; IMHO also ein Schmarren!
> Warum nicht drop, sondern reject?
Drop bedeutet, das Verbindungen abgewürgt werden. Reject beendet eine
Verbindung "ordentlich" und gibt eine Meldung zurück.
Sind damit die Fragen beantwortet?
Viele Grüße
Stefan
--
PGP verfügbar
|
|
| | From: | Andreas Rittershofer | | Subject: | Re: sinnvolle Filterregeln | | Date: | Mon, 01 Mar 2004 17:57:09 GMT |
|
|
| On Mon, 1 Mar 2004 18:43:08 +0100, "Stefan Heidrich"
wrote:
>> Warum müssen nur eingehende privilegierte Ports gesperrt
>> werden? Was ist, wenn lokal eine Datenbank auf 3306 läuft
>> und diese dann von außen erreichbar ist?
>wenn die Datenbank auf dem FLI4L läuft hast Du Recht. Mit den gesperrten
>Ports schütz Du nur den Router, nicht dahinter liegende Devices. Die sind
>sowieso nur per NAT erreichbar und um die aktiv zu erreichen müsste auf dem
>Router ein entsprechendes Portforwarding aktiviert sein.
>
>Und eine Datenbank hat auf einem Router nichts zu suchen; ein Router ist ein
>Router!
>
Am Ursprungsposting war nicht zu erkennen, dass es sich um einen
dezidierten Router handelt; es hätte auch durchaus sein können, dass
es ein Linux-Server mit Router-Funktionalität handelt - daher meine
obige Antwort.
>> Es müssen zunächst alle eingehenden Ports gesperrt werden.
>Damit würdest Du auch Antwortports sperren; IMHO also ein Schmarren!
Nein. Ich schrieb "zunächst". Das NAT macht natürlich nicht nur den
hohen Port für die Anfrage nach außen auf, sondern auch für die
Antwort nach innen.
>
>> Warum nicht drop, sondern reject?
>Drop bedeutet, das Verbindungen abgewürgt werden. Reject beendet eine
>Verbindung "ordentlich" und gibt eine Meldung zurück.
Das erklärt zwar, was passiert - das wusste ich schon vorher - aber
nicht warum, wie ich gefragt habe. Ich bin der Meinung, dass ich auf
Ports, auf denen ich nichts anbiete, ich durchaus ein drop machen
kann.
mfg ar
--
E-Learning mit dem LmTM-Server:
http://www.LmTM.de/
|
|
|
