Apache von aussen durch DNAT erreichbar machen

chadi_Abdul_Rida_a1e8ba · 7. November 2019 um 03:00

hallo erstmal,

Linux Newbie
OS: Suse Linux 8.2 als Gateway. IP:192.168.100.99 Subet:255.255.255.0
T-Online dynamische IP-Zuweisung
externes interface: ppp0
internes Interface: eth1
Im Netzwerk befindet sich ein Windows XP Rechner mit Apache(IP:192.168.100.98).
Dieser soll von aussen erreichbar sein. Ich habe also die susefirewall
deaktiviert, ein Skript zur Erstellung der nötigen iptables heruntergeladen und
ein wenig modifiziert, und schließlich über den runlevel-editor für runlevel
2,3,5 aktiviert. Jedoch will das mit dem externen Zugriff auf dem Apache
einfach nicht klappen. Hier ist das script:

#/bin/sh
########################################################

Skript: Firewall-Skript fuer DSL-Router

########################################################

Author: [email protected]

Datum : 16.02.2003

Status: funktiostuechtiges Beispiel

########################################################

Dieses Skript darf und soll von jedem kopiert

und veraendert werden.

Fuer Anregungen aller Art bin ich jederzeit dankbar.

########################################################

#— Forwarding aktivieren —
echo -n ‚.‘
echo 1 >> /proc/sys/net/ipv4/ip_forward
echo 1 >> /proc/sys/net/ipv4/ip_dynaddr

#— Netfilter-Module laden —
echo -n ‚.‘
modprobe ip_tables
echo -n ‚.‘
modprobe iptable_filter
modprobe iptable_nat
echo -n ‚.‘
modprobe ip_conntrack
modprobe ip_conntrack_ftp
modprobe ip_conntrack_irc
echo -n ‚.‘
modprobe ip_nat_ftp
modprobe ip_nat_irc
echo -n ‚.‘
modprobe ipt_unclean
modprobe ipt_state
modprobe ipt_tcpmss
echo -n ‚.‘
modprobe ipt_MASQUERADE
modprobe ipt_TCPMSS
modprobe ipt_LOG

#— alte Regeln löschen —
echo -n ‚.‘
iptables -t filter -F
iptables -t nat -F

#— Default Policy setzen —
echo -n ‚.‘
iptables -t filter -P INPUT ACCEPT
iptables -t filter -P FORWARD ACCEPT
iptables -t filter -P OUTPUT ACCEPT
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT

#— Masquerading aktivieren —
echo -n ‚.‘
iptables -t nat -A POSTROUTING -o ppp0 -s 192.168.0.0/16 -j MASQUERADE

#— MSS der Pakete ins I-Net an die MTU von DSL (=1492) anpassen —
echo -n ‚.‘
iptables -A FORWARD -o ppp0 -p TCP --tcp-flags SYN,RST SYN -j TCPMSS
–clamp-mss-to-pmtu

#---- Massnahmen gegen Angriffsversuche ergreifen
----------------------------->
echo -n ‚.‘

#-- ungewöhnliche/defekte Pakete verwerfen –

forwarding

#iptables -A FORWARD -m unclean -j DROP

local input

#iptables -A INPUT -m unclean -j DROP

#-- Pakete aus I-Net mit privaten (gefaelschten) Absenderadressen verwerfen –

prerouting

#iptables -t nat -A PREROUTING -i ppp0 -s 192.168.0.0/16 -j DROP
#iptables -t nat -A PREROUTING -i ppp0 -s 10.0.0.0/8 -j DROP
#iptables -t nat -A PREROUTING -i ppp0 -s 172.16.0.0/12 -j DROP
#iptables -t nat -A PREROUTING -i ppp0 -s 127.0.0.0/8 -j DROP

forwarding

#iptables -A FORWARD -i ppp0 -s 192.168.0.0/16 -j DROP
#iptables -A FORWARD -i ppp0 -s 10.0.0.0/8 -j DROP
#iptables -A FORWARD -i ppp0 -s 172.16.0.0/12 -j DROP
#iptables -A FORWARD -i ppp0 -s 127.0.0.0/8 -j DROP

local input

#iptables -A INPUT -i ppp0 -s 192.168.0.0/16 -j DROP
#iptables -A INPUT -i ppp0 -s 10.0.0.0/8 -j DROP
#iptables -A INPUT -i ppp0 -s 172.16.0.0/12 -j DROP
#iptables -A INPUT -i ppp0 -s 127.0.0.0/8 -j DROP

#---- Destination-NAT aktivieren
---------------------------------------------->
echo -n ‚.‘

#-- Apache Verbindungen nach 192.168.100.98 leiten –
iptables -t nat -A PREROUTING -i ppp0 -p TCP --dport 80 -j DNAT
–to-destination 192.168.100.98

#---- bestimmte Verbindungen aus I-Net erlauben
-------------------------------->
echo -n ‚.‘

#-- HTTP –
iptables -A INPUT -p TCP --dport 80 -j ACCEPT

#-- SSH –
#iptables -A INPUT -i ppp0 -p TCP --dport 22 -j ACCEPT

#-- FTP (mit offenen Ports für „passive mode“) –
#iptables -A INPUT -i ppp0 -p TCP --dport 21 -j ACCEPT
#iptables -A INPUT -i ppp0 -p TCP --dport 49152:65534 -j ACCEPT

#-- Ping –
iptables -A INPUT -i ppp0 -p ICMP --icmp-type ping -j ACCEPT

#-- Destination-NAT für lokales Netzwerk erlauben –
iptables -A FORWARD -i ppp0 -d 192.168.0.0/16 -j ACCEPT

#---- alle uebrigen Verbindungen aus I-Net abweisen
--------------------------->
echo -n ‚.‘

forwarding

iptables -A FORWARD -i ppp0 -m state --state NEW,INVALID -j LOG
iptables -A FORWARD -i ppp0 -m state --state NEW,INVALID -j DROP

local input

iptables -A INPUT -i ppp0 -m state --state NEW,INVALID -j LOG
iptables -A INPUT -i ppp0 -m state --state NEW,INVALID -j DROP

#---- Ende Firewall-Skript
---------------------------------------------------->
echo -n ‚.‘

Ich danke schon mal für jede Hilfe.

Anonym_d5503925c587 · 7. November 2019 um 03:01

Hi…

Linux Newbie
OS: Suse Linux 8.2 als Gateway. IP:192.168.100.99

Im Netzwerk befindet sich ein Windows XP Rechner mit
Apache(IP:192.168.100.98).
Dieser soll von aussen erreichbar sein.

#— Default Policy setzen —
iptables -t filter -P INPUT ACCEPT
iptables -t filter -P FORWARD ACCEPT

Default Policy Accept ist eine Fehlerquelle, wenn man irgendwo vergisst, alle nicht vorher ausdrücklich erlaubten Pakete wegzuwerfen. Außerdem braucht man das nicht explizit zu setzen.

#-- Apache Verbindungen nach 192.168.100.98 leiten –
iptables -t nat -A PREROUTING -i ppp0 -p TCP --dport 80 -j
DNAT --to-destination 192.168.100.98

Das passt.

#-- HTTP –
iptables -A INPUT -p TCP --dport 80 -j ACCEPT

Hier erlaubst Du HTTP auf den Linuxrechner, gleichzeitig willst Du es aber auf den Windowsrechner umleiten. Eins von beiden muß schiefgehen, allerdings wäre es logischer, daß kein Zugriff auf den Linuxrechner möglich ist, da PREROUTING nach meinem Verständnis vor INPUT kommt.
Kommentiere die Regel mal aus und schau, was passiert. Falls das nicht hilft, LOG-Regeln an strategischen Punkten einfügen und per tail -f /var/log/messages mitlesen, welche Pakete wo durch die Filter laufen.

#-- FTP (mit offenen Ports für „passive mode“) –
#iptables -A INPUT -i ppp0 -p TCP --dport 21 -j ACCEPT
#iptables -A INPUT -i ppp0 -p TCP --dport 49152:65534 -j ACCEPT

Dass sollte ip_conntrack_ftp eigentlich selbermachen. Wenn aber auf diesen Ports definitiv keine Dienste laufen, macht es nichts aus.

#-- Destination-NAT für lokales Netzwerk erlauben –
iptables -A FORWARD -i ppp0 -d 192.168.0.0/16 -j ACCEPT

Das ist ungewöhnlich, sollte aber auch gehen. Wenn es jemand schaffen sollte, ein Paket mit einer Zieladresse im Bereich 192.168 an Deiner ppp0 ankommen zu lassen, würde das weitergeleitet. Sowas kann allerdings nur Dein Provider veranstalten.

#---- alle uebrigen Verbindungen aus I-Net abweisen

iptables -A INPUT -i ppp0 -m state --state NEW,INVALID -j DROP

DROP bringt gegenüber REJECT keinen Sicherheitsvorteil. Insbesondere werden Portscans nicht, wie oft behauptet, verlangsamt. Was es tatsächlich verlangsamt ist der Verbindungsaufbau aus dem lokalen Netz zu den meisten IRC-Servern. Daher würde ich REJECT empfehlen.

genumi

Der_Frank_176821 · 7. November 2019 um 03:01

#— Default Policy setzen —
iptables -t filter -P INPUT ACCEPT
iptables -t filter -P FORWARD ACCEPT

Default Policy Accept ist eine Fehlerquelle, wenn man irgendwo
vergisst, alle nicht vorher ausdrücklich erlaubten Pakete
wegzuwerfen. Außerdem braucht man das nicht explizit zu
setzen.

Ich bin auch fuer -P DROP. Die letzte Regel jeder Kette sollte darueberhinaus -j REJECT sein. Und vor jedes REJECT, egal wo, ein -j LOG (zum debuggen).

#-- HTTP –
iptables -A INPUT -p TCP --dport 80 -j ACCEPT

Hier erlaubst Du HTTP auf den Linuxrechner, gleichzeitig
willst Du es aber auf den Windowsrechner umleiten. Eins von
beiden muß schiefgehen, allerdings wäre es logischer, daß kein
Zugriff auf den Linuxrechner möglich ist, da PREROUTING nach
meinem Verständnis vor INPUT kommt.

Die Pakete stecken in der FORWARD, INPUT ist AFAICS voellig irrelevant.

#-- FTP (mit offenen Ports für „passive mode“) –
#iptables -A INPUT -i ppp0 -p TCP --dport 21 -j ACCEPT
#iptables -A INPUT -i ppp0 -p TCP --dport 49152:65534 -j ACCEPT

Dass sollte ip_conntrack_ftp eigentlich selbermachen. Wenn
aber auf diesen Ports definitiv keine Dienste laufen, macht es
nichts aus.

Kuemmert sich das conntrack auch um eingehende FTP? Will der OP ueberhaupt einen FTP-Server auf seinem gateway betreiben? Sehr fragwuerdig.

#-- Destination-NAT für lokales Netzwerk erlauben –
iptables -A FORWARD -i ppp0 -d 192.168.0.0/16 -j ACCEPT

Das ist ungewöhnlich, sollte aber auch gehen. Wenn es jemand
schaffen sollte, ein Paket mit einer Zieladresse im Bereich
192.168 an Deiner ppp0 ankommen zu lassen, würde das
weitergeleitet. Sowas kann allerdings nur Dein Provider
veranstalten.

Ich haette die Regel auch etwas enger geschnuert.

#---- alle uebrigen Verbindungen aus I-Net abweisen
iptables -A INPUT -i ppp0 -m state --state NEW,INVALID -j DROP

DROP bringt gegenüber REJECT keinen Sicherheitsvorteil.
Insbesondere werden Portscans nicht, wie oft behauptet,
verlangsamt.

Hui? -v please.

Was es tatsächlich verlangsamt ist der Verbindungsaufbau aus
dem lokalen Netz zu den meisten IRC-Servern.

Ebenfalls -v, bitte.

Daher würde ich REJECT empfehlen.

Full ACK.

Ich seh auch nicht so ganz das Problem des OP. Kann er vielleicht mal mit der Ausgabe von

# iptables-save

wiederkommen? Vielleicht klemmt’s ja irgendwo. Auch ein

# watch -d iptables -nvL $chain --line-numbers

und ein gleichzeitiger Verbindungsaufbau haben bei mir schon fuer so manche Erleuchtung gesorgt.

HTH,
Gruss vom Frank.

Anonym_d5503925c587 · 7. November 2019 um 03:03

Hi…

#-- HTTP –
iptables -A INPUT -p TCP --dport 80 -j ACCEPT

Hier erlaubst Du HTTP auf den Linuxrechner, gleichzeitig
willst Du es aber auf den Windowsrechner umleiten. Eins von
beiden muß schiefgehen, allerdings wäre es logischer, daß kein
Zugriff auf den Linuxrechner möglich ist, da PREROUTING nach
meinem Verständnis vor INPUT kommt.

Die Pakete stecken in der FORWARD, INPUT ist AFAICS voellig
irrelevant.

Da alles, was von außen auf Port 80 kommt, schon in PREROUTING umadressiert wird, sollte es nie in INPUT ankommen, richtig. D.h. obige Regel kann man sich schenken, weil sie nie zutreffen wird. Da ich in seinen FORWARD-Regeln keinen Fehler entdeckt habe, kam die leise Vermutung auf, daß die Reihenfolge der Chains anders ist, als ich dachte.

#-- FTP (mit offenen Ports für „passive mode“) –
#iptables -A INPUT -i ppp0 -p TCP --dport 21 -j ACCEPT
#iptables -A INPUT -i ppp0 -p TCP --dport 49152:65534 -j ACCEPT

Dass sollte ip_conntrack_ftp eigentlich selbermachen. Wenn
aber auf diesen Ports definitiv keine Dienste laufen, macht es
nichts aus.

Kuemmert sich das conntrack auch um eingehende FTP? Will der

Ich denke schon.

OP ueberhaupt einen FTP-Server auf seinem gateway betreiben?

Tja. Keine Ahnung.

DROP bringt gegenüber REJECT keinen Sicherheitsvorteil.
Insbesondere werden Portscans nicht, wie oft behauptet,
verlangsamt.

Hui? -v please.

Bei REJECT erfährt der anfragende Rechner sofort, daß er nicht durchkommt. Das einzige, was ein Angreifer daraus schliessen kann, ist, daß eine Firewall vorhanden ist. Das kann er aber auch auf anderem Wege herausbekommen.
Bei DROP muß er einen Timeout abwarten, wiederholt da Paket vielleicht und muß nochmal warten. Einen Portscanner interessiert das aber nicht, weil er während des Wartens munter weiter Pakete an die anderen Ports abschickt. Nur den Timeout des letzten abgeschickten Pakets muß er abwarten. Wenn, wie üblich, nicht ein einzelner Rechner, sondern ein ganzes Subnet gescannt wird, dauert der gesamte Scanvorgang auch maximal um einen Timeout länger - vernachlässigbar.

Was es tatsächlich verlangsamt ist der Verbindungsaufbau aus
dem lokalen Netz zu den meisten IRC-Servern.

Ebenfalls -v, bitte.

Die IRC-Server, die ich kenne, versuchen bei jedem Login einen Zugriff auf den identd des Benutzers. Wenn der ein DROP auf Port 113 hat, wartet der Server seinen Timeout ab, bevor er einsieht, daß kein identd läuft. Erst dann wird die Verbindung hergestellt.

watch -d iptables -nvL $chain --line-numbers

Ei, den kannte ich noch gar nicht…

genumi