Diese Website existiert nur weil wir Werbung mit AdSense ausliefern.
Bitte den AdBlocker daher auf dieser Website ausschalten! Danke.

Suse-Firewall & Apache

Alles rund um das Internet, Internet-Anwendungen (E-Mail, Surfen, Cloud usw.) und das Einrichten von Netzwerken einschl. VPN unter Linux

Moderator: Moderatoren

Antworten
Empty
Newbie
Newbie
Beiträge: 10
Registriert: 9. Jul 2004, 17:30

Suse-Firewall & Apache

Beitrag von Empty »

Hallo,
einen Suse 9.0 Rechner als "Router" daheim stehen. Neuerdings läuft darauf auch ein Apache. Dieser ist über eine dyndns-Adresse auch von außen erreichbar. Soweit alles Bestens.
Allerdings ist der Apache nicht erreichbar, wenn ich mich auf der Gegenseite hinter einem Router bzw einer Firewall befinde. Anpingen ist jedoch möglich.

Hat da jemand einen Tip für mich?
gaw
Hacker
Hacker
Beiträge: 464
Registriert: 28. Sep 2004, 16:33

Beitrag von gaw »

Das kann verschiedene Gründe haben. Zum Beispiel könnte die Firewall auf dem Router oder auf der "Gegenseite" http Verkehr blockieren und icmp Pakete aber zulassen. Bist du den sicher dass dein apache vom Internet aus überhaupt auf dem Port 80 angesprochen werden kann, also dann wenn keine Firewall oder Router dazwischen hängen?


mfG
gaw
Empty
Newbie
Newbie
Beiträge: 10
Registriert: 9. Jul 2004, 17:30

Beitrag von Empty »

Mir ist noch was eingefallen:

Ich habe in der "personal-firewall"-datei den parameter REJECT_ALL_INCOMING_CONNECTIONS = " ppp0 masq" gesetzt.

wenn ich das ppp0 weglasse, lässt sich die firewall nicht mehr starten. jemand eine idee ?
gaw
Hacker
Hacker
Beiträge: 464
Registriert: 28. Sep 2004, 16:33

Beitrag von gaw »

English beherrscht zwar nicht jeder perfekt, aber ein Blick in ein Wörterbuch oder online http://leo.org zeigt dir was REJECT übersetzt bedeutet:

to reject ablehnen | lehnte ab, abgelehnt
to reject so. jmdn. ablehnen
to reject absagen
to reject absondern
to reject abstoßen
to reject abweisen | wies ab, bgewiesen
to reject so./sth. jmdn./etw. abweisen
to reject ausmustern
to reject ausschlagen | schlug aus, ausgeschlagen
to reject aussortieren
to reject ausstoßen
to reject nicht annehmen
to reject reflektieren
to reject verwerfen | verwarf, verworfen

Was all incoming connection bedeutet sollte auch mit rudimentären Englisch Kenntnissen erfassbar sein.

Der Parameter fordert also dazu auf alles was an Verbindungen hereinkommt zu verwerfen. Als Parameter erwartet die Firewall eine Schnittstelle wie eth0 oder ppp0. masq ist keine Schnittstelle sondern sagt der Firewall lediglich, dass die entsprechende Schnittstelle maskiert wird. Daher startet die Firewall nicht, weil sie vermutlich eine ip-tables Regel nichtexistente Schnisttstelle masq anwenden soll. Wenn du ppp0 einträgst erlaubt sie keine Neuanfragen von außen. Nur wenn du einen Webserver auf der Firewall(unprofessionell) oder im internen Netz(halbprofessionell) oder in einer DMZ( prof. Lösung) laufen hast solltest du schon Neuanfragen zulassen wen du von außen darauf zugreifen willst. Übersetzt bedeutet dass, auf keinen Fall "masq ppp0" eintragen sondern den Parameter leer lassen.

REJECT_ALL_INCOMING_CONNECTIONS = ""

mfg
gaw
Empty
Newbie
Newbie
Beiträge: 10
Registriert: 9. Jul 2004, 17:30

Beitrag von Empty »

Erst mal danke für die Aufklärung.

Es hat keinesfalls an der Übersetzung gehapert, eher am Grundverständnis.
Auch wenn es noch so unprofessionell sein mag, würde ich gern den Webserver auf der Firewall laufen lassen.

Wie ich mittlerweile erfahren habe muss es schon
REJECT_ALL_INCOMING_CONNECTIONS = " ppp0 masq"
heißen, damit das routing funktioniert. Zusätzlich muss wohl port 80 explizit freigegeben werden, damit das ganze funktionieren kann. bloß wo ?
Bei den Firewalleinstellungen im Yast hab ich "http" schon zugelassen. nützt aber nix :(
gaw
Hacker
Hacker
Beiträge: 464
Registriert: 28. Sep 2004, 16:33

Beitrag von gaw »

Du benutzt die SuSEPersonal "Firewall", die nur sehr einfache Dinge beherrscht. Mit dem Eintrag in diese Variable wird das Masquerading der entsprechenden Schnittstelle eingeschaltet. Soweit ich weiß ist eingehender Verkehr von außen überhaupt nicht zu konfigurieren. Ich habe diese "Firewall" nie wirklich benutzt sondern mit iptables selber gearbeitet, damit lässt sich alles viel direkter formulieren.

Da aber nicht jeder mit iptables umgehen kann gibt es Alternativen. Konfigurationen die mehr erlauben als einen einfachen Internetzugang per Masquerading für ein LAN, sollten mit der SuSEFirewall2 arbeitem. Hier lassen sich ankommende Verbindungen besser kontrollieren.

Nun kommt es darauf an, wo dein Apache läuft. Wenn er auf dem gleichen Rechner läuft wie die SuSEFirewall2 muss der Dienst www in die Variable FW_SERVICES_EXT_TCP eingetragen werden.
Ansonsten, wenn der Apache im internen Netz läuft muss in die Variable FW_FORWARD_MASQ der Rechner im Lan eingetragen werden, hier ein Beispiel für einen Webserver der die IP 192.168.1.10 hat und von aussen erreichbar sein soll:
FW_FORWARD_MASQ="$FW_FORWARD_MASQ 0/0,192.168.1.10,tcp,80" Dabei werden die einkommende Pakete welche an die dynamische IP adressiert sind umgeschrieben und ins LAN gesendet. Die rücklaufenden Pakete werden von iptables dass als Backend arbeitet automatisch an die korrekte Adresse zurückgesendet. Wichtig ist dabei das zusätzlich FW_ROUTE="yes" gesetzt wird.
Hier eine Firewallconfigurationsdatei wie sie unter 9.1 aussieht, die meisten Variable sind aber auch unter 9.0 vorhanden.

Code: Alles auswählen


# Externes Interface in der Regel ppp0
# bei isdn ippp0
FW_DEV_EXT="ppp0"

# Internes Interface zum LAN
# zum Beispiel:
FW_DEV_INT="eth0"

# Wer keine DMZ besitzt
# leerlassen
FW_DEV_DMZ=""

# Auf jeden Fall auf yes setzen ist Voraussetzung 
# für Masquerading und DNAT
FW_ROUTE="yes"

# Muss auf jeden Fall eingeschaltet werden wenn
# private Adressen (z.B 192.168.x.x) im LAN 
# verwendet werden und der Rechner dynamisch
# eine IP vom ISP zugewiesen bekommt, also
# einschalten.
FW_MASQUERADE="yes"

# An welcher Schnittstelle sollen ausgehende 
# Pakete maskiert werden? Natürlich an der 
# externen und da steht ppp0. Man hätte hier
# auch ppp0 eintragen können, falls du aber mal auf
# isdn umstellen willst musst du so nur einen 
# Eintrag ändern
FW_MASQ_DEV="$FW_DEV_EXT"

# Welche Netze sollen maskiert werden? Hier wird
# angenommen dass das LAN die 
# Netzadresse 192.168.0.0/24 hat. Hier muss die
# Netzadresse deines LAN stehen
FW_MASQ_NETS="192.168.0.0/24"

# Damit legst du fest, dass nur extra 
# aufgeführten  Machinen aus dem LAN  
# Zugriff auf die Firewall haben. Als Systemadmin
# will man aber meistens von jeder Maschine Zugriff
# haben. Bequemer ist hier no, sicherer yes- 
# alledings müssen dann die Rechner von dem aus 
# der Zugriff erlaubt ist eingetragen werden.
FW_PROTECT_FROM_INTERNAL="no"

# Damit wird festgelegt, dass nur auf  
# die in den 
# Variabeln FW_SERVICES_EXT_TCP, 
# FW_SERVICES_EXT_UDP,
# FW_SERVICES_DMZ_TCP,
# FW_SERVICES_DMZ_TCP,  
# FW_SERVICES_INT_TCP,
# FW_SERVICES_INT_TCP
# aufgeführte Dienste die auf der Firewall
# laufen zugegriffen werden dürfen
FW_AUTOPROTECT_SERVICES="yes"

# Hier werden die Dienste eingetragen die auf dem
# Linuxrechner laufen und von aussen erreichbar 
# sein sollen. Wenn also ein Webserver
# auf der Firewall am Laufen hast (Keine  
# wirklich gute Idee) dann sollte hier http
# und https eingetragen werden
FW_SERVICES_EXT_TCP="http https"

# Wie oben nur mit UDP.
FW_SERVICES_EXT_UDP=""


# Falls der Rechner ein Endpunkt eines 
# VPN-Tunnels ist
FW_SERVICES_EXT_IP=""

# Das gleiche wie für den Zugriff von außen
# nun für Zugriff aus der DMZ
FW_SERVICES_DMZ_TCP=""
FW_SERVICES_DMZ_UDP=""
FW_SERVICES_DMZ_IP=""

# Das gleiche wie oben nur für den Zugriff
# aus dem internen LAN- Ein ssh Zugriff
# Willst du aus dem LAN über ssh auf die
# Firewall zugreifen muss hier.
# FW_SERVICES_INT_TCP="22" stehen.
FW_SERVICES_INT_TCP=""
FW_SERVICES_INT_UDP=""
FW_SERVICES_INT_IP=""

# Warum sollten wir das erlauben?
FW_ALLOW_INCOMING_HIGHPORTS_TCP="no"

#  domain und ntp sind ganz sinnvoll
FW_ALLOW_INCOMING_HIGHPORTS_UDP="domain ntp"

# Für die unten aufgeführten Services
FW_SERVICE_AUTODETECT="yes"

# Die nächsten Services sind auf jes zu setzen,
# wenn einer der Dienste auf der Firewall läuft
FW_SERVICE_DNS="no"
FW_SERVICE_DHCLIENT="no"
FW_SERVICE_DHCPD="no"
FW_SERVICE_SQUID="no"
FW_SERVICE_SAMBA="no"

# In die nächste Variable wird eigentlich nur
# dann etwas eingetragen wenn man über mehrere
# feste offizielle IP Adressen verfügt, zum Beispiel
# für einen Mailserver. Wer nur dynamische 
# Adresssen erhält kann diese Variable leer lassen
FW_FORWARD=""


# Nun konnt eine ganz wichtige Variable für emule, 
# den eigenen webserver oder andere Dienste die
# im LAN stehen und von außen über DNAT oder
# erreichbar sein sollen. Nehmen wir
# an im internen Netz läuft ein Apache auf dem 
# Rechner 192.168.0.10 der von außen erreichbar
# sein soll, ganz gleich von wo die Anfrage kommt.
# Dann sieht die Regel so aus
FW_FORWARD_MASQ="$FW_FORWARD_MASQ 0/0,192.168.0.10,tcp,80" 

# Die nächste Regel erlaubt das eigentlche 
# Portforwarding- Hier erfolgt der Eintrag wenn 
# man einen transparenten Proxy laufen lässt und 
# alle http Anfragen auf den lokalen PORT 3168 
# umlenken will
FW_REDIRECT=""

# Einige LOG-Einstellungen die nicht alles loggen
# aber das wichtigste
FW_LOG_DROP_CRIT="yes"
FW_LOG_DROP_ALL="no"
FW_LOG_ACCEPT_CRIT="yes"
FW_LOG_ACCEPT_ALL="no"

# Die rp-Filter Laufzeitparameter des Kernels 
# werden eingeschaltet. Im Prinzip dass was
# echo "1" > proc/sys/net/ipv4/conf/$if/rp_filter
# macht wobeu $if die einzelne Schnittstelle ist
FW_KERNEL_SECURITY="yes"

# Antispoofingregeln können auch explizit formuliert
# werden sind aber unnötig falls die obige Variable 
# eingeschaltet ist
FW_ANTISPOOF="no"


# Das lässt man besser aus. Warum sollte man
# die Routen behalten wollen, wenn man die
# Firewall per Befehl starten und stoppen kann?
# Naja die SuSE-Leute bezeichnen das selber als
# unsicher, wie recht sie doch haben.
FW_STOP_KEEP_ROUTING_STATE="no"

# Zu Diagnosezwecken ist es besser das zu 
# erlauben  
FW_ALLOW_PING_FW="yes"

# Wer keine DMZ hat muss das nicht einschalten
FW_ALLOW_PING_DMZ="no"

# Aus dem Internet sollen mglichst wenig wissen
# dass sich hinter der dyn. IP-Adresse ein Rechner
# verbirgt
FW_ALLOW_PING_EXT="no"


# Traceroute erlauben? Warum nicht?
FW_ALLOW_FW_TRACEROUTE="yes"

# Das ist eine Gewissensfrage. Wenn der ISP
# Sourcequenching erlaubt kann de Rechner  
# merken dass die Verbindung gedrosselt wird
# Andererseits wird der Rechner für eine Denial of 
# Service Attacke angreifbar. Wenn man als Privat-
# mann also Angst hat, dass böse Buben soviele
# ICMP-pakete schicken, so dass der eigene 
# Webserver ausfällt sollte man das auf no stellen
FW_ALLOW_FW_SOURCEQUENCH="yes"

# Solange kein Samba oder Netbios läuft ist auch 
# kein Broadcast notwendig. Sollte Samba einge-
# schaltet sein, auf der Firewall (auch so eine 
# abstruse Idee) dann muss hier int stehen
FW_ALLOW_FW_BROADCAST="no"

# Ganz wichtig wenn die Variable vorher auf no
# steht sonst laufen die Log-Dateien ziemlich
# schnell über, insbesondere wenn WIN-Clients in 
# der Nähe sind
FW_IGNORE_FW_BROADCAST="no"


# Hat man mehere  externe Schnittstellen oder
# mehrere interne Schnittstellen so kann man
# hier ein Classrouting einschalten, dass heißt alle
# Pakete werden an die Schnittstellen der gleichen
# Klasse weitergeleitet. Hat man mehrere interne
# Schnittstellen so könnte die Rechner die an 
# den anderen Schnittstellen hängen erreichen.
# Es gibt sicher irgendwo irgendwann ein Szenario
# wo derartig Abstruses benötigt wird....aber muss
# dass in ein Firewallscript?
FW_ALLOW_CLASS_ROUTING="no"

# Da fürchtet die SuSE wieder zuviele Fragen, ich 
# auch deswegen lassen wir es leer;)
FW_CUSTOMRULES=""

# Auch so eine Angelegenheit über die 
# sich streiten lässt. Manche sagen es ist besser
# das auf no zu stellen um einen Portscan zu 
# verlangsamen. Es ist die Frage ob man einen
# Angreifer sagen soll, dass eine Firewall aktiv ist.
# Ich frage warum nicht, er kann es mit anderen 
# Mitteln sowieso rausfinden. Das ist halt meine
# Ansicht, andere meinen es ist besser zu droppen
FW_REJECT="yes"

# Das ist nicht schlecht. Wenn jemand seine 
# Up-Loadrate kennt, kann er sein System etwas 
# verbessern indem er einen Wert knapp unter der
# Uploadgrenze einträgt. So wird der Rest für DNS
# ICMP oder TCP-Anfragen reserviert. Dadurch 
# werden die PING-Zeiten wesentlich kürzer und 
# die Flusskontrolle belastet nicht das DSL-Modem 
# wenn der emule wieder auf Hochtouren
# laufen sollte. Man erreicht dadurch insgesamt eine # bessere performance. Wenn der Upload 
# beispielsweise bei 128kbit/s liegen sollte könnte 
# man hier folgendes eintragen
# FW_HTB_TUNE_DEV="ppp0, 125"eingeben.   Da # ich nicht wissen kann wie die Uploadraten des 
# Einzelnen aussehen lassen wir das einmal leer.
FW_HTB_TUNE_DEV=""

# Diese beiden Einstellungen erlauben keine 
# IP6-Pakte und geben eine Meldung heraus um
# lange Timeouts zu vermeiden
FW_IPv6=""
FW_IPv6_REJECT_OUTGOING="yes"

# Einstellungen für VPN-Connections
FW_IPSEC_TRUST="no"

# Hier kann man LOG-Optionen angeben z.B. wie
# Pakete ausgegeben werden, was ausgegeben
# wird und ob wir ein Präfix anhingen um unsere
# Meldungen sofort zu erkennen, beispielsweise:
FW_LOG="--log-level warning --log-tcp-options --log-ip-option --log-prefix SuSE-FW2"


versuch das einfach mal statt mit der Personal Firewall zu arbeiten.

mfG
gaw
Zuletzt geändert von gaw am 8. Dez 2004, 15:45, insgesamt 1-mal geändert.
Empty
Newbie
Newbie
Beiträge: 10
Registriert: 9. Jul 2004, 17:30

Beitrag von Empty »

Wie es aussieht, arbeite ich mit einer Kombination aus beiden (oder so ähnlich[legacy mode?!]) Jedenfalls habe ich mich ziemlich genau an diese Anleitung gehalten:
http://portal.suse.com/sdb/de/2002/07/masq80.html

und zusätzlich in die Konfigurationsdatei der SuSEFirewall2

Code: Alles auswählen

FW_SERVICES_EXT_TCP="http https ssh" 
eingetragen.

mit "www" hab ich es noch nicht probiert, werde ich aber mal tun, sobald ich daheim bin. Hoffe mal dass das die Lösung ist....
gaw
Hacker
Hacker
Beiträge: 464
Registriert: 28. Sep 2004, 16:33

Beitrag von gaw »

Das dürfte keine Rolle spielen ob www oder die Kombination aus http, https. Warum ssh? Willst du von aussen auf die Firewall zugreifen können?

Konfiguriere die SuSEFirewall2 so, wie oben geschildert, mit den Einträgen deiner Netzadressen und Schnittstellen natürlich und lasse die Variable REJECT_ALL_INCOMING_CONNECTIONS = "" einfach weg.
Ansonsten kann ich dir kaum helfen. Ich kann nicht sämtliche Komptabilitätsmodi zu älteren Firewalleinstellungen testen und ich sehe darin auch keinen Sinn. Eine Kombination gegenseitig konkurrierender Firewalls-Frontends mit veralteten Einstellungen auseinanderzupfriemeln und mit try und errror auszutesten kann in eine never ending story münden, da schreib ich schneller ein iptables skript. Du hast die SuSE 9.0. Maßgeblich sind die Kommentare in der Datei /etc/sysconfig/SuSEFirewall2. Die stehen schon in der 8.2 fast genau so wie in der 9.1. Und ich habe sie oben im Skript relativ einfach für deine Belange formuliert. Solltest du da etwas nicht verstehen oder wenn es damit nicht klappt melde dich wieder. Und lass die Personal-Firewall unangetastet oder besser deinstalliert sie einfach.


mfG
gaw
Empty
Newbie
Newbie
Beiträge: 10
Registriert: 9. Jul 2004, 17:30

Beitrag von Empty »

Erledigt. Die Personal Firewall rausgeschmissen unnad die von dir gepostete Konfiguration fast 1:1 übernommen. Trotzdem kein Zugriff von außen auf den Apache :(

Ich meine aber festgestellt zu haben, dass es länger dauert, bis "Die Seite kann nicht angezeigt werden..." erscheint. Kann mich aber auch täuschen.

Spielt es evtl eine Rolle, dass ein Samba-Server drauf läuft?? (ja, unprofessionell, I Know)

Würden Logfiles mehr Aufschluss geben? Wenn ja, welche?

der "shields-up"-check auf grc.com sagt, port 80 hat den Status stealth(leo.org sagt -> verdeckt, heimlich.. ;) ..) Liegts daran, wo stelle ich es ggf um?
gaw
Hacker
Hacker
Beiträge: 464
Registriert: 28. Sep 2004, 16:33

Beitrag von gaw »

Manchmal ist es schwer wenn man nicht am betroffenen Rechner sitzt.
Funktioniert mit der Einstellung denn der Internetzugang?
Kannst du mit telnet den webserver lokal über den Hostnamen ansprechen oder hast du ihn an die externe Adresse gebunden?
user@linux :~>telnet `hostname` 80 <ENTER>
Trying xxx.xxx.xxx.xxx...
Connected to hostname.
Escape character is '^]'
get <ENTER>
Hier folgt der Quellcode in HTML
mfg
gaw
Empty
Newbie
Newbie
Beiträge: 10
Registriert: 9. Jul 2004, 17:30

Beitrag von Empty »

Den Telnet-Befehl muss ich heut nachmittag testen. Der Internetzugang incl. Routing funktioniert.
An den Einstellungen des Webservers hab ich nix verändert. Ich hab langsam den Verdacht, es lieg am Apache und nicht an der Firewall...
Empty
Newbie
Newbie
Beiträge: 10
Registriert: 9. Jul 2004, 17:30

Beitrag von Empty »

Code: Alles auswählen

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<title>Cannot process request!</title>
<link rev="made" href="mailto:%5bno%20address%20given%5d" />
<style type="text/css"><!--/*--><![CDATA[/*><!--*/
    body { color: #000000; background-color: #FFFFFF; }
    a:link { color: #0000CC; }
    p, address {margin-left: 3em;}
    span {font-size: smaller;}
/*]]>*/--></style>
</head>

<body>
<h1>Cannot process request!</h1>
<p>

    The server does not support the action requested by the browser.

</p>
<p>
If you think this is a server error, please contact
the <a href="mailto:%5bno%20address%20given%5d">webmaster</a>.

</p>

<h2>Error 501</h2>
<address>
  <a href="/">paul.burghardt</a><br />

  <span>Thu Dec  9 16:03:31 2004<br />
  Apache/2.0.48 (Linux/SuSE)</span>
</address>
</body>
</html>

Connection closed by foreign host.
gaw
Hacker
Hacker
Beiträge: 464
Registriert: 28. Sep 2004, 16:33

Beitrag von gaw »

Immerhin scheint der Apache zu laufen, siehst du denn diesen Fehler auch, wenn du die URL im Browser eingibst?

mfg
gaw
Empty
Newbie
Newbie
Beiträge: 10
Registriert: 9. Jul 2004, 17:30

Beitrag von Empty »

nein. da kommt dann die standard-internet-explorer-"seite kann nicht angezeigt werden"-Meldung.
gaw
Hacker
Hacker
Beiträge: 464
Registriert: 28. Sep 2004, 16:33

Beitrag von gaw »

Dann wird der Fehler auch nicht verschwinden wenn du die firewall einschaltest.

mfG
gaw
Empty
Newbie
Newbie
Beiträge: 10
Registriert: 9. Jul 2004, 17:30

Beitrag von Empty »

Es funktioniert endlich.
Hab ja deine Konfig fast komplett so übernommen und dabei übersehn dass der 80er port ins lan gemappt ist.
Ausschlaggebend war aber auf jeden Fall dass ich die personal-firewall und damit das "REJECT_ALL_INCOMING_CONNECIONS" entfernt hab.

Danke nochmal für deine Hilfe.
Antworten