Apache nur auf 127.0.0.1:80 antworten lassen

[Uschi Renziehausen]

Liebe Freunde,

ist es möglich, einen Apachen dazu zu bringen, daß er generell nur Anforderungen, die vom eigenen Rechner kommen, annimmt, ohne daß diese Einschränkung in den Virtual Hosts wieder aufgehoben werden kann? Für ein "Ja" oder "Nein" wäre ich schon mal dankbar, aber ich würde in die Luft springen, wenn mir jemand verrät, wie das geht.

Liebe Grüße von einer Indianer-müden Uschi

[Bio]

Sup!

ist es möglich, einen Apachen dazu zu bringen, daß er generell nur Anforderungen, die vom eigenen Rechner kommen, annimmt, ohne daß diese Einschränkung in den Virtual Hosts wieder aufgehoben werden kann? Für ein "Ja" oder "Nein" wäre ich schon mal dankbar, aber ich würde in die Luft springen, wenn mir jemand verrät, wie das geht.

Diese deny/allow Sache ist IMHO in den virtual hosts festzulegen, und ich denke, es "overridet" auch irgendeine "default" einstellung.

http://httpd.apache.org/docs/sections.html (unten)

Vielleicht solltest Du niemanden an den Server lassen und eine Firewall den Port 80 von aussen blocken lassen - oder den Server auf einen anderen Port binden, und den von aussen blocken, oder den portmapper nicht starten.

Gruesse,

Bio

[Maja]

ist es möglich, einen Apachen dazu zu bringen, daß er generell nur Anforderungen, die vom eigenen Rechner kommen, annimmt, ohne daß diese Einschränkung in den Virtual Hosts wieder aufgehoben werden kann? Für ein "Ja" oder "Nein" wäre ich schon mal dankbar, aber ich würde in die Luft springen, wenn mir jemand verrät, wie das geht.

Ich weiß nicht für was du das brauchst. Ich hatte folgendes Problem: Zu Testzwecken läuft auf meinem Rechner ein Apache, der aber keine externen Anfragen bearbeiten soll. Ich habe das - auch aus anderen Gründen - mit einem Personal Firewall gelöst (z.B. Tiny oder Zone Alarm(für Windows)). Dieser blockt einfach alle externen Anfragen auf Port 80.

Gruß Maja

[Christoph Schnauß]

liebe Uschi,
(huch, so eine Anrede hab ich noch nie gebraucht, aber deine Anrede hat ansteckend gewirkt)

in der Apache-Dokumentation kann man nachlesen: "Unless a NameVirtualHost directive is used for a specific IP address the first vhost with that address is treated as an IP-based vhost. In 1.3.13 and later that includes the IP address *."
siehe http://httpd.apache.org/docs/vhosts/details.html

Das heißt, auf deine Frage gibts weder ein "ja" noch ein "nein", sondern es gibt ein
if (erster vhost mit anderer IP-Adresse){
wahrscheinlich nein
}
else if {IP-basierte vhost-Liste) {
ja
}
else if (was andres in die httpd.conf geschrieben {
...
}
else {
kein vhost definiert
}

zusätzlich kann man mit den "bind"- und "listen"-Angaben experimentieren, und wenn das nicht genügt, kannst dir ein eigenes Modul zusammenzuschrauben versuchen, das das kann. Da weiß ich aber nur, _daß_ es geht, und zur Zeit noch nicht genau, _wie_ es geht. Vielleicht weiß es Michael Schröpl besser.

Grüße aus Berlin

Christoph S.

[Michael Schröpl]

Hi Christoph,

in der Apache-Dokumentation kann man nachlesen: "Unless a NameVirtualHost directive is used for a specific IP address the first vhost with that address is treated as an IP-based vhost. In 1.3.13 and later that includes the IP address *."
siehe http://httpd.apache.org/docs/vhosts/details.html

die IP-Adressen-Definitionen für die VirtualHosts, die Du hier beschreibst,
beziehen sich meiner Meinung nach auf die IP-Adresse des Servers selbst -
nicht auf die IP-Adresse des Client, den Uschi zugriffsreglementieren will.

Der Server kann beispielsweise mehrere Netzwerkkarten haben (und an mehreren
Netzen angesprochen sein), wobei bestimmte Virtual Hosts nur über bestimmte
Karten ansprechbar sind. Stell Dir einen Server vor, der sowohl den Internet-
als auch den Intranet-Auftritt einer Firma enthält - auf diese Weise könnte
man die Zugriffe über die jeweiligen Netzwerkzugänge reglementieren.

Wir haben auch mal eine Apache-Konfiguration gemacht, bei der zwei verschiedene
Server mit zwei verschiedenen IP-Adressen zwei semantisch gleiche, aber zusätz-
lich _auch_ über verschiedene DNS-Namen ansprechbare Virtual Hosts beliefern.
Maschine 1 kennt also die Virtual Hosts X und X1, Maschine 2 heißt X und X2.
Allerdings wollten wir nicht die beiden weitgehende identischen Konfigurationen
zweimal definieren (und pflegen!) müssen - wir wollten sie nur auf einer Maschine
pflegen und automatisch auf die andere kopieren können.
Also haben wir den Virtual Host X ohne Referenz auf eine IP-Adresse definiert,
die beiden Virtual Hosts X1 und X2 dagegen mit einer solchen Referenz.
Jede der beiden Maschinen wird dabei die Definition für die jeweils andere Ma-
schine ignorieren, weil nie ein Zugriff mit der passenden IP-Adresse kommen wird.
Anfragen an den Virtual Host X würde aber jede der beiden Maschinen beantworten.
Der Zugriff auf die beiden X-Server wird dabei von einem Proxy-Server gesteuert,
der beide Server überwacht und seine DNS-Konfiguration on the fly umstellt - eine
Hot-Standby-Ausfallsicherung des Webservers also.

zusätzlich kann man mit den "bind"- und "listen"-Angaben experimentieren,

Auch "bind" und "listen" beschreiben das Verhalten des Servers gegenüber
ankommenden Anforderungen _auf_ bestimmte IP-Adressen (bzw. Port-Nummern),
dürften Uschi m. E. in ihrem Kontext nicht helfen.

Viele Grüße
      Michael

[Henryk Plötz]

Moin

Auch "bind" und "listen" beschreiben das Verhalten des Servers gegenüber
ankommenden Anforderungen _auf_ bestimmte IP-Adressen (bzw. Port-Nummern),
dürften Uschi m. E. in ihrem Kontext nicht helfen.

Nachdem hier anscheinend noch fast niemand in die Doku geschaut hat, hab ich das einfach mal getan und bin zu dem Schluss gekommen, dass BindAddress so ziemlich das einzige ist, was Uschi zuverlässig helfen wird:

"Only one BindAddress directive can be used. For more control over which address and ports Apache listens to, use the Listen directive instead of BindAddress. BindAddress can be used as an alternative method for supporting virtual hosts using multiple independent servers, instead of using <VirtualHost> sections." http://httpd.apache.org/docs/mod/core.html#bindaddress

Ich interpretiere das so: 1. BindAddress kann nur einmal verwendet, also komme was wolle nicht überschrieben werden. 2. Mit BindAddress kann man virtuelle Hosts emulieren, in dem man mehrere httpd-Prozesse mit unterschiedlichen Konfigurationen startet -> VirtualHost-Einstellungen innerhalb eines Servers der mit BindAddress nur auf 127.0.0.1 lauscht führen nicht dazu, dass der Server plötzlich auch noch auf andere IP-Addressen reagiert.

Michael: Zu deinem Einwand, dass du deinen lokalen Rechner nicht erreichen kannst: Das hängt einzig und allein von der Namensauflösung ab. Viele Rechner haben im Intranet einen Namen und diesem Namen wird sinnvollerweise die IP-Addresse des Ethernetinterfaces zugeordnet. Wenn du also http://deinrechnername aufrufst, baut der Browser eine Verbindung zu 192.168.0.1 (oder was auch immer du als IP-Addresse auf deinem Ethernetinterface hast) auf. Das kann er natürlich nur über das Ethernet-Interface tun (zumindest wenn da nicht noch irgendwas durch die Gegend geroutet wird) und kann daher nur als Absenderaddresse 192.168.0.1 verwenden.
Wenn du http://localhost aufrufst sollte er zu 127.0.0.1 verbinden (zumindest wenn deine Namensauflösung nicht _sehr_ merwürdig konfiguriert ist) und aus dem selben Grund müsste die Absenderaddresse dann auch 127.0.0.1 sein.
Aus einem ähnlichen Grund habe ich bei mir in der /etc/hosts einen Eintrag der
127.0.0.1 localhost fuzzy.homeip.net
lautet und somit meinem dyndns-Namen die IP-Addresse des loopback-interface zuordnet, damit das auch funktioniert wenn grade keine Internetverbindung besteht oder das Ethernetinterface (dem der Name sonst zugeordnet würde) nicht aktiviert ist.

--
Henryk Plötz
Grüße aus Berlin

[Christoph Schnauß]

ups,

Nachdem hier anscheinend noch fast niemand in die Doku geschaut hat

also hast du dich vom "Anschein" leicht verführen lassen. Sowohl Michael wie auch ich haben (vielleicht nicht unbedingt in diesem Thread, aber insgesamt  -  was dir gut bekannt ist) deutlich gemacht, daß für spezielle Nachfragen die Apache-Dokumentation immer nachgelesen werden sollte.

bin zu dem Schluss gekommen, dass BindAddress so ziemlich das einzige ist, was Uschi zuverlässig helfen wird:

ich hab bereits gesagt, daß mit "bind" zu experimentieren wäre. Auch Michael schließt das wahrhaftig nicht aus. Das "einzige" Feature muß das deswegen nicht sein. Wenns klappt, ist es gut, wenn nicht ...

"Only one BindAddress directive can be used. For more control over which address and ports Apache listens to, use the Listen directive instead of BindAddress. BindAddress can be used as an alternative method for supporting virtual hosts using multiple independent servers, instead of using <VirtualHost> sections." http://httpd.apache.org/docs/mod/core.html#bindaddress

Es geht bei "bind address" eben um die "multiple independent servers". Aber genau darum geht es in Uschis Ausgangsposting  -  wenn ich es richtig gelesen habe  -  nicht (ich kann mich irren).

Ich interpretiere das so: 1. BindAddress kann nur einmal verwendet, also komme was wolle nicht überschrieben werden.

Doch. Kann überschrieben werden. Das einzige, was nicht funktioniert, ist die gleichzeitige Verwendung von "bindaddress" und "listen" für dieselbe IP-Adresse eines Servers, auf dem  _diese_ Apache-Instanz grade laufen soll.

2. Mit BindAddress kann man virtuelle Hosts emulieren

problematische Aussage. Möglicherweise verstehen wir beide hier unter "emulieren" im technischen Sinn nicht ganz genau dasselbe.

VirtualHost-Einstellungen innerhalb eines Servers der mit BindAddress nur auf 127.0.0.1 lauscht führen nicht dazu, dass der Server plötzlich auch noch auf andere IP-Addressen reagiert.

richtig, dafür gibt es keinen "automatischen" Grund. Aber im strengen Wortsinn  -  auf den es hier wohl auch ankommt  -  "lauscht" der Server in diesem Fall eben nicht die 127.0.0.1 (eigentlich sogar 127.0.0) ab, sondern ist mit ihr verbunden. Das macht einen Unterschied. Wenn es diese Bindung gibt, kann er nicht auf andere IP-Adressen reagieren (mit viel Aufwand läßt sich aber sogar das aufbrechen). Wenn er nur "lauschen" soll, kann er sehr wohl auf andere Adressen reagieren. Zu konfigurieren ist halt, wie er das tun soll / kann.

Michael: Zu deinem Einwand, dass du deinen lokalen Rechner nicht erreichen kannst: Das hängt einzig und allein von der Namensauflösung ab.

Der Apache ist halt nicht per default auch ein DNS.

Viele Rechner haben im Intranet einen Namen und diesem Namen wird sinnvollerweise die IP-Addresse des Ethernetinterfaces zugeordnet.

Ich habe diese Namenszuuordnung bisher immer für zwingend nötig gehalten, so daß man sagen müßte: "_alle_ Rechner im Intranet haben einen Namen". Du kannst mich gern eins Besseren belehren.

Wenn du also http://deinrechnername aufrufst

von welchem Rechner im Intranet aus ??? Bereits hier ist es eminent wichtig, zu unterscheiden, ob der Aufruf vom Server-Rechner aus oder von einem Client aus erfolgt und ob es einen "richtigen" DNS gibt.

Wenn du http://localhost aufrufst sollte er zu 127.0.0.1 verbinden (zumindest wenn deine Namensauflösung nicht _sehr_ merwürdig konfiguriert ist) und aus dem selben Grund müsste die Absenderaddresse dann auch 127.0.0.1 sein.
Aus einem ähnlichen Grund habe ich bei mir in der /etc/hosts einen Eintrag der
127.0.0.1 localhost fuzzy.homeip.net

vergiß nicht, daß Uschi keine Aussage über ihr Betriebssystem gemacht hat. Eventuell gibts bei ihr gar kein /etc/hosts. Außerdem: nimm mal an, du hast nur zwei Rechner per Ethernetkarte und -kabel verbunden und damit ein kleines LAN hergestellt. Auf Recher1 hast du den Apache, auf Rechner2 nicht  -  Was zeigt dir dann Rechner2 beim Aufruf von 127.0.0.1 ?

Aber im Ausgangsposting von Uschi gibts nun noch die dubiose Formulierung "daß er generell nur Anforderungen, die vom eigenen Rechner kommen, annimmt"  -  nun ja, dieser "eigene Rechner" kann ja entweder Server mit Apache-Installation oder Client mit ohne Apache-Installation sein ( nein, _mit ohne_ ist hier kein Verschreiber). Da müßte Uschi uns schon bissel helfen und die gewünschten Bedingungen etwas spezifizieren.

winkewinke innerhalb Berlins

Christoph S.

[Carsten]

Hallo Uschi!

Wenn ich dich richtig verstanden und die Doku richtig gelesen habe ist

Listen 127.0.0.1:80

die richtige Beschwörung.... wenn nicht, geht es nicht.

Allerdings stehen die <VirtualHost> Einträge ja in der gleichen Datei wie das 'Listen', wer das eine ändern darf, kann auch das andere ändern.
(Evtl. mit include ... aber da sollte man wen fragen der sich auskennt ... oder mal probieren...)

Gruss,
 Carsten

[Calocybe]

Hi!

Gibt ja ganz schoen viele Meinungen hier. Dabei sollte man doch denken, die Leute hier wissen Bescheid?

Wenn ich dich richtig verstanden und die Doku richtig gelesen habe ist
Listen 127.0.0.1:80

Yoh, entweder das, oder
  BindAdress 127.0.0.1
  Port 80
.

Beide Varianten koennen aber durch weitere Listen-Direktiven ergaenzt werden. Zwar nicht *innerhalb* eines <VirtualHost>, aber in der Zeile direkt davor durchaus - und das zaehlt dann fuer die gesamte Serverconfig.

(Evtl. mit include ... aber da sollte man wen fragen der sich auskennt ... oder mal probieren...)

Include macht das, was man davon erwartet, ganz straight-forward. Alles was in einer Include-Datei steht, wird behandelt, wie wenn es in der httpd.conf direkt steht, auch Listen-Direktiven.

So long

[Carsten]

Hallo Calocybe!

Gibt ja ganz schoen viele Meinungen hier. Dabei sollte man doch denken, die Leute hier wissen Bescheid?

Naja...wohl eher jeder soviel wie er für 'seinen' Apache grad braucht.

Include macht das, was man davon erwartet, ganz straight-forward. Alles was in einer Include-Datei steht, wird behandelt, wie wenn es in der httpd.conf direkt steht, auch Listen-Direktiven.

Dann wäre folgendes möglich:

<VirtualHost ...>
Include /etc/httpd/vhost/hostX.conf
</virtualHost>

und es gäbe (in der hostX.conf) keine Möglichkeit mehr doch noch 'Listen' Direktiven einzuschleusen.
Nur leider steht bei Include "Context: server conf" und nix von "virtual host" und die Context-Doku ist da recht deutlich das "server conf" "<virtual host>" Bereiche ausschliesst. Aber vielleicht geht sowas ja doch irgendwie, womit wir wieder bei den Leuten wären die sich damit auskennen ;-)

Gruss,
 Carsten

[Michael Schröpl]

Hallo Uschi,

ist es möglich, einen Apachen dazu zu bringen, daß er generell
nur Anforderungen, die vom eigenen Rechner kommen, annimmt,

hierzu erst einmal ein "ja":

<Directory />
 order deny,allow
 deny  from all
 allow from [Adresse Deines Rechners]
</Directory>

Zumindest in meinem Netzwerk zählt hierbei die IP-Adresse der Netzwerk-
karte des Rechners, 127.0.0.1 funktioniert bei mir als Client gar nicht.
Bei einem standalone-PC mag das anders sein.

(Ich habe eine Anwendung, wo ich genau das auch brauche: ein Apache-Handler
saugt mit Hilfe von LWP::Simple Dokumente ab und schreibt deren Inhalt on
the fly um - normale Benutzer dürfen aber nicht auf das Original zugreifen
können.)

ohne daß diese Einschränkung in den Virtual Hosts wieder
aufgehoben werden kann?

Wer schreibt denn die Konfigurationen Deiner Virtual Hosts, daß Du dem so
mißtraust? ;-)

Ich habe mal innerhalb eines Virtual Host ein "allow from all" angegeben,
das aber von dem übergeordneten "deny" overruled wurde.

Ich kann Dir aber nicht verbindlich sagen, ob in diesem Fall der Server
den Virtual Host overruled hat oder (wahrscheinlicher) die Prüfungen im
Wurzelverzeichnis beginnen und sich dann immer näher an den vollständigen
Pfad der Zieldatei heran tasten.

Deshalb würde ich im Server das Verbot für "/" aussprechen - egal, wie
Dein DocumentRoot definiert ist. Mehr sperren schadet nie - zumal über
Alias und ScriptAlias ja durchaus Pfade außerhalb des DocumentRoot in
Deinem URL-Baum (insbesondere in einem der Virtual Hosts!) liegen könnte.

Viele Grüße
      Michael
(der Virtual Hosts mangels Übung mit ganz spitzen Fingern anfaßt)

[Uschi Renziehausen]

Hallo an alle, die sich mit meinem Problem rumschlagen

ich hätte bei meinem Ausgangsposting vielleicht doch den Hintergrund meiner Anfrage erläutern sollen, kann ja nie schaden:

Also: das Problem mit der Apache-Config taucht bei mir in folgenden Kontexten auf:

a) Wir haben in der Uni einen Computerpool, in dem Mitarbeiter und Studis, die nix, aber auch gar nix mit Programmierung etc zu tun haben, unter anderem folgendes tun können sollen:

• an html-Kursen teilnehmen, zu denen, wenn die Leute das Gelernte
    am heimischen Rechner nachvollziehen sollen, auch das Thema gehört: wie richte ich mir am heimischen Herd einen Apache und Virtual Hosts ein. Wohlgemerkt: Die sollen dabei nicht lernen, wie man einen Apache rauf und runter konfiguriert, sondern nur, wie sie das wichtigste zum Laufen bringen. Das läßt sich mit Ausnahme der virtual hosts sicher so realisieren, dass man eine für Uschis und Konsorten erklärte httpd.conf bastelt, die sich die Leute anpassen können. Virtual Hosts sollten die Leute allerdings selbst anlegen können, damit sie raffen, wie das funktioniert und wie man mit der etc/hosts umgeht.

• ausserhalb von Kursen Webseiten basteln. Auch in diesen Fällen ist es Mist, wenn kein Apache rennt. Im Dreamweaver kann man zum Beispiel mit spielerischer Leichtigkeit ssi's basteln, aber die kann sich Userlein natürlich nur begucken, wenn ein Webserver läuft.

b)Auch die Mitarbeiter brauchen einen Testwebserver, den sie am Arbeitsplatz im Büro nutzen können.

Die Uni hat ein Novell-Netzwerk, die Clients rennen entweder unter NT oder Windows 2000. Jeder User kriegt von Novell ein Home-Directory gemappt.

Für b wäre mein Traum wäre ein Spielwebserver für alle User auf Linux-Basis auf dem ein Apache, PHP, MySql, Perl und was sonst noch so alles vorkommt, installiert ist, wobei der Zugriff auf die Uni-User begrenzt ist, der Indianer also allen nicht zu uns gehörenden IPs eine klare Absage erteilt. Wohlgemerkt: das Ganze ist ein Traum, wir haben so etwas nicht, das Rechenzentrum ächzt unter einem gravierenden Personalmangel, es gibt also niemanden, der uns das aufsetzt.

Damit die Leute die vhosts nach eigenen Bedürfnissen einrichten können, müsste sich jeder in seinem Home-Laufwerk, das für alle User gleich heißt, eine Datei namens vhosts.conf packen, die dann in die httpd.conf des Apache included wird. Nur muss eben verhindert werden, dass die für diesen Fall ausserordentlich rigiden Sicherheitsbestimmungen über die vhosts ausgehebelt werden können.

Irgendwie müßte so eine generelle Lösung her, aber da das bis zur Realisierung bei unserem Höllentempo Jahre dauern kann, habe ich mir for immediate needs überlegt, dass ein Apache auf den Einzelplatzrechnern rennen soll, der nach demselben Prinzip funktioniert. Nur: sicher muss es eben sein.
Ein Problem dabei ist sicher die etc/hosts, davon gibt es halt nur eine *schnueff*.

Und jetzt werde ich die gesamte Diskussion hier nochmal in aller Gemütsruhe durchgehen und versuchen, ein bisschen mehr über den Apachen zu lernen.

Liebe Grüße und vielen Dank, wenigstens weiss ich jetzt, wo ich mit dem Studium anzufangen habe,

Uschi