WG als Router mit Absicherung des heimischen Netzes

[geologe]

Bist Du Dir sicher, dass du den Squid richtig als transparenten Proxy konfiguriert hast?
Als alles an einer Netzwerkkarte hing, muß es nicht funktioniert haben , sondern ist vielleicht am Proxy vorbei.

bin mir schon sicher, die transparenten Aufrufe standen im Proxy-Log

hinreichend nachgewiesen ?

Wenn du den Proxy manuell einträgst, fungiert er auch nicht als transparenter Proxy.
.... früher mußte man in der squid.conf was ändern, damit der Pakete, die redirected wurden untersucht.

ist klar, in der squid.conf steht:
http_port 192.168.2.4:3128 transparent
mehr wurde für die Transparenz nicht angegeben

die Policies hab ich auch ausprobiert.. kein Erfolg

grummel.....

Pah, jetzt hab ich folgendes in der squid.conf geändert
http_port 3128 transparent
also auf gut deutsch auf allen IP Adressen hören

und es geht !

netstat -npat|grep :3128

tcp        0      0 0.0.0.0:3128            0.0.0.0:*               LISTEN      2994/(squid)
tcp        0      0 192.168.2.4:3128        192.168.102.6:64013     VERBUNDEN   2994/(squid)
tcp        0      0 192.168.2.4:3128        192.168.102.6:63958     VERBUNDEN   2994/(squid)
tcp        0      0 192.168.2.4:3128        192.168.102.6:63955     VERBUNDEN   2994/(squid)
tcp        0      0 169.254.10.59:3128      192.168.2.136:1571      VERBUNDEN   2994/(squid)
tcp        0      0 192.168.2.4:3128        192.168.102.6:64015     VERBUNDEN   2994/(squid)
tcp        0      0 169.254.10.59:3128      192.168.2.136:1573      VERBUNDEN   2994/(squid)
tcp        0      0 192.168.2.4:3128        192.168.102.6:63954     VERBUNDEN   2994/(squid)
tcp        0      0 169.254.10.59:3128      192.168.2.136:1572      VERBUNDEN   2994/(squid)
tcp        0      0 169.254.10.59:3128      192.168.2.136:1574      VERBUNDEN   2994/(squid)
tcp        0      0 192.168.2.4:3128        192.168.102.6:63956     VERBUNDEN   2994/(squid)
tcp        0      0 192.168.2.4:3128        192.168.102.6:64016     VERBUNDEN   2994/(squid)
tcp        0      0 192.168.2.4:3128        192.168.102.6:64014     VERBUNDEN   2994/(squid)
tcp        0      0 192.168.2.4:3128        192.168.102.6:63953     VERBUNDEN   2994/(squid)

interessant, die Anfragen des manuell eingetragenen Proxies (192.168.102.6 = PC über VPN) schlagen auf 192.168.2.4 auf,
die des Umgeleiteten PC's auf 169.254.10.59 (eth0:avahi)

ok, ich hatte einen anderen Grund für den Test, nämlich die Vermutung die Anfrage kommt hinter'm NAT auf eth1

was ist eth0:avahi genau ?
(google machthier nicht wirlich schlau, irgendwas aus der automatischen Konfiguration..)

na jedenfall ist das Problem gelöst !

besten Dank für Deine Unterstützung !

dann werd ich jetzt mal beim clamav weitermachen

Letzendlich - wenn auch clamav läuft - wird dann ja auf Dansguardian umgeleitet, hier gilt die Erkenntnis dann wohl analog.


ciao
michael

[roestle]

interessant, die Anfragen des manuell eingetragenen Proxies (192.168.102.6 = PC über VPN) schlagen auf 192.168.2.4 auf,
die des Umgeleiteten PC's auf 169.254.10.59 (eth0:avahi)

REDIRCT -> macht, dass das Paket auf die IP-Adresse des eingehenden Interfaces geleitet wird
Folglich kommen deine Requests mal auf 192.168.2.4 und mal auf 169.254.10.59 rein.

was ist eth0:avahi genau ?

Der Grund, warum du zwei Interfaces hast (eth0 und eth0:avhi) ist, Zeroconf konnte über dhcp keine Ip-Adress ermitteln und hat deswegen die 169.254.10.59 vergeben. Manuell wirst du noch die 192.168.2.4 vergeben haben.
Nebenbei läuft den Proxy jetzt auch auf eth1, wird aber durch iptables geblockt und acls hast du auch, ist also nur ein wenig schlimm .


Grüße,

Mathias

[geologe]

Kannes sein das in der Zeile ein Ziel fehlt?
...hinter die 80 noch ein "-" und das Interface oder IP kommen muß.

hast garnicht so schlecht gelegen mit der ursache

aber die beiden nächsten Parameter sind doch Sourceport und original destination (danach ratelimit und usergroup)

ich hatte ursprünglich schon probiert an Dest: 192.168.2.4:3128 umzuleiten, aber dieses Argument lies Shorewall nicht zu

ERROR: REDIRECT rules cannot  specify a server IP; rule: "REDIRECT loc 192.168.2.4:3128 tcp 80     "

ebenso:
 ERROR: Unknown interface :eth0 in rule: "REDIRECT loc eth0:3128 tcp 80     "

oder:
 ERROR: Unknown interface :fw in rule: "REDIRECT loc fw:3128 tcp 80     "

der Vollständigkeit halber wäre ich an dieser Lösung auch interessiert

ciao
Michael

[arosy]

der Vollständigkeit halber wäre ich an dieser Lösung auch interessiert

ciao
Michael

Wenn ich das jetzt aus dem Kopf zusammen bekomme:

REDIRECT loc 3128 tcp 80 - 192.168.1.1

Ist auch beim mehreren Ip/Interfacen eindeutig und sauber.
192.168.1.1 natürlich entsprechen deiner Wunsch Squid-Ip.




Cu
Andreas

[geologe]

REDIRECT loc 3128 tcp 80 - 192.168.1.1

geht nicht und hätte mich auch schwer gewundert

weil an dieser Stelle die Orig Dest steht, also die ursprüngliche Zieladresse und die wird irgendwo im Internet liegen

wenn, muß die Zieladesse irgendwo anders stehen

ciao
Michael

[arosy]

weil an dieser Stelle die Orig Dest steht, also die ursprüngliche Zieladresse und die wird irgendwo im Internet liegen

wenn, muß die Zieladesse irgendwo anders stehen

Was sagt uns das? Man sollte irgendwann Feierabend machen.

Ist ja logisch ohne den letzten Parameter redirected er alles auch die eigene IP. Deshalb fehlt in meiner Zeile nur eine Kleinigkeit:

REDIRECT loc 3128 tcp 80 - !192.168.1.1

So sollte es gehen. Alles außer der Squid-IP.

[roestle]

Du solltest deine Netzwerkkonfiguration noch aufräumen, sonst wirst du vermutlich noch das ein oder andere mal merkwürdige Probleme mit Diensten bekommen, die einfach mit Interfaces konfiguriert werden.

Und die Regel, um alle Pakete, die von lokal kommen (also eth0 inklusive aller alias) auf die IP 192.168.2.4 umzuleiten, muß vermutlich so aussehen:

REDIRECT loc [COLOR=Red][B]fw:192.168.2.4[B]:3128[/B][/B][/COLOR] tcp 80  -  !192.168.2.4

Der Teil mit '- !192.168.2.4' ist vermutlich überflüssig, da die Pakete vom Squid bereits in der firewall-zone sind und somit als source nicht loc.

Grüße,

Mathias

[geologe]

Hallo Mathias,

Du solltest deine Netzwerkkonfiguration noch aufräumen..

ja, wirklich gerne

"- !192.168.2.4" hatte ich schon mehrfach mit drin, letztendlich ohne jegliche Auswirkung (die ich auch realisiert hätte)

Regel, um alle Pakete, die von lokal kommen...

REDIRECT loc [COLOR=Red][B]fw:192.168.2.4[B]:3128[/B][/B][/COLOR] tcp 80  -  !192.168.2.4

ich mach's kurz:

 ERROR: REDIRECT rules cannot  specify a server IP; rule: "REDIRECT loc fw:192.168.2.4:8080 tcp 80 - !192.168.2.4   "

derzeitige shorewall 4.0.15-1 unter lenny !

sorry, das Bett ruft - trotz Urlaub...

ciao
Michael

[roestle]

ERROR: REDIRECT rules cannot specify a server IP; rule: "REDIRECT loc fw:192.168.2.4:8080 tcp 80 - !192.168.2.4 "

Mist, da hätte ich auch selber dran denken können, iptables REDIRECT hat ja garkeine Option zum angeben der IP-Adresse, nur --to-ports .
Es wird immer auf die IP des eingehenden Interfaces umgeleitet, hab ich doch vor der Feier sogar geschrieben .
Es bleibt dir also nur das Aufräumen der Netzwerkeinstellungen übrig oder so zu tun, als würde squid nicht auf der firewall, sondern im lokalen Netz laufen . Naja, oder halt Squid auf allen Interfaces laufen lassen .

[geologe]

Es bleibt dir also nur das Aufräumen der Netzwerkeinstellungen übrig .....

auch

dann gib mal bitte sachdienliche Hinweise wo ich anfangen soll

ich kämpfe mich gerade durch die Logoptionen der versch. Programme und die zugehörigen Logfiles

gibt es eine "geschickte" Methode um sich alles was IPTABLES, SQUID und Co (Dansguardian, Clamav) abgewiesen haben zentral zu loggen ?

ciao
Michael

[roestle]

dann gib mal bitte sachdienliche Hinweise wo ich anfangen soll

Uh, das wird kompliziert .
Als erstes shorewall abschalten .
Am besten bei den Interfaces anfangen. Die Debian/Linux Network HOWTOs inklusive Zerconf/avahi lesen. Und dann solange konfigurieren, bis bei 'ifconfig -a' nur noch eht0, eth1 und lo stehen. (Ich weiß grade allerdings nicht, ob avahi nicht sowieso immer einen alias für die Schnittstelle ala eth0:avahi anlegt, dann sollte die aber wenigstens eine gültige ip-adresse aus dem Netzwerk bekommen).
Dafür also dchpd Konfiguration überprüfen.
Manpage von tcpdump studieren, für den Anfang reicht vielleicht "tcpdump not port ssh".
Wenn Du ipv6 machen willst, dann wird es noch ein wenig komplizierter.
Das externe Interface kann übrigens ruhig per DHCP eine Ip-Adresse vom Telekom-Dinges bekommen.
Du hast Dir ziemlich hohe Ziele gesteckt .
Wenn die Interfaces alle richtig laufen, dann wieder zurück zu den Diensten und shorewall.
Prüfen auf welchen Interfaces/Ip-Adressen die Dienste laufen.
Idealerweise sollten alle, die nur intern sind, auch nur auf dem internen Interface laufen und auch nur diese Seite bedienen.
Hatte ich tcpdump schon erwähnt?

gibt es eine "geschickte" Methode um sich alles was IPTABLES, SQUID und Co (Dansguardian, Clamav) abgewiesen haben zentral zu loggen ?

Hmm, ausser alle Dienste in die selbe Syslog-Datei loggen zu lassen, hmm, nein. Bei IPTABLES/Shorwall gibts jedenfalls definitiv die Möglichkeit auch alle REJECT und DROP Pakete zu loggen. Bei Squid kann man debugging einschalten, um sämtliche Entscheidungen zu loggen. Dansguardan und Clamav kann ich dir leider nichts zu sagen.
Möchtest Du eigentlich durch die abgewiesenen Sachen irgendwelche Gegenmaßnahmen einleiten und/oder Angriffe erkennen? Dafür gibts spezielle IDS-Software (Intrusion Detection System) oder willst Du nur am Anfang wissen wo es hängt?
Hatte ich schon gesagt, dass Du Dir ziemlich hohe Ziele gesteckt hast .
Das Wiregate als rundumglücklich Box, mit all den automatischen Helferlein, in eine Firewall zu verwandeln ist nicht ohne.
Ich denk aber, Du bist auf dem richtigen Weg :thumbsup:.

Grüße,

Mathias

[geologe]

Uh, das wird kompliziert .
...
Das externe Interface kann übrigens ruhig per DHCP eine Ip-Adresse vom Telekom-Dinges bekommen.

bekommt es schon - soll aber (viel?) später auf eth1 nur noch mit einem DSL Modem kommunizieren

dazu brauche ich dann Multicast nur auf einer eth2 (IP TV) damit ich nicht das ganze Netz (auf eth0) damit verseuche

die eth2 gibt es übrigends physikalisch schon, dann fang ich da gleich mal mit der sauberen Konfig an

Du hast Dir ziemlich hohe Ziele gesteckt .
Wenn die Interfaces alle richtig laufen...

Hatte ich tcpdump schon erwähnt?

nö und nochmal na

ok, Danke für den roten Faden, da bin ich ja dann eine Weile beschäftigt...

...Gegenmaßnahmen einleiten und/oder Angriffe erkennen?

primär dient es zum besseren Verständnis, insbesondere wenn noch irgendwas nicht geht - aber wer weiss, IDS wäre schon schick...

jaja, die hochgesteckten Ziele....

Das Wiregate als rundumglücklich Box ... in eine Firewall zu verwandeln ist nicht ohne.
Ich denk aber, Du bist auf dem richtigen Weg :thumbsup:.

Danke, das macht Mut.

Bis jetzt ist CPU Last kein Problem, auch die Flash Zugriffe halten sich noch sehr in Grenzen, bin gespannt wann die Grenze kommt - außerdem brauchen wir doch eine Anwendung für's WG2 oder }:->

ciao
Michael

[makki]

Der Grund, warum du zwei Interfaces hast (eth0 und eth0:avhi) ist, Zeroconf konnte über dhcp keine Ip-Adress ermitteln und hat deswegen die [/COLOR][/COLOR][COLOR=Blue][COLOR=black]169.254.10.59 vergeben.

Äh nee, das liegt daran das in
/etc/dhcp3/dhclient-exit-hooks.d/zzz_avahi-autoipd
und
/etc/network/if-up.d/avahi-autoipd

--force-bind drinsteht. Nicht Standard, aber durchaus volle Absicht damit man per Auto-IP immernoch draufkommt, fast egal wie arg es verkonfiguriert ist

Makki

P.S.: Ich nutze übrigens selbst ein WG als Router am VDSL50 mit PPPoE aber ohne Squid und so..

[geologe]

Hallo Makki

schön von Dir zu hören (lesen), ich wollt schon fragen....

Äh nee, das liegt daran das in
/etc/dhcp3/dhclient-exit-hooks.d/zzz_avahi-autoipd --force-bind drinsteht.

Humor ist wenn man trotzdem lacht
ok, da steht folgendes drin

case "$reason" in
    MEDIUM|ARPCHECK|ARPSEND|NBI)
        ;;

    PREINIT|BOUND|RENEW|REBIND|REBOOT|STOP)
    /usr/sbin/avahi-autoipd -swD[COLOR=Red] --force-bind[/COLOR] $interface 2> /dev/null
        ;;
    
    EXPIRE|FAIL|RELEASE|TIMEOUT)
        /usr/sbin/avahi-autoipd -swD [COLOR=Red]--force-bind[/COLOR] $interface 2> /dev/null
        ;;
esac

langt da wirklich force-bind zu löschen ?

ich würde das avahi Interface gerne komplett über Bord.....

und
/etc/network/if-up.d/avahi-autoipd

[ "$IFACE" != "lo" ] || exit 0
case "$ADDRFAM" in
  inet|NetworkManager) ;;
  *) exit 0
esac

case "$METHOD" in
    static)
    /usr/sbin/avahi-autoipd -swD [COLOR=Red]--force-bind [/COLOR]$IFACE 2> /dev/null
    ;;
    dhcp|NetworkManager) ;;
    *) exit 0
esac


if [ -x /bin/ip ]; then
    # route already present?
    ip route show | grep -q '^169.254.0.0/16[[:space:]]' && exit 0

    /bin/ip route add 169.254.0.0/16 dev $IFACE metric 1000 scope link
elif [ -x /sbin/route ]; then
    # route already present?
    /sbin/route -n | egrep -q "^169.254.0.0[[:space:]]" && exit 0

    /sbin/route add -net 169.254.0.0 netmask 255.255.0.0 dev $IFACE metric 1000
fi

Nicht Standard, aber durchaus volle Absicht

ok, Monitor und Tastatur gibts ja auch noch - so im Notfall.

also nur die roten Sachen löschen oder alles hopp ?

ciao
Michael

[makki]

Habs jetzt nicht getestet aber ausm Bauch: nur das rote --force-bind hab ich hinzugefügt..
Das mag in dem Fall nicht erwünscht sein, ich kann aber nicht versprechen das es mit irgendeinem Update dann doch wieder reingeblasen wird (normalerweise achte ich aber darauf, wenn ich es weiss.. ist halt schwer, auf der einen Seite soll es doch bitte ohne Freakshow/Linux Know-how funktionieren, auf der anderen auch der letzte Geek bedient werden )

Makki