IPAM System – From Zero to phpIPAM mit Raspi

Setzt Ihr in Zeiten von Netzwerk Mikro- und Makrosegementierung noch immer auf hilflos zusammengeschriebene Word Dokumente oder Excel Listen oder gar Text Dateien, vollgestopft mit irgendwelchen IP Listen, die 10 Sekunden nach dem Abspeichern bereits wieder veraltet sind oder erst gar nicht gepflegt werden? Seien wir ehrlich, das ist traurig und zudem unprofessionell. Gibt es doch mittlerweile ausreichend Möglichkeiten das zu verbessern! Manchmal werden bereits kommerzielle Software Produkte eingesetzt, mit teilweise erschreckend geringem Funktionsumfang, aber wenigstens das. Es gibt aber eine Open Source Lösung namens phpIPAM, die durchaus ein umfangreiches Toolset für die Netzwerk- und Netzwerk-Geräteverwaltung mitbringt und recht smart über ein Web Frontend bedient werden kann. Warum dieses System nicht einfach auf einem Raspberry Pi (kurz genannt „Raspi“) bereitstellen, der dann mit seinem minimalen Footprint ins Rack gelegt und an einen Switch angeschlossen werden kann. So ist das System unabhängig von einer virtuellen Umgebung. Geringe Kosten, großer Mehrwert! Deshalb entstand dieser Guide, der für Integratoren und Administratoren, die (evtl. noch) nicht ganz so fit im Bereich Unix und Raspi Hardware sind, eine Step by Step Anleitung für die Integration von phpIPAM, auf einem Raspi sein soll. Selbstverständlich kann dieser Guide auch für eine Installation auf einem (virtuellen) Debian Server angewendet werden, denn das verwendete Raspi OS ist praktisch nichts anderes. Ich habe für die Umsetzung bis zum laufenden System übrigens ca. 4h benötigt, das Schreiben dieses Guide hat wesentlich länger gedauert! Das aber nur als „grobe“ Orientierung für alle, die deshalb ein wochenlang dauerndes Projekt erwarten. Sollte jemandem ein technischer Fehler auffallen oder generell etwas fehlen oder ich einen Schritt vergessen oder falsch dokumentiert haben, gerne unten kommentieren. Rechtschreibfehler hingegen verleihen diesem Guide seinen unverwechselbaren Charakter und decken zudem Copy & Paste Plagiate zuverlässig auf! 😀

Ok, dann mal los…

Hard- und Software

Ich hatte noch einen Raspberry Pi 3B+ mit einem Standard Gehäuse, einem Netzteil und einer MicroSD aus einem anderen Projekt „herumliegen“. Denkt bitte daran, sollte Euer System keinen MicroSD Card Reader besitzen, werdet Ihr einen entsprechenden Adapter (bspw. einen USB MicroSD Card Reader) benötigen. Meiner war bspw. beim Raspi Paket dabei. Ich spare mir aus perönlichen Gründen auch die üblichen „Hier kannst Du das alles kaufen“ Links, denn ich bin sicher Ihr findet selbst, was Ihr dafür braucht. 🙂 Natürlich geht für dieses Projekt auch ein Raspberry PI 4 oder 5, so wird das „System“ sogar noch etwas leistungsfähiger. Es muss dann lediglich (abweichend von meinen Infos) das passende Raspi OS installiert werden. Das sollte auch keinen oder nur einen geringen Impact auf den eigentlichen Installationsprozess von phpIPAM haben.

Infos zu den Hard- und Softwarekomponenten:

  • Hardware: Raspberry Pi 3B+
  • Speicher: SanDisk Ultra Micro SD Karte 16GB
  • Netzwerk: LAN Verbindung / DHCP Adresse reserviert
  • Betriebssystem: Raspi OS Legacy Lite (64 Bit) -> basierend auf Debian „Bullseye“ (Release date: December 5th 2023) <- Lite verwenden, weil schlank und eine GUI brauchen wir nicht! Übrigens basieren alle nativen Raspberry PI Betriebssysteme (Rsspi OS) auf einer Debian Distribution.
  • Apache Version 2.4.56
  • PHP version 7.4.33
  • MySQL version   10.5.21-MariaDB-0+deb11u1
  • phpIPAM Software Release: 1.7.0 (GIT Release Stand 06.01.2024)

Nochmal der Hinweis:

Die Raspi Hardware hat sicher ihre Vorteile, ABER bei großen und komplexen Netzen könnte das System an seine Grenzen stoßen. Dann kann man bspw. auf eine leistungsfähige VM oder gar Hardware (hier bspw. basierend auf einem Debian 11) setzen. Sämtliche Konfigurationen und Informationen aus einer vorhandenen phpIPAM Instanz können übrigens auch jederzeit auf ein anderes phpIPAM System migriert werden! Somit kann das System durchaus „mitwachsen“…

Vorbereitungen Raspi

Ich habe für das Imagen der MicroSD Card den nativen Raspberry Pi Imager und das Raspberry Pi OS Legacy Lite (64 Bit) verwendet und beim Imagen der MicroSD Card gleich den SSH Zugriff aktiviert (incl. SSH Passwort Authentifizierung), damit ich zur Erstinbetriebnahme nicht noch einen Monitor und eine Tastatur anstecken muss. Selbstredend sollte dieser Zugriff nach der Integration auf eine zertifikatsbasierte Anmeldung umgestellt werden. Das kann (und MUSS) aber auch danach noch erfolgen.

  • Navigieren Sie zu Erweiterte Optionen im Raspberry Pi Imager.
  • Klicken Sie auf das Kontrollkästchen neben SSH aktivieren.
  • Legen Sie einen Benutzernamen und ein Passwort fest.*
Raspi Imager 1
  • Ich konnte so nach der Installation direkt via SSH auf die vom DHCP Server vergebene IP zugreifen, was für diesen Guide völlig ausreichend ist.
  • Übrigens habe ich WLAN deaktiviert belassen, da ich für dieses Projekt einen kabelgebundenen LAN Anschluss bevorzuge und auch immer empfehlen würde.
  • Der Raspi erhielt in meinem Fall den Hostnamen IPAM-RASPI. Den solltet Ihr freilich an Eure Wüsche anpassen. Übrigens kann er später immer einen anderen A-Record oder CNAME bekommen, unter dem Ihr dieses System dann im Browser aufrufen könnt. Aber das später…

Vorbereitungen Netzwerk

  • Netzwerkseitig habe ich das IPAM System in einem passenden Management LAN Segment positioniert.
  • Um die Discovery- und Keep Alive Scan Funktionen zu nutzen, habe ich diesem System zusätzlich ICMP PING Requests in ALLE Netzwerk Segmente erlaubt. (Achtung, lokale Firewalls blocken ggfs. PING Requests! Hier sollte das IPAM System eine Ausnahme bekommen.)
  • Damit die Forward- und Reverse DNS Auflösung funktioniert (das System findet so nämlich auch den Hostnamen der gefundenen IP Adressen heraus), lasse ich auch UDP Port 53 (also DNS) auf die internen DNS Server unseres LABs zu. Wer diese DNS Zugriffe vermeiden möchte, kann auch mit seinen DNS-Forwardern arbeiten, die dann als DNS Server am System hinterlegt werden. Dann muss natürlich der DNS Zugriff auf die Forwarder erlaubt werden.
  • Der Einfachheit halber habe ich zunächst vollen ausgehenden Zugriff auf das Internet zugelassen, damit die Installation sämtlicher Software Pakete von den Debian Quellen und natürlich vom phpIPAM GIT Repository problemlos vonstatten gehen kann. Da es sich nur um einige, wenige URLs handelt, könnte man bereits hier auch einschränken. Grundsätzlich reicht für diesen Guide immer HTTP (Port 80) und HTTPS (Port 443), im Zweifel noch DNS (UDP 53) und NTP (TCP 123) nach extern.
  • Wichtiger Hinweis: Sollte das System hinter einem Proxy oder einer Firewall mit SSL-Interception positioniert werden, muss zuerst das Zertifikat dieses Systems importiert werden. Hier kann man sich an Standard Anleitungen für den Import von CA Zertifikaten an einem Debian Server orientieren. Ein guter Artikel wäre bspw. dieser hier.
  • Am Ende nicht vergessen, wenn Ihr (wie ich) mit einer dynamischen IP arbeitet:
    • die Reservierung der IP am DHCP Server vorzunehmen und
    • falls das nicht bereits via DHCP automatisch passiert, auch den entsprechenden DNS Host Record zu setzen… 😉

Konfiguration des Raspberry Pi OS (hier Debian 11 – Codename „Bullseye“)

Davon ausgehend, dass die Installation und die Verbindung zum Raspi, via SSH erfolgreich waren, setzen wir wie folgt fort:

OS Version Prüfen

Prüfe die aktuelle OS Version mit:

cat /etc/debian_version

Ausgabe…

11.8

oder mit:

cat /etc/os-release

Ausgabe…

PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

Zeitsynchronisation mit NTP Service einrichten

Richten wir nun die korrekte Zeitsynchronisation mit dem NTP Service ein…

Zunächst installiert man den NTP Zeitservice mit:

sudo apt-get install ntp -y

und aktivieren den automatischen Start des NTP Service nach dem Systemstart mit:

sudo systemctl enable --now ntp

Erwartete Ausgabe:

Synchronizing state of ntp.service with SysV service script with /lib/systemd/systemd-sysv-install.

Executing: /lib/systemd/systemd-sysv-install enable ntp

Jetzt stoppen und deaktivieren wir den „systemd timesync“ Service mit:

sudo systemctl stop systemd-timesyncd
sudo systemctl disable systemd-timesyncd

Jetzt starten wir sicherheitshalber den NTP Service einmal neu mit:

sudo systemctl restart ntp

Jetzt legen wir in der Config Datei die Zeitquelle für unseren Raspi fest.

Ich habe exemplarisch den de.pool.ntp.org festgelegt. Ihr könnt hier natürlich auch Euren eigenen oder einen anderen Zeitserver hinterlegen.

sudo nano /etc/ntp.conf

Entscheidende Stelle in der Datei ist hier die Zeile 7. (In der Original Datei weicht diese Zeilennummer ab!)

# You do need to talk to an NTP server or two (or three).
#server ntp.your-provider.example

# pool.ntp.org maps to about 1000 low-stratum NTP servers.  Your server will
# pick a different set every time it starts up.  Please consider joining the
# pool: <http://www.pool.ntp.org/join.html>
pool de.pool.ntp.org iburst

Neustart des NTP Service, wieder mit:

sudo systemctl restart ntp

Prüfen, ob die Zeitsynchronisation funktioniert:

sudo ntpq -pn

Die erwartete Ausgabe könnte in etwa so aussehen:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 de.pool.ntp.org .POOL.          16 p    -   64    0    0.000   +0.000   0.000
-116.202.14.29   124.216.164.14   2 u  145 1024  377    6.966   +0.516   0.133
+78.47.56.71     17.253.14.253    2 u  390 1024  377    5.276   -0.231   0.108
*85.220.190.246  213.172.96.14    2 u  901 1024  377    8.191   -0.143   0.123
-185.252.140.125 216.239.35.4     2 u  469 1024  377    7.493   +0.427   0.131
-89.58.43.2      74.187.231.27    3 u  759 1024  377   11.134   -3.403   0.053
-144.76.59.106   192.53.103.104   2 u  443 1024  377    7.578   +0.358   0.208
-3.121.254.221   237.17.204.95    2 u  323 1024  377   14.999   -7.028 139.276
-185.244.195.159 205.46.178.169   2 u  876 1024  377   12.038   +0.573   0.127
+78.47.250.33    213.239.239.164  3 u  726 1024  377    7.515   -0.263   0.196

und der klassichen Abfrage der aktuellen Zeit mit:

date

Hier sollte das korrekte Datum und auch die korrekte Zeit angezeigt werden, also sowas wie:

Fri  5 Jan 14:34:45 CET 2024

Nützliche Netzwerk Utilities installieren

Ich installiere, nur zu Diagnosezwecken noch nslookup und und traceroute, denn die anderen Utilities wie PING, IFCONFIG etc. sind bereits im OS enthalten, aber diese Pakete fehlen mir immer. Die Installation einfach mit:

sudo apt install inetutils-traceroute inetutils-ping net-tools dnsutils -y

durchführen und vllt. mal einen ping, traceorute, nslookup oder auch dig testen.

Software-Voraussetzungen für phpIPAM installieren

Um phpIPAM installieren zu können, benötigt man:

  • VIM, für die Leute, die diesen CLI Editor bevorzugen. Wer eh lieber mit Nano arbeitet (wie ich bspw.), muss nichts tun, der ist standardmäßig dabei.
  • einen Webserver (ich setze auf Apache2)
  • PHP und diverse Module als Laufzeitinterpreter und
  • MariaDB als Datenbank-Server und -Client

Klingt kompliziert, ist aber in der Realität nur ein eine Zeile, wenn man sie kennt… 😉

Installation aller erforderlichen Pakete

Wir installieren also alle o.g. Voraussetzungen gleichzeitig mit:

sudo apt install -y vim apache2 php php-cli libapache2-mod-php php-curl php-mysql php-curl php-gd php-intl php-pear php-imap php-apcu php-pspell php-tidy php-xmlrpc php-mbstring php-gmp php-json php-xml php-ldap php-common php-snmp php-fpm mariadb-server mariadb-client git

FPM-Service checken

Anschließend prüfen wir gleich den PHP FPM-Service mit:

systemctl status php*-fpm.service

Erwartete Ausgabe:

● php7.4-fpm.service - The PHP 7.4 FastCGI Process Manager
     Loaded: loaded (/lib/systemd/system/php7.4-fpm.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2024-01-06 11:10:57 CET; 1 day 3h ago
       Docs: man:php-fpm7.4(8)
   Main PID: 33591 (php-fpm7.4)
     Status: "Processes active: 0, idle: 2, Requests: 0, slow: 0, Traffic: 0req/sec"
      Tasks: 3 (limit: 779)
        CPU: 15.729s
     CGroup: /system.slice/php7.4-fpm.service
             ├─33591 php-fpm: master process (/etc/php/7.4/fpm/php-fpm.conf)
             ├─33592 php-fpm: pool www
             └─33593 php-fpm: pool www

Jan 06 11:10:57 IPAM-RASPI systemd[1]: Starting The PHP 7.4 FastCGI Process Manager...
Jan 06 11:10:57 IPAM-RASPI systemd[1]: Started The PHP 7.4 FastCGI Process Manager.

Prima, läuft…

PHP Zeitzonen anpassen

Als Nächstes passen wir in den PHP Config Files (php.ini) die Zeitzonen Einstellungen an.

Ellenlange Dateien übrigens…

Wer den Nano Editor verwendet, STRG+W, dann Date eingeben und ENTER. So landet man direkt beim „Date“ Eintrag… 😉

Wir beginnen mit der fpm Datei…

sudo nano /etc/php/*/fpm/php.ini

und passen die Einstellung wie folgt an:

[Date]
date.timezone = Europe/Berlin

und dann noch die Default PHP Config Datei:

sudo nano /etc/php/7.4/apache2/php.ini

Auch hier wieder die Option:

[Date]
date.timezone = Europe/Berlin

und auch die in der PHP-CLI noch:

sudo nano /etc/php/7.4/cli/php.ini

natürlich auch hier wieder die Option:

[Date]
date.timezone = Europe/Berlin

Jetzt direkt den FPM-Service neu starten:

sudo systemctl restart php*-fpm.service

Apache2 und MariaDB vorbereiten

Zuerst lassen wir beide Dienste mal automatisch starten, wenn das System rebootet wurde.

Zuerst den MariaDB Service:

sudo systemctl enable --now mariadb

Erwartete Ausgabe:

Synchronizing state of mariadb.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable mariadb

dann den Apache2 Service:

sudo systemctl enable --now apache2

Erwartete Ausgabe:

Synchronizing state of apache2.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable apache2

MariaDB Instanz härten / phpIPAM DB und User anlegen

Wir legen also jetzt das MariaDB root Passwort fest und erstellen im Anchluss direkt die Datenbank und einen Benutzer für phpIPAM.

Zunächst härten mit dem MariaDB CLI Wizard…

sudo mysql_secure_installation

Jetzt startet ein Wizard, den man wie abgebildet abarbeitet und das neu vergebene root Passwort natürlich sichert.

Dieses Passwort benötigen wir nämlich später noch!

Mariadb 1
Mariadb 2

und schon ist dieser Part erledigt…

Jetzt erstellen wir die leere Datenbank, den Datenbank Benutzer für phpIPAM und legen dessen Passwort fest.

Dieses brauchen wir später bei der Einrichtung von phpIPAM nochmal.

Dazu melden wir uns zuerst am MariaDB Server an und verwenden das oben vergebene root Passwort:

mysql -u root -p

Nach erfolgreicher Anmeldung

  • erstellen wir die Datenbank namens „phpipam„
  • weisen dem DB Benutzer volle Zugriffsrechte zu, dessen Benutzername ebenfalls „phpipam“ lautet und dessen „mega-sicheres-passwort!“ Ihr selbstverständlich anpasst und dokumentiert
  • Am Ende laden wir die Grant Tables neu, damit die Änderungen auch direkt übernommen und gespeichert werden

All das erledigen mit den folgenden vier Zeilen SQL Statement:

CREATE DATABASE phpipam;
GRANT ALL ON phpipam.* TO phpipam@localhost IDENTIFIED BY 'mega-sicheres-passwort!';
FLUSH PRIVILEGES;
QUIT;

Ok, auch erledigt…

phpIPAM Installation

phpIPAM ist keine konventionelle Applikation, die eine Installationsroutine besitzt. Es ist eine Webanwendung. Die „Installation“ ist also vielmehr ein Kopiervorgang, bei dem alle Dateien aus dem aktuellen GITHub Repository von phpIPAM, auf unseren Server (Raspi) und hier ins Web Verzeichnis, dem sog. Document Root des Apache2 Servers kopiert werden. GIT als hierfür notwendiges „Kopiertool“ haben wir bereits installiert.

GitHub Repo clonen

Deshalb können wir den Vorgang jetzt wie folgt starten:

sudo git clone --recursive https://github.com/phpipam/phpipam.git /var/www/html/phpipam

Der Vorgang dauert je nach Geschwindigkeit der Internetverbindung etwas…

Config erstellen und DB Connection anpassen

Nachdem das erledigt ist, wechseln wir ins phpIPAM Verzeichnis

cd /var/www/html/phpipam

erstellen die Konfigurationsdatei für phpIPAM:

sudo cp config.dist.php config.php

und passen die Verbindung zum Datenbankserver an:

sudo nano config.php

und suchen diesen Teil der Datei. 

/ ** 
* database connection details
******************************/
$db['host'] = 'localhost';
$db['user'] = 'phpipam';
$db['pass'] = 'mega-sicheres-passwort!';
$db['name'] = 'phpipam';
$db['port'] = 3306;

Da alle anderen Parameter bereits standardmäßig alle korrekt sind, müssen wir nur noch das Passwort des phpipam DB Users in Zeile 6 anpassen (In der Original Datei weicht diese Zeilennummer ab!)

phpIPAM Datenbankschema importieren

Die Datenbank haben wir bereits erstellt, jetzt importieren wir sämtliche Tabellen und Verweise in die neue Datenbank. Dazu liefert phpIPAM eine SQL Datei mit.

sudo mysql -u root -p phpipam < /var/www/html/phpipam/db/SCHEMA.sql

Nach Eingabe des root Passworts ist der Job nach einigen Millisekunden bereits erledigt.

Apache Webserver Konfiguration

Wenden wir uns jetzt also dem Apache Webserver und dessen Konfiguration zu. Die Erklärung warum und weshalb man das alles so tut, wie ich es getan habe muss ich hier auslassen, das würde den eh schon großen Rahmen dieses Guide sprengen. Insofern einfach schrittweise die folgenden ToDo’s umsetzen…

Zuerst erstellen wir einen neuen, sog. „Virtual Host“, indem wir zuerst das Default Config File deaktivieren.

cd /etc/apache2/sites-available/
sudo mv 000-default.conf 000-default.conf.bak

und dann eine neue Konfiguration für unsere phpIPAM Applikation erstellen…

sudo nano /etc/apache2/sites-available/phpipam.conf

Den folgenden Inhalt könnt ihr dann einfach in diese Datei kopieren und müsst dann nur – gemäß Eurer Vorgaben – die Zeilen 2 und 4 anpassen:

<VirtualHost *:80>
    ServerAdmin webmaster@euredomain.com
    DocumentRoot "/var/www/html/phpipam"
    ServerName ipam.euredomain.com
    <Directory "/var/www/html/phpipam">
        Options Indexes FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>
    ErrorLog "/var/log/apache2/phpipam-error_log"
    CustomLog "/var/log/apache2/phpipam-access_log" combined
</VirtualHost>

Jetzt passen wir die Berechtigungen des Apache Dienstbenutzers (www-data) an:

sudo chown -R www-data:www-data /var/www/html/

und prüfen dann, ob unsere Konfigurationsdatei syntaktisch korrekt ist, also vom Apache Webserver auch verwendet werden kann:

sudo apachectl -t

Erste Ausgabe bei mir, falls das noch jemandem passiert:

AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message

Ich hab tatsächlich ne Weile gebraucht, bis ich die Ursache verstanden und das Problem lösen konnte.

Bei mir waren es ein fehlende Host Einträge, weshalb der Apache den Hostnamen der ServerName Direktive nicht auflösen konnte.

Nachdem ich beide Einträge in Zeile 6 und 7 in der hosts Datei gesetzt hatte, war der Spuk vorbei.

Also prüfen wir zur Sicherheit nochmal den vergebenen Hostnamen des Raspi (oder Servers):

hostname

editieren die hosts Datei:

sudo nano /etc/hosts

und setzen die Einträge in Zeile 6 und 7 (bitte an Euren Hostnamen anpassen)

127.0.0.1	localhost
::1			localhost ip6-localhost ip6-loopback
ff02::1		ip6-allnodes
ff02::2		ip6-allrouters

127.0.1.1	IPAM-RASPI.euredomain.com
127.0.1.1	IPAM-RASPI

Prüfen nun erneut die Konfigurationsdatei:

sudo apachectl -t

Erwartete Ausgabe:

Syntax OK

Jetzt den Apache Rewrite Mod aktivieren:

sudo a2enmod rewrite

Und den Apache Service neu starten

sudo systemctl restart apache2

Status des Apache2 Service prüfen:

sudo systemctl status apache2

Erwartete Ausgabe:

● apache2.service - The Apache HTTP Server
     Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2024-01-05 15:30:27 CET; 0min 26s ago
       Docs: https://httpd.apache.org/docs/2.4/
    Process: 83668 ExecStart=/usr/sbin/apachectl start (code=exited, status=0/SUCCESS)
   Main PID: 83672 (apache2)
      Tasks: 6 (limit: 779)
        CPU: 333ms
     CGroup: /system.slice/apache2.service
             ├─83672 /usr/sbin/apache2 -k start
             ├─83673 /usr/sbin/apache2 -k start
             ├─83674 /usr/sbin/apache2 -k start
             ├─83675 /usr/sbin/apache2 -k start
             ├─83676 /usr/sbin/apache2 -k start
             └─83677 /usr/sbin/apache2 -k start

Jan 07 17:30:27 IPAM-RASPI systemd[1]: Starting The Apache HTTP Server...
Jan 07 17:30:27 IPAM-RASPI systemd[1]: Started The Apache HTTP Server.

Geschafft!

Das war im Prinzip schon die Bereitstellung des Systems!

Jetzt kann man schonmal einen ersten Blick auf das System werfen unter:

http://eure_raspi_ip

oder

http://euer-dns-name.euredomain.com

Ihr müsstet jetzt bereits die Anmeldeseite von phpIPAM sehen…

Phpipam 1

Möchte man sich auch schonmal einloggen, lautet der Default Login:

Benutzername: admin

Passwort: ipamadmin

Das Passwort ist selbstverständlich sofort zu ändern.

Vergebt hier bitte ein möglichst komplexes und sicheres Passwort, denn dieses System wird die vermutlich wichtigsten Informationen Eurer Infrastruktur speichern!

Cronjobs für automatische Vorgänge konfigurieren

Diese Konfiguration ist erforderlich für:

  • die automatische Suche nach neuen Hosts
  • die regelmäßige Prüfung bereits vorhandener Hosts

Die beiden oben genannten automatischen Vorgänge sind für mich ein essentieller Teil der Features von phpIPAM. Im Gegensatz zu statischen Listen, werden so IP’s, die bereits vergeben wurden ständig überprüft, ob die entsprechenden Hosts noch online, die IP’s also noch in Verwendung sind. Zudem vermerkt phpIPAM auch den Zeitpunkt des letzten „Alive“ Status dieser IP. So kann es eben nicht passieren, dass IÜ’s doppelt vergeben werden. Wer so einen Fehler scho einmal suchen musste, wird wissen was das für einen zeitlichen Aufwand bedeuten und für einen üblen Impact haben kann! Zum Zweiten wird ständig überprüft, ob neue Hosts hinzugekommen und damit IP Adressen „verbraucht“ wurden. Nicht selten heben Kollegen ein System ins Netz und „vergessen“ doch glatt bescheid zu sagen… 😉

Für diese beiden Aufgaben liefert phpIPAM zwei Scripte mit, die via Cronjob regelmäßig ausgeführt werden (können).

  • pingCheck.php -> Alive Check
  • discoveryCheck.php -> Discovery Check

Die Konfiguration erfolgt über einen entsprechenden Cronjob, bei welchem die Scripte zeitgesteuert, mit dem PHP Interpreter ausgeführt werden.

Dazu finden wir zunächst heraus, wo unser PHP Interpreter aufzurufen ist, da dieser Aufruf von PHP Version zu PHP Version variieren kann:

whereis php

Erwartete Augabe:

php: /usr/bin/php7.4 /usr/bin/php /usr/bin/php.default /usr/lib/php /etc/php /usr/include/php /usr/share/php7.4-opcache /usr/share/php7.4-mysql /usr/share/php7.4-snmp /usr/share/php7.4-tidy /usr/share/php7.4-xml /usr/share/php7.4-gmp /usr/share/php /usr/share/php7.4-ldap /usr/share/php7.4-json /usr/share/php7.4-readline /usr/share/php7.4-mbstring /usr/share/php7.4-intl /usr/share/php7.4-common /usr/share/php7.4-xmlrpc /usr/share/php7.4-curl /usr/share/php7.4-pspell /usr/share/php7.4-gd /usr/share/php7.4-imap /usr/share/man/man1/php.1.gz

entscheidend für uns bereits die ersten Zeichen der Ausgabe /usr/bin/php7.4.

Damit werden wir diese Scripte also aufrufen, was wir wie folgt umsetzen:

sudo crontab -e

Sollte hier eine Abfrage zum Editor erfolgen, einfach die 1 auswählen…

Jetzt die folgenden Zeilen in die Datei kopieren:

*/15 * * * * /usr/bin/php7.4 /var/www/html/phpipam/functions/scripts/pingCheck.php
15 */2 * * * /usr/bin/php7.4 /var/www/html/phpipam/functions/scripts/discoveryCheck.php

Die hier gemachten Timings, bedeuten übrigens:

  • alle 15 Minuten werden die bekannten IP’s auf Keep Alive überprüft
  • alle 2 Stunden, in der 15. Minute (also viertel nach 8, viertel nach 10, etc…) wird in den Netzen nach neuen Hosts gesucht.

Startzeitpunkt ist übrigens sofort nach dem Speichern der Cronjobs. Das sind natürlich nur Vorschläge, Ihr könnt das jederzeit an Eure Bedürfnisse anpassen.

Beachtet jedoch hierbei immer die Einstellungen in phpIPAM, zur Markierung von IP’s unter „phpIPAM Settings“ -> „ICMP Settings“ -> „Ping status intervals“… 😉

Phpipam Icmp Settings

Solltet Ihr bei diesen Einstellungen also bspw. „nur“ alle 45 Minuten einen Scan starten, erhält man für bekannte IP’s eine Warnung, da der Interval größer, als der Warnzeitpunkt ist.

Ob die die Scripte funktionieren kann man übrigens testen, indem man sie einfach ausführt, also bspw. einfach diese Zeile in die Shell kopieren und ENTER:

/usr/bin/php7.4 /var/www/html/phpipam/functions/scripts/pingCheck.php

Erwartete Ausgabe:

pingCheck: Scan start, 26 IPs
pingCheck: Scan complete, 0 updates

Anpassungen

phpIPAM mit SSL absichern (HTTPS aktivieren)

Sicher der meist abgerufene Guide mittlerweile, da natürlich niemand mehr unverschlüsselt, auch nicht innerhalb des lokalen Netzwerkes kommunizieren möchte. In meinem Beispiel nutze ich ein selbstsigniertes Zertifikat, nur um die grundsätzliche Vorgehensweise zu demonstrieren. Wenn Ihr ein öffentlich signiertes SSL-Zertifikat (mit dem passenden Subject Name) oder gar ein Wildcard SSL-Zertifikat Euer eigen nennt, verwendet selbstverständlich dieses. Ich werde auch hier nur die wichtigsten Steps beschreiben. Das warum und woher würde einfach den Rahmen sprengen…

Zunächst prüfen wir, ob der Apache eventuell schon auf 443 horcht und Content liefert…

curl -vk https://localhost/ -o /dev/null

Erwartete Ausgabe:

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying ::1:443...
* connect to ::1 port 443 failed: Connection refused
*   Trying 127.0.0.1:443...
* connect to 127.0.0.1 port 443 failed: Connection refused
* Failed to connect to localhost port 443: Connection refused
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
* Closing connection 0
curl: (7) Failed to connect to localhost port 443: Connection refused

Ok, hier ist (noch) tote Hose…

Ok, zuerst Modul SSL aktivieren:

sudo a2enmod ssl

Erwartete Ausgabe:

Considering dependency setenvif for ssl:
Module setenvif already enabled
Considering dependency mime for ssl:
Module mime already enabled
Considering dependency socache_shmcb for ssl:
Enabling module socache_shmcb.
Enabling module ssl.
See /usr/share/doc/apache2/README.Debian.gz on how to configure SSL and create self-signed certificates.
To activate the new configuration, you need to run:
  systemctl restart apache2

Apache neu starten:

sudo systemctl restart apache2

Apache Status prüfen:

sudo systemctl status apache2

Erneute Prüfung, ob Modul SSL aktiviert wurde:

curl -vk https://localhost/ -o /dev/null

Unerwartete Ausgabe „error:1408F10B:SSL routines:ssl3_get_record:wrong version number„

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying ::1:443...
* Connected to localhost (::1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* error:1408F10B:SSL routines:ssl3_get_record:wrong version number
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
* Closing connection 0
curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number

Fix mit:

sudo a2ensite default-ssl
sudo systemctl restart apache2

Erneuter Test

curl -vk https://localhost/ -o /dev/null

Erwartete Ausgabe (Auszug):

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying ::1:443...
* Connected to localhost (::1) port 443 (#0)
...
...
...
* Connection #0 to host localhost left intact

Ok, wir sind im Rennen…

Härten wir gleich den Apache2 ein wenig und lassen nur Zugriffe via TLS Version 1.2 und 1.3 zu:

sudo nano /etc/apache2/mods-available/ssl.conf

Datei wie folgt anpassen (bachte speziell Zeile 4):

#   The protocols to enable.
        #   Available values: all, SSLv3, TLSv1, TLSv1.1, TLSv1.2
        #   SSL v2  is no longer supported
        SSLProtocol -all +TLSv1.2 +TLSv1.3
sudo systemctl restart apache2

Ab jetzt handelt der Apache Webserver mit dem Client nur Verbindungen aus, welche mit TLS v1.2 oder TLS v1.3 verschlüsselt sind.

Beachtet das bei der Auswahl und den Funktionen der Web Browser, die auf phpIPAM zugreifen werden – speziell wenn „ältere“ Browserversionen verwendet werden (müssen/sollen).

Der Browser muss zwingend eines der beiden Protokolle unterstützen!

Verzeichnis für das Abspeichern des Server Certificate und des Certificate Private Key erstellen:

Der Ort ist natürlich frei wählbar, dann aber bitte die Anpassungen in der ssl.conf überrnehmen!

sudo mkdir /etc/apache2/ssl

Wizard für das selbstsignierte Zertikat starten:

Laufzeit 365 Tage, Name: apache.crt. Kann auch wieder angepasst werden, bitte bei der ssl.comf später beachten!

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/apache2/ssl/apache.key -out /etc/apache2/ssl/apache.crt

Erwartete Ausgabe:

Generating a RSA private key
................................................................................................................+++++
.............................................................................................+++++
writing new private key to '/etc/apache2/ssl/apache.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:<Euer Bundesland>
Locality Name (eg, city) []:<Euer Ort>
Organization Name (eg, company) [Internet Widgits Pty Ltd]:<Eure Organisation>
Organizational Unit Name (eg, section) []:<Eure Abteilung>
Common Name (e.g. server FQDN or YOUR name) []:euer-dns-name.euredomain.com <- Hier muss jetzt exakt der FQDN angegeben werden, der dann auch im Browser aufgerufen wird, also das sog. "Certificate Subject".
Email Address []:hostmaster@eure-domain.com

Prüfen, ob das Zetifikat und der private key abgelegt wurden:

ls /etc/apache2/ssl/

Erwartete Ausgabe:

apache.crt  apache.key

Damit dieses Zertifikat auch verwendet wird, müssen wir nun die SSL Konfiguration des Virtual Host anpassen. Der Einfachheit halber passen wir hierfür „nur“ die Default SSL Konfiguration an. Experten können hierfür selbstverständlich eine angepasste SSL-Konfiguration erstellen und aktivieren. (Stichwort a2ensite…).

sudo nano /etc/apache2/sites-available/default-ssl.conf

Die Datei passt Ihr mit Euren Werten an. Wenn Ihr die phpIPAM Dateien und das Zertifikat, sowie den Private Key exakt in den selben Pfad abgelegt habt, wie oben beschrieben, dann muss der entscheidende Teil der Datei am Ende so aussehen (Beachtet die Zeilen 4, 14 und 15, denn die Zeilen dahinter bleiben unverändert!):

<VirtualHost _default_:443>
                ServerAdmin webmaster@localhost

                DocumentRoot /var/www/html/phpipam
…

SSLEngine on

                #   A self-signed (snakeoil) certificate can be created by installing
                #   the ssl-cert package. See
                #   /usr/share/doc/apache2/README.Debian.gz for more info.
                #   If both key and certificate are stored in the same file, only the
                #   SSLCertificateFile directive is needed.
                SSLCertificateFile      /etc/apache2/ssl/apache.crt
                SSLCertificateKeyFile /etc/apache2/ssl/apache.key

Damit es nicht zu einer Zertifikatsfehlermeldung im Browser kommt, muss nun noch das Zertifikat, also die Datei apache.crt im Zertifikatsspeicher der Clients, als „Vertrauenswürdige Stammzertifizierungsstelle“ importiert werden. Das Ganze manuell oder eben via GPO. Beachtet, dass Firefox bspw. einen eigenen Zertifikatsspeicher pflegt und nutzt. Auch dort muss es importiert werden!

Anschließend kann man den verschlüsselten Zugriff auf:

https://eure_raspi_ip

oder

https://euer-dns-name.euredomain.com

testen.

Permanente Umleitung auf HTTPS einrichten

Wenn HTTPS funktioniert, leiten wir am besten unverschlüsselte HTTP-Anfragen dauerhaft auf HTTPS um.

Dazu passen wir unser Virtual Host Konfiguration an, indem wir zuerst unsere phpipam.conf als phpipam.http.conf.bak sichern…

cd /etc/apache2/sites-available/
sudo mv phpipam.conf phpipam.http.conf.bak

diese dann als neue phpipam.conf anlegen…

sudo cp phpipam.http.conf.bak phpipam.conf

…diese editieren…

sudo nano phpipam.conf

… indem wir die Zeilen 3 – 10 auskommentieren (Hashtags davor) und die Zeile 11 hinzufügen. Am Ende die Datei speichern mit Strg+O -> ENTER und schließen mit STRG+X

<VirtualHost *:80>
    ServerAdmin webmaster@euredomain.com
    # DocumentRoot "/var/www/html/phpipam"
    # ServerName ipam.euredomain.com
    # ServerAlias ipam.euredomain.com
    # <Directory "/var/www/html/phpipam">
    #     Options Indexes FollowSymLinks
    #     AllowOverride All
    #     Require all granted
    # </Directory>
    Redirect permanent / https://ipam.euredomain.com
    ErrorLog "/var/log/apache2/phpipam-error_log"
    CustomLog "/var/log/apache2/phpipam-access_log" combined
</VirtualHost>

Wieder ein Neustart des Apache Servers:

sudo systemctl restart apache2

Jetzt testen mit Zugriff auf:

http://eure_raspi_ip

oder

http://euer-dns-name.euredomain.com

und Ihr müsstet jetzt automatisch umgeleitet werden auf:

https://ipam.euredomain.com

HTTPS Zugriff mit einem Letsencrypt Zertifikat schützen

Wenn ihr jetzt noch ein öffentliches Zertifikat benötigt und dieses kostenlos sein soll, könnte dieser Beitrag weiterhelfen.

Und jetzt viel Spaß…

Jetzt gilt es sich natürlich mit dem System und dessen Verwaltung zu befassen, wie bei jeder anderen Applikation auch. Wichtig ist herauszufinden wie phpIPAM in der Praxis am besten zu verwenden ist. Dabei wünsche ich Euch viel Erfolg und natürlich auch ein bisschen Spaß! Ich hoffe der Guide konnte Euch ein wenig beim Einstieg ins Thema IPAM behilflich sein! 😉

Quellen:

Abschließend möchte ich selbstverständlich noch die unterschiedlichen Quellen nennen, die es mir ermöglicht haben, diesen Guide zu erstellen. Ich habe die Infos also nur noch zu dieser Anleitung zusammengeführt, alles getestet, dokumentiert, einiges etwas vereinfacht oder angepasst und hoffentlich ganz gut veranschaulicht. 🙂

Beitrag Teilen via...

3 Kommentare

  2. Hi, vielen Dank für diese sehr gute Anleitung, um phpipam auf Debian zu installieren. Diese war so ziemlich die einzige, die ich im Netz gefunden habe, die auch mit Debian 12.5 funktioniert ohne Fehlermeldungen. Ich hätte da aber noch eine Frage: Ist es möglich, durch Scan der Subnetze, den aktiven IP-Adressen auch die MAC-Adresse hinzuzufügen? Wenn ja wie? Vielen Dank schon einmal vorab. VG Oliver K.

    • Hi Oliver,

      zu Deiner Frage nur zwei Hinweise…
      Zum Einen erfordert der ARP-Request, den Du hier meinst, dass sich das IPAM System (oder mindestens ein Interface des Systems) unweigerlich im selben Subnet wie das gescannte Device befinden muss, denn ARP-Requests funktionieren in der Regel (also ohne aktiviertes IP Forwarding) nicht über Subnetzgrenzen (also Router) hinweg.
      Zum Anderen weiß ich, dass diese Funktion im Discovery Scan zwar implementiert ist, kann aber für Details zur Umsetzung und Integration, auch nur auf das offizielle Github Repository verweisen:
      https://github.com/phpipam/phpipam

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Seite ist durch reCAPTCHA und Google geschützt Datenschutz-Bestimmungen und Nutzungsbedingungen anwenden.