staging.inyokaproject.org

Hallo @ all,

Folgende Ausgangssitation:

Server mit Ubuntu 7.10
SSH, squid und ppoe

Das Gerät stellt den Internetzugang für mehrere Benutzer über DSL zur Verfügung.

eth1 - 192.168.50.1 \–– proxy squid + firewall mittels IP Tables –- eth0 192.168.20.1-– adsl Modem

Ich möchte nun die Nutzung des squid proxy erzwingen indem ich in der Firewallregel alle IP Pakete welche je normalerweise an port 80 bzw. 443 gehen
an port 3128 umleite. Meiner Meinung nach passiert dies für die Datenpakete vor allen anderen Routingeinstellung und wäre somit mit einer Preroutingregel einzustellen.

Folgende Regel habe ich also in meine firewall.rc eingesetzt:
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j REDIRECT --to-port 3128

Hiermit habe ich nun zwar alle Datenpakete auf den port 3128 (und somit auf den proxy) "umgebogen" - nun komme ich aber mit meinen clients nicht mehr raus.
Eingetragen auf den clients ist 192.168.50.1:3128 im IE Browser.

Setze ich meine INPUT und OUTPUT policy der firewall.rc auf ACCEPT geht alles. Somit ist meine squid.conf ok. und es fehlt mir ein weiterer Routingeintrag - Pakete von eth1 source port 3128 müßten nun doch mittels Forward an das DSL Modem geleitet werden und Antworten entsprechend zurück. Egal welche Forward Regel ich eintrag es haut einfach nicht hin. ☹

Anbei meine firewall.rc

#!/bin/sh

/sbin/modprobe ip_tables
/sbin/modprobe ip_conntrack
/sbin/modprobe ip_conntrack_ftp
/sbin/modprobe ip_conntrack_irc
/sbin/modprobe iptable_nat
/sbin/modprobe ip_nat_ftp

echo "1"> /proc/sys/net/ipv4/ip_forward
echo "1"> /proc/sys/net/ipv4/ip_dynaddr

iptables -F
iptables -t nat -F
iptables -t mangle -F

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

### Umleitung zu proxy
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j REDIRECT --to-port 3128
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 443 -j REDIRECT --to-port 3128

iptables -A OUTPUT -p udp --sport 1024: --dport 53 -j ACCEPT
iptables -A INPUT -p udp -s 217.237.150.205 --sport 53 --dport 1024: -j ACCEPT
iptables -A OUTPUT -p tcp --sport 1024: --dport 53 -j ACCEPT
iptables -A INPUT -p tcp -s 217.237.150.205 --sport 53 --dport 1024: ! --syn -j ACCEPT
iptables -A OUTPUT -p tcp --sport 1024: --dport 3128 -j ACCEPT
iptables -A INPUT -p tcp --sport 3128 --dport 1024: ! --syn -j ACCEPT

iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

iptables -A OUTPUT -p tcp --sport 1024: --dport 25 -j ACCEPT
iptables -A INPUT -p tcp --sport 25 --dport 1024: ! --syn -j ACCEPT

iptables -A OUTPUT -p tcp --sport 1024: --dport 110 -j ACCEPT
iptables -A INPUT -p tcp --sport 110 --dport 1024: ! --syn -j ACCEPT

iptables -A INPUT -i eth1 -p tcp -s 192.168.50.0/24 -d 192.168.50.1 --sport 32000: --dport 22 -j ACCEPT
iptables -A OUTPUT -o eth1 -p tcp -s 192.168.50.1 -d 192.168.50.0/24 --sport 22 --dport 32000: ! --syn -j ACCEPT
iptables -A OUTPUT -o eth1 -p tcp -s 192.168.50.1 -d 192.168.50.0/24 --sport 32000: --dport 22 -j ACCEPT
iptables -A INPUT -i eth1 -p tcp -s 192.168.50.0/24 -d 192.168.50.1 --sport 22 --dport 32000: ! --syn -j ACCEPT

# iptables -A INPUT -p icmp -s 192.168.0.0/16 -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type echo-request -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type echo-reply -j ACCEPT
iptables -A FORWARD -o ppp0 -p icmp --icmp-type echo-request -j ACCEPT
iptables -A FORWARD -i ppp0 -p icmp --icmp-type echo-reply -j ACCEPT

iptables -A FORWARD -o ppp0 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

iptables -A FORWARD -i ppp0 -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

# restliche eintreffende Pakete verwerfen

iptables -A INPUT -j DROP

Hat jemand einen Tipp??

Grüße Thomas

Hat niemand eine Idee ??

Hy, ich habe es kurz überflogen und meiner Meinung nach hast Du einen kleinen Denkfehler:

▶ Du hast zwar im Prerouting die Ports umgebogen
▶ Dann erlaubst Du aber vom Server ausgehende Verbindungen zu Port 3128
▶ Und eingehende Verbindungen auf den Server von Port 3128

❗ Aber was Du möchtest sind eingehende Verbindungen auf Port 3128 (INPUT) und ausgehende zu Port 80 und 443 (OUTPUT). Denn Deine Clients möchten auf Deinen Squid (Port 3128 ) zugreifen und der Squid wiederum im Internet auf die Server (Port 80 + 443).

Gruß, Björn

Hallo Björn,

vielen Dank für Deine Rückmeldung !!

was Du sagst leuchtet mir ein. Ich habe folgende Regel modifiziert:

iptables -A INPUT -i eth1 -p tcp --sport 1024: --dport 3128 ! --syn -j ACCEPT
iptables -A OUTPUT -i eth0 -p tcp --sport 3128 --dport 80 - j ACCEPT

was mir noch nicht klar ist: Was ist mit dem Forwarding - ist das überhaupt nötig?

Der Proxy tritt doch als "Vermittler" auf - d. h. er stellt die Verbindung ins Internet her ( hier läuft bei mir ja auch die Firewall.
Die clients wenden sich wiederum zur Internetverbindungsherstellung über den Browser an den Proxy - d.h. ein Forwarding ist doch gar nicht nötig.

Wäre das Forwarding in dem Falle nicht auszu dokumentieren??

Gruß Thomas

Hy Thomas,

grundsätzlich benötigst Du natürlich kein Forwarding. Aber Dein Forwarding erlaubt eh nur den PING (icmp echo-request und reply) und alle Verbindungen, die zu bereits aufgebauten Sessions gehören. Alleine um ein wenig Diagnose aus den LAN betreiben zu können würde ich auch zumindest den PING immer erlauben.

Gruß, Björn

Hallo Björn,

ich blicks nicht ☹

welche Regeln müssen denn nun in die Firewall rein damit der client nur über meinen proxy ins Internet kann und ohne den Eintrag draußen bleibt ?

eth0 = NIC zu DSL Modem
eth1 = NIC internes LAN

iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j REDIRECT --to-port 3128

Folgendes habe ich jetzt zugefügt - haut aber auch nicht hin

iptables -A INPUT -i eth1 -p tcp --sport 1024: --dport 3128 -j ACCEPT
iptables -A OUTPUT -i eth1 -p tcp --sport 3128: --dport 80 -j ACCEPT

iptables -A INPUT -i eth0 -p tcp --sport 3128 --dport 80 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -i eth0 -p tcp --sport 80 --dport 3128 - j ACCEPT

Was fehlt denn noch ???

Gruß Thomas

PapaTom hat geschrieben:

Setze ich meine INPUT und OUTPUT policy der firewall.rc auf ACCEPT geht alles. Somit ist meine squid.conf ok.

Nein, nicht unbedingt. Wenn ein Browser bewusst einen eingetragenen Proxy benutzt, sieht das anders aus, als wenn die Verbindung transparent im Router auf den Proxy umgeleitet wird. Damit das funktioniert, muss man eine Option in der squid.conf anpassen:

http_port 3128 transparent

(Ab Squid 2.6. Davor war es komplizierter.)
PapaTom hat geschrieben:

iptables -A OUTPUT -p tcp --sport 1024: --dport 3128 -j ACCEPT
iptables -A INPUT -p tcp --sport 3128 --dport 1024: ! --syn -j ACCEPT

Du solltest dir mal die Netfilter-Dokumentation auf http://netfilter.org durchlesen. Die Option --syn ist völlig sinnlos, wenn man konsequent -m state benutzen kann. Also verstehe lieber erstmal, wie das mit dem Paketfilter funktioniert, und plane das dann logisch, anstatt einfach irgendwie rumzuprobieren bis es scheinbar funktioniert.

Wahrscheinlich brauchst du aber sowieso keinen Paketfilter, wenn du einfach nur stattdessen den Squid korrekt auf die LAN-Schnittstelle beschränkst.

Ein Proxy, der am Internet hängt und falsch konfiguriert ist, ist eine Spamschleuder und zieht Ärger mit dem Provider nach sich.

Hallo Otzenpunk

sowohl der Eintrag http_port 3128 transparent als auch die Bindung des proxys an eth1 sind bereits in squid.conf eingestellt.
Natürlich sollte man verstehen was man macht - es ist jedoch ziemlich ernüchternd nach tagelangem Lesen und probieren nicht weiter zu kommen.
Deswegen wende ich mich an dieses Forum !!
Solltest Du eine Antwort !! auf meine Frage haben wäre es schön wenn Du diese posten könntest.

Schönes Wochenende

Thomas

PapaTom hat geschrieben:

Solltest Du eine Antwort !! auf meine Frage haben wäre es schön wenn Du diese posten könntest.

Meine Antwort ist: Wenn du nach außen hin keine Dienste anbietest, brauchst du wahrscheinlich keinen Paketfilter. Und wenn du Dienste von deinem Server absichtlich im Internet anbietest, brauchst du auch keinen. Also schalte einfach alles an iptables-Regeln ab, was nicht mit NAT zu tun hat.

Ansonsten ist es natürlich nervig, wenn man tagelang gelesen hat und trotzdem zu keinem Ergebnis kommt, aber vielleicht hat man dann eben einfach den falschen Lesestoff gehabt. Dass du in deinem Skript sowohl -m state als auch --syn verwendest, lässt mich jedenfalls vermuten, dass du das aus diversen (teilweise endlos veralteten) Schritt-für-Schritt-Howtos zusammengepastet hast, und da sind fundamentale Fehler drin (u.a. eben dass du --syn überhaupt verwendest, oder dass alle wichtigen ICMP-Pakete geblockt werden, oder dass du mit den paarweisen Regeln durcheinanderkommst (was überhaupt nicht passieren würde, wenn du am Anfang einfach alle ESTABLISHED,RELATED-Pakete akzeptieren würdest und dich nur noch um NEW kümmerst)).

Meine Frage:

ist mein Vorhaben so schwer zu verstehen - oder stehe ich auf ner Leitung.
Ich sitze in meinem stillen Kämmerlein und habe hier zwei PC´s ( A und B) und einen DSL Anschluß. PC A hat wie gesagt zwei NIC´s und ist mit eth0 an PC B angebunden und mit eth1 am DSL Modem.
Alles was ich erreichen möchte ist:
PC A ist von der DSL Seite gesichert gegen ungewollte Eindringlinge
PC A stellt die Verbindung ins Internet her und dient als Proxy für PC B.
PC B soll ohne einen proxyeintrag im Internetbroser nicht ins Internet kommen.

Mein Ansatz war der zu sagen es wird über eine firewall auf PC A erst mal alles zugemacht. Dann mittels IPTables diverse Dienste (DNS, HTTP) kontrolliert öffnen.

Durch diesen Block:

iptables -A FORWARD -o ppp0 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i ppp0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

werden nun die Pakete von PC B weitergeleitet und maskiert.
Hoffentlich bin ich bis dahin auf dem richtigen Weg.

Nun soll PC A ja aber als "Mittelsmann" den Internetzugang herstellen und PC B soll Internetanfragen von PC A beantwortet bekommen.
Somit muss für mein Verständnis doch der gesamte Forwardblock entfallen - ???
Damit der squid auf eth1 ( internes LAN) auf port 3128 Datenpakete empfangen kann wird

im prerouting der port 80 auf den port 3128 umgelenkt
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j REDIRECT --to-port 3128

ferner muß eth1 tcp Datenpakete empfangen können und nicht geblockt sein.

Ist das bis dahin richtig ??