Konfiguration des Proxyserver Squid mit SquidGuard und Authenifizierung


Ich werde heute beschreiben wie man den Proxy-Server Squid mit SquidGard einrichtet und Zugriff per Benutzer-Authentifizierung.
Anlass ist, das ich selbst bei mir zuhause diese Kombination einsetze, um meinen Kindern manche nicht kinderfreundlichen Inhalte im Web zu ersparen und zu blocken.
Es gibt verschiedene Einsatz-Scenarien von Squid z.B als Caching von Webseiten zum schnellen Anzeigen im Browser.
Zuerst muss man die Pakete dafür installieren, bei mir im Fall von openSUSE-Leap. Pakete können sich bei anderen Linux Distributionen unterscheiden.
zypper in squid squidGuard
Anschließend den Proxyserver Squid beim Systemstart aktivieren:
systemctl enable squid.service
Starten von Squid
systemctl start squid.service
Bei der fertigen Umgebung wird Squid die Anfragen über den SquidGuard leiten, zum die URL’s oder Domains zu überprüfen, ob derjenige Benutzer die Inhalte sehen darf oder nicht.

Als erstes konfiguriere ich den Squid, Konfigurationsdatei liegt unter:

cd /etc/squid/ && vim squid.confz.B meine squid.conf
auth_param basic program /usr/sbin/basic_pam_auth #----> Wichtig Authentifizierung von Usern, wird per Popup erscheinen
auth_param basic children 5 startup=0 idle=1
auth_param basic realm Squid proxy-caching web server
acl localnet src 192.168.100.0/24 # RFC1918 possible internal network #----> Wichtig Zugriff Regel für das Netz von Squid
acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT
acl password proxy_auth REQUIRED
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost manager
http_access deny manager
http_access allow localnet password
http_access allow localhost
http_access deny all
http_port 3145
coredump_dir /var/cache/squid
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern . 0 20% 4320
err_page_stylesheet /etc/squid/errorpage.css
redirect_program /usr/sbin/squidGuard -c /etc/squidguard.conf #-----> Wichig weiterleitung über SquidGuard und liest Konfig von squid ein
redirect_children 5 #----> Wieviele Kindprozesse darf Squidguard öffnen.

Es wird in dieser Konfig-Datei vieles per Kommentar erklärt, hier empfiehlt sich es mal gelesen zu haben.

Dann müssen noch Berechtigungen der Datei
/usr/sbin/basic_pam_auth
gesetzt werden, damit die Authentifizierung über die angelegten Benutzer funktioniert:
chgroup shadow /usr/sbin/basic_pam_auth
chmod g+s /usr/sbin/basic_pam_auth

Damit alles aktiv geschaltet wird müssen wird den Proxyserver neustarten:
systemctl restart squid.service

So jetzt damit kommen wir zum SquidGuard:
Die Konfigurationsdatei heisst:
vim /etc/squidguard.conf;
Ein Beispiel von mir:
logdir /var/log/squidGuard
dbhome /var/lib/squidGuard/db
src parents {
ip 192.168.100.0/24 # range 192.168.10.0 - 192.168.10.255
# AND
user papa mama # ident Papa und Mama
}
src kids {
ip 192.168.10.17 # Notebook Kind 1
user username # ident Kind1
# AND
ip 192.168.10.14 # Notebook Kind 2
user username (Kind # ident Kind2
}
dest blacklist {
domainlist blacklist/domains
urllist blacklist/urls
}
#####
#
# Zeitregeln
#####
# abbrev for weekdays:
s = sun, m = mon, t =tue, w = wed, h = thu, f = fri, a = sat
time tagsueber {
weekly mtwhfas 12:00-16:00 # Unter der Woche
}
acl {
parents {
pass all
}
kids {
pass !blacklist all
}
default {
pass none
redirect http://hostname/cgi-bin/squidGuard.cgi/blocked?clientaddr=%a&clientname=%n&clientuser=%i&clientgroup=%s&url=%u

Die Datei ist eigentlich sehr einfach strukturiert und auf der Webseite von SquidGuard gut erklärt, deswegen verlinke ich hier gern:
http://www.squidguard.org/Doc/configure.html

Für das Blocken von nicht kinderfreundlichen Seiten gibt es schon fertige Listen, die das meiste auch schon abdecken:
Block-Listen
Diese Listen müssen entpackt und in das Verzeichnis:
cd /var/lib/squidGuard/db/blacklist/
kopiert werden und anschließend initialisiert werden:
squidGuard -C all

So, jetzt sollte alles soweit funktionieren, testen kann man am besten, in dem man mit einem Benutzer, der für das Blocken eingerichtet ist, geblockte URL’s oder Domains aufzurufen, um zu sehen ob diese Seite aufgerufen werden kann.

In diesem Sinne Have Fun!

Johannes Carraro

Autor: Johannes Carraro

Bevor Johannes bei NETWAYS anheuerte war er knapp drei Jahre als Systemadministrator in Ansbach tätig. Seit Februar 2016 verstärkt er nun unser Managed Services Team als Systems Engineer. In seiner Freizeit spielt Johannes E-Gitarre in einer Metalband, bastelt an Linux Systemen zuhause herum und ertüchtigt sich beim Tischtennisspielen im Verein, bzw. Mountainbiken, Inlinern und nicht zuletzt Skifahren

Analyse der Konfigration bei Galera-MySQL-Cluster

Ich möchte in diesem Blog-Beitrag noch Ergänzungen zum Galera-Blog von Marius zum Thema Konfiguration-Check machen.

Zum Beispiel kann man bestimmte Statis abfragen, ob der Cluster synchronisiert ist oder wie viele Nodes der Cluster besitzt und noch einiges mehr.
Kurz zum Verständnis bei MySQL ist das Prozentzeichen(%) das Wildcard wie bei der Bash das Sternchen(*).
Das werde ich Anhand nachfolgender Beispiele erklären.

Die Anzahl der Nodes im Cluster:

mariaDB [(none)]> show status like 'wsrep_cluster_size%';
+--------------------+-------+
| Variable_name | Value |
+--------------------+-------+
| wsrep_cluster_size | 3 |
+--------------------+-------+

Wie man sehen kann sind hier 3 Nodes im Cluster.

Den aktuellen Sync-Status im Cluster wird so ermittelt:

MariaDB [(none)]> show status like 'wsrep_local_state_comment%';
+---------------------------+--------+
| Variable_name | Value |
+---------------------------+--------+
| wsrep_local_state_comment | Synced |
+---------------------------+--------+

Die Ausgabe sollte hier selbsterklärend sein.

Um alle Statis von dem Cluster abzurufen kann man dieses Kommando benutzen:
show status like 'wsrep_%';
| wsrep_provider_name | Galera |
| wsrep_provider_vendor | Codership Oy <info@codership.com> |
| wsrep_provider_version | 25.3.19(r3667) |
| wsrep_ready | ON |
| wsrep_received | 56804 |
| wsrep_received_bytes | 2506329647 |
| wsrep_repl_data_bytes | 352492270

Das ist nur ein kleiner Ausschnitt aus dem Ouput der hier herauskommt

Jetzt kommen wir zur eingestellten Konfiguration, die man hier auch auslesen kann, um spätere Anpassungen vorzunehmen kann.
Die Werte dafür sind in Variablen bei MySQL gespeichert und können wie folgt abgerufen werden:

Die max_allow Variablen kann man so ermitteln:

MariaDB [(none)]> show variables like '%max_allow%';
+--------------------------+------------+
| Variable_name | Value |
+--------------------------+------------+
| max_allowed_packet | 536870912 |
| slave_max_allowed_packet | 1073741824 |
+--------------------------+------------+

Wenn man hier etwas herumspielt mit den Werten, kann man erstaunliches und informatives herausfinden.

So als kleiner Einstieg sollte dieser Beitrag ausreichen damit man die wichtigsten Einstellungen beim Galera-Cluster ausgegeben bekommt.
Lesenswert Link:
Galera Dokumtentation

Empfehlenswert sind natürlich unsere Schulungen im Bereich, die auf jeden Fall einen Blick wert sind.

Johannes Carraro

Autor: Johannes Carraro

Bevor Johannes bei NETWAYS anheuerte war er knapp drei Jahre als Systemadministrator in Ansbach tätig. Seit Februar 2016 verstärkt er nun unser Managed Services Team als Systems Engineer. In seiner Freizeit spielt Johannes E-Gitarre in einer Metalband, bastelt an Linux Systemen zuhause herum und ertüchtigt sich beim Tischtennisspielen im Verein, bzw. Mountainbiken, Inlinern und nicht zuletzt Skifahren

Konvertierung des alten ext4 Dateisystems zum btrfs Dateisystem

Da das Datei-System Btrfs schon einige Zeit als “stable” (stabil) angesehen wird, möchte ich hier kurz beschreiben, wie man sein bestehendes ext4 Dateisystem zum btrfs Dateisystem konvertieren kann.

Bevor man mit der ganzen Prozedur anfängt, sollte man sein ext4 Dateisystem einem Filesystem-Check unterziehen um eventuelle Fehler auszumachen.
Ich boote dazu mein System mit einem Live-CD USB-Stick von einer beliebigen Linux Distribution, damit alle Partitionen nicht eingehängt (mounted) sind
So lassen sich alle Filesystem-Checks gut durchführen.
# fsck.ext4 -f /dev/sdX

Gehen wir jetzt mal von einem intakten ext4 Dateisystem aus, kann man jetzt (voraus man hat auch ein Backup erstellt) mit der Konvertierung zum neuen btrfs Dateisystem beginnen.

Wer so eine Konvertierung zum ersten Mal macht, sollte eine andere Partition als der root-Partition wählen, da bei dieser noch weitere Nacharbeiten zu erledigen sind.

Prüfen, ob die btrfs-tools installiert sind:
# # rpm -qa | grep btrfs --> rpm-based Linux Distros
btrfsprogs-4.5.3-6.3.x86_64

# dpkg -l | grep btrfs --> deb-based Linux Distros
ii btrfs-tools 3.12-1ubuntu0.1

Mit folgendem Befehl startet man die Konvertierung:
ca. 20% freier Speicherplatz sollte für die Konvertierung vorhanden sein.
# btrfs-convert /dev/sdX
Es wird automatisch ein btrfs subvolume erstellt das sich ext4_saved nennt erstellt, das eine spätere Rückkonvertierung zum alten ext4 Dateisystem ermöglicht.

Nach erfolgreicher Konvertierung muss man diese Partition einhängen und noch den mountpoint Typ im der Datei ‘/etc/fstab’ abändern:
mount /dev/sdX /mnt
# vim /mnt/etc/fstab
z.B
UUID=e52d7524-230c-413e-9c26-8c94b94c34b2 /home btrfs defaults 0 0

Man ändert hier von ext4 auf btrfs und speichert die Datei wieder ab. Anschließend erfolgt eine Neustart des Systems
um abschließend die Funktion zu testen.

Mit folgendem Befehl wird die Rückkonvertierung zu ext4 ermöglicht:
# btrfs-convert -r /dev/sdX

So nun kann man das neue Datei-System auf Herz und Nieren testen, für mich hat es den Langzeittest schon bestanden, da ich es fast überall seit langem auf meinen Systemen einsetze, z.B RAID5 beim Server oder auch als home-Partition, die automatische Snapshot-funktion mit Snapper finde ich besonders gelungen. Bei SUSE Enterprise Server oder openSUSE-Leap/Tumbleweed ist es Standard als root-Filesystem.

Johannes Carraro

Autor: Johannes Carraro

Bevor Johannes bei NETWAYS anheuerte war er knapp drei Jahre als Systemadministrator in Ansbach tätig. Seit Februar 2016 verstärkt er nun unser Managed Services Team als Systems Engineer. In seiner Freizeit spielt Johannes E-Gitarre in einer Metalband, bastelt an Linux Systemen zuhause herum und ertüchtigt sich beim Tischtennisspielen im Verein, bzw. Mountainbiken, Inlinern und nicht zuletzt Skifahren

Icinga Web 2 Modul fileshipper imports im Director

Es werden viele Importe im Icinga Web 2 Modul Director via Ldap / SQL-Ressource getätigt, aber viele übesehen eine einfache Möglichkeit bestehende Dateien mittels Icinga 2 Modul “fileshipper” in den Icinga Web 2 Director zu importieren. Wie man dieses umsetzt werde ich an einem einfachen Beispiel, einer CSV-Datei hier beschreiben.

Zuerst muss man sich das Fileshipper-Modul von Github per “git clone” oder .zip-Datei herunterladen und in dem Verzeichnis '/usr/share/icingaweb2/modules/' ablegen und anschießend das Verzeichnis in “fileshipper” umbennen, denn sonst erkennt es Icinga Web 2 als Modul nicht an.
# cd /usr/share/icingaweb2/modules/ && git clone https://github.com/Icinga/icingaweb2-module-fileshipper.git
oder
# cd /usr/share/icingaweb2/modules/ && unzip master.zip

Anschließend muss das neu installierte Modul noch aktiviert werden,  mit dem icingacli Kommando:
# icingacli module enable fileshipper
icingacli module list
MODULE VERSION STATE DESCRIPTION
director 1.3.1 enabled Director - Config tool for Icinga 2
doc 2.4.1 enabled Documentation module
fileshipper 1.0.0 enabled Fileshipper for Icinga Director
monitoring 2.4.1 enabled Icinga monitoring module

Es geht aber aber auch über die Icinga Web 2 –  Oberfläche siehe Screenshot:

Nachdem das Modul installiert und aktiviert ist kann es losgehen. Zuerst erstellt man das Verzeichnis “fileshipper” unter # mkdir /etc/icingaweb2/modules/fileshipper und erstellt eine import.ini Datei in der das Verzeichnis angeben wird, wo sich die zu importierenden Dateien (.csv) liegen.
[fileshipper files]
basedir = "/usr/local/share/"

Dann wird im Icinga Web 2 => Director => Automation => Add Import Source

ein Name des zukünftigen Imports z.B fileshipper-import-hosts vergeben und bei Source “Import from files (fileshipper) ausgewählt.

Jetzt muss die neue Import-Quelle noch modifiziert werden z.B. so:

Ich denke das Bild ist selbsterklärend und Bedarf keiner weiteren Erklärung.

Jetzt kann man einen Import run starten in dem man auf die Import-Source fileshipper-import-hosts und Trigger Import Run auswählt.

Nun sollte in der Voransicht (Preview) die importierten Hosts sichtbar werden.

Um jetzt aus diesen RAW-Daten Icinga 2 konforme Objekte werden zu lassen brauchen wir eine Sync-Rule die man z.B.so anlegt:


Hier wird in der Maske angeben, welcher Typ (Host-Objekt) daraus werden soll und ob bereits existierende Daten ersetzt (replace) oder zusammengeführt (merge) werden sollen.
Mit Purge können bereits existierende Daten gelöscht werde, JA oder NEIN.

Im Kartei-Reiter “Properties/Eigenschaften” werden die Felder vom Import (Source/Quelle) den Icinga 2 konformen Zielen (Destination) zugeordnet:

Danach kann der Sync-Run der erstellten Sync-Rule gestartet werden und bei erfolgreichen Lauf, werden Konfigurations-Dateien erstellt und sind bereit für den Director zu deployen.

Im Activity-Log kann der Vorgang nochmals überprüft werden, bevor man die Konfiguration per Director deploy übernehmen kann.

So jetzt sollten nach erfolgreichem Deployment die Hosts im Icinga Web 2 unter Hosts sichtbar sein.

 

Im Rahmen einer Icinga 2 Fundamentals Schulung, die wir anbieten, werden auch noch weitere Import-Quellen besprochen und praktisch vollzogen.

Unter anderem haben wir noch weitere Schulungen zu Open Source Themen im Portofolio, einen Überblick bekommen Sie hier bei NETWAYS-Schulungen.

Johannes Carraro

Autor: Johannes Carraro

Bevor Johannes bei NETWAYS anheuerte war er knapp drei Jahre als Systemadministrator in Ansbach tätig. Seit Februar 2016 verstärkt er nun unser Managed Services Team als Systems Engineer. In seiner Freizeit spielt Johannes E-Gitarre in einer Metalband, bastelt an Linux Systemen zuhause herum und ertüchtigt sich beim Tischtennisspielen im Verein, bzw. Mountainbiken, Inlinern und nicht zuletzt Skifahren

PNP4Nagios RRD Single/Multiple Storage

pnp4nagiosFür alle die das Nagios Plugin PNP4Nagios mit Icinga2 einsetzen, werden eventuell schon über folgende Fehlermeldung gestolpert sein,
oder noch stolpern:

/var/log/messages:
NPCD[65119]: ERROR: Executed command exits with return code '7'

/var/log/pnp4nagios/perfdata.log:
2016-09-15 13:53:55 [19510] [0] *** TIMEOUT: Timeout after 15 secs. ***
2016-09-15 13:53:55 [19510] [0] *** TIMEOUT: Deleting current file to avoid NPCD loops
2016-09-15 13:53:55 [19510] [0] *** TIMEOUT: Please check your process_perfdata.cfg
Einstellung:
'/etc/pnp4nagios/process_perfdata.cfg'
Option
RRD_STORAGE_TYPE = SINGLE

Ab der PNP-Version 0.6 ist es möglich, die Performance-Daten nicht in einer einzelnen RRD-Datenbank (SINGLE), sondern in mehreren RRD Datenbanken (MULTIPLE) zu speichern.
Diese Einstellung in der Konfigurations-Datei sollte NICHT global verändert werden, da PNP4Nagios nach dieser Umstellung auf MULTIPLE sofort beginnt, neue RRD-Files anzulegen. Alte Daten gehen damit sofort verloren!

Auf Grund der Performance ist es nicht sinnvoll, global mit RRD_STORAGE_TYPE = MULTIPLE zu arbeiten, da die Anzahl der RRD-Datenbanken und somit auch der Disk-I/O während der Updates sich vervielfachen würde. Deshalb sollte man überlegen, welche Nagios Checks mit dieser Einstellung gefahren werden.
Bestehende RRD-Datenbanken können über einen Konverter (Perl-Skript) '/usr/libexec/pnp4nagios/rrd_convert.pl' konvertiert werden.

Folgende Ausgabe bekommt man bei Ausführung des Perl-Skriptes:

Usage: /usr/libexec/pnp4nagios/rrd_convert.pl --check_command=
--cfg_dir= [ --list_commands ]
[ --dry-run ]
[ --tmp_dir= ]
[ --no_structure_check ]

Schaut dann so in etwa aus:

rrd-convert

# sudo -su icinga /usr/libexec/pnp4nagios/rrd_convert.pl --cfg_dir=/etc/pnp4nagios/ --check_command=disk --dry-run

Search pattern disk
XML Files analyzed 129
XML Files found 7
XML Files without RRD 0
Old XML Files ignored 0
Number of unique check_commands 15
Dry run? [YES]
Temp Directory /tmp/rrd_convert

This is only a 'dry run'. The new RRD Files are stored in '/tmp/rrd_convert'

Start Converter [n|y]?:y
File 1/7
RRDtool dump to /tmp/rrd_convert/icinga2-disk__.dump
Manipulating /tmp/rrd_convert/icinga2-disk__.dump
............ done 47999 lines
Restoring File
/tmp/rrd_convert/icinga2/disk____.rrd
... done
File 2/7
RRDtool dump to /tmp/rrd_convert/icinga2-disk.dump
Manipulating /tmp/rrd_convert/icinga2-disk.dump
............ done 48424 lines
Restoring File
/tmp/rrd_convert/icinga2/disk__tmp_vagrant-puppet_manifests-a11d1078b1b1f2e3bdea27312f6ba513.rrd
/tmp/rrd_convert/icinga2/disk__vagrant.rrd
/tmp/rrd_convert/icinga2/disk__.rrd
/tmp/rrd_convert/icinga2/disk__boot.rrd
/tmp/rrd_convert/icinga2/disk__home.rrd
/tmp/rrd_convert/icinga2/disk__tmp_vagrant-puppet_modules-41d422e93c9413f221fcbaa64a7964b7.rrd
... done
DONE

Schauen Sie doch einfach mal auf unserer Webseite vorbei, wir biete Schulungen zu vielen interessanten OpenSource-Themen an.

Johannes Carraro

Autor: Johannes Carraro

Bevor Johannes bei NETWAYS anheuerte war er knapp drei Jahre als Systemadministrator in Ansbach tätig. Seit Februar 2016 verstärkt er nun unser Managed Services Team als Systems Engineer. In seiner Freizeit spielt Johannes E-Gitarre in einer Metalband, bastelt an Linux Systemen zuhause herum und ertüchtigt sich beim Tischtennisspielen im Verein, bzw. Mountainbiken, Inlinern und nicht zuletzt Skifahren