Debian 12 : MFA für ssh/su/sudo aktivieren

Unter Windows ist es recht einfach einen MFA Schutz zu realisieren. Hier haben wir Windows Hello oder das Azure AD das uns das abnimmt.
Für den Mac gibt es TouchID aber für Linux muss man hier selbst etwas bauen.

Installation des benötigten Pakets
apt install libpam-google-authenticator -y
Konfigurieren von libpam-google-authenticator
google-authenticator
Jetzt kommen einige Fragen zur Konfiguration
Do you want authentication tokens to be time-based (y/n) y
An dieser Stelle wird der QR Code Angezeigt, dieser kann kann jetzt gescannt werden und in der Authenticator App deiner Wahl eingepflegt werden. Und dann gehts weiter mit folgenden Fragen
Do you want me to update your "/chris/.google_authenticator" file? (y/n) y

Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n) y

By default, a new token is generated every 30 seconds by the mobile app.
In order to compensate for possible time-skew between the client and the server,
we allow an extra token before and after the current time. This allows for a
time skew of up to 30 seconds between authentication server and client. If you
experience problems with poor time synchronization, you can increase the window
from its default size of 3 permitted codes (one previous code, the current
code, the next code) to 17 permitted codes (the 8 previous codes, the current
code, and the 8 next codes). This will permit for a time skew of up to 4 minutes
between client and server.
Do you want to do so? (y/n) n

If the computer that you are logging into isn't hardened against brute-force
login attempts, you can enable rate-limiting for the authentication module.
By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting? (y/n) y

Jetzt ist die Konfiguration abgeschlossen. Der Zeitpunkt ist gekommen in der wir die zu sichernden Dienste konfigurieren.
Hier als Beispiel ssh

Öffnen der Datei /etc/pam.d/common-auth und das PAM Modul aktivieren.
Dazu diese Zeilen einfügen in der config einfügen.
# google mfa
auth required pam_google_authenticator.so nullok
Nachdem alle User die Konfiguration durchlaufen haben muss nullok aus der Zeile entfernt werden. Das sorgt dafür das nur noch User mit MFA eine Authentifizierung möglich ist.


Und jetzt noch die Datei /etc/ssh/sshd_config anpassen.
KbdInteractiveAuthentication yes
UsePAM yes
Jetzt noch den sshd Service neu starten und wir müssen uns mit einem MFA Token anmelden.
systemctl restart sshd


Noch sicherer wäre das ganze wenn man das Login auf pubkey umstellt. Hierzu muss VOR der Einrichtung ein Pubkey erzeugt und hinzugefügt werden. Dann kann man in der Datei /etc/pam.d/sshd den Part @include common-auth auskommentieren (# davor) und danach die Zeilen einfügen.
# google mfa
auth required pam_google_authenticator.so
Hintergrund ist das wir hier das common-auth modul deaktivieren , dieses ist für die Passwort Anmeldung zuständig. Wechseln wir auf das Pubkey Verfahren wird dieses Modul nicht mehr angezogen , was die Einstellung die oben erwähnt wurde deaktivert.

Da wir die Einstellungen im common-auth Modul setzen sind alle Dienste davon betroffen die dieses verwenden. d.h. jetzt sind alle Dienste über MFA abgesichert die dieses PAM Modul verwenden.

AWS : Cloudwatch Agent & collectd

Cloudwatch liefert ja schon von Haus aus viele Metriken will man jedoch "tiefer" ins System schauen empfiehlt es sich einen anderen Agent zu verwenden (zusätzlich oder den Cloudwatch Agent nur als Bridge)

Ich habe mich für den Weg entschlossen die Metriken von collectd üder den cloudwatch agent in Cloudwatch zu reporten. Dort können dann wie gewohnt Alarme definiert werden.

Als erstes braucht man einen IAM User (Programmatic access) und eine IAM Role die das Recht besitzen in Cloudwatch zu reporten.
IAM UserIAM Role

Die Role "ServerMonitoring" weißt man dann den EC2 Instanzen zu die in das Monitoring aufgenommen werden müssen.

attach iam role
attach iam role to instance

Jetzt müssen die benötigten Packete heruntergeladen & installiert werden. Mein Beispiel ist für Debian 8 und Debian 9 geeignet. Bei anderen Linux Systemen ist der Ablauf etwas anders. Der Cloudwatch Agent kann auf der Seite ( Install Cloudwatch Agent ) für andere Systeme heruntergeladen werden. Das Github Repo für die collectd-cloudwatch Bridge ist hier GitHub - awslabs
mkdir -p ~/downloads
cd ~/downloads
wget https://s3.amazonaws.com/amazoncloudwatch-agent/debian/amd64/latest/amazon-cloudwatch-agent.deb
wget https://github.com/awslabs/collectd-cloudwatch/archive/master.zip
dpkg -i amazon-cloudwatch-agent.deb
unzip master.zip
Unter Debian muss man das setup.py script leicht abändern ;-)
cd collectd-cloudwatch-master/src/
vi setup.py
dort suchen nach
DISTRIBUTION_TO_INSTALLER = {
    "Ubuntu": APT_INSTALL_COMMAND,
    "Red Hat Enterprise Linux Server": YUM_INSTALL_COMMAND,
    "Amazon Linux AMI": YUM_INSTALL_COMMAND,
    "Amazon Linux": YUM_INSTALL_COMMAND,
    "CentOS Linux": YUM_INSTALL_COMMAND,
}
ersetze mit
DISTRIBUTION_TO_INSTALLER = {
    "Debian GNU": APT_INSTALL_COMMAND,
    "Ubuntu": APT_INSTALL_COMMAND,
    "Red Hat Enterprise Linux Server": YUM_INSTALL_COMMAND,
    "Amazon Linux AMI": YUM_INSTALL_COMMAND,
    "Amazon Linux": YUM_INSTALL_COMMAND,
    "CentOS Linux": YUM_INSTALL_COMMAND,
}
Dann muss collectd installiert werden und die aws cli konfiguriert werden
apt install collectd
aws configure (AWS Key & Security Key von monitoring user angeben)
jetzt installieren wir noch die bridge
chmod u+x ~/downloads/collectd-cloudwatch-master/src/setup.py 
~/downloads/collectd-cloudwatch-master/src/setup.py 
jetzt wird das alles noch konfiguriert
/opt/aws/amazon-cloudwatch-agent/amazon-cloudwatch-agent-config-wizard
vi /etc/collectd/collectd.conf
/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -c file:/opt/aws/amazon-cloudwatch-agent/bin/config.json -s
dann alles neu starten
systemctl restart amazon-cloudwatch-agent
systemctl restart collectd
es gibt im plugin cloudwatch-collectd zwei Dateien die jetzt steuern was bei cloudwatch ankommt und was nicht. In der Datei /opt/collectd-plugins/cloudwatch/config/blocked_metrics sind alle aktuell erkannten Metriken gelistet. Möchte man jetzt z.B. das der Speicher (memory) an cloudwatch reportet wird so muss dieser in der Datei whitelist.conf eingetragen werden. z.B. für Speicher (memory--.*) ob eure Werte ankommen oder nicht seht ihr nach einer Tasse Kaffee oder Tee hier in cloudwatch AWS Collectd Metriken
die cloudwatch metriken liefern normalerweise
df-root-percent_bytes-used
memory--percent-used
swap--percent-used
cpu--percent-active
Das Ergebnis seht ihr hier :AWS_MEMORY Cloudwatch collectd
für das debugen sollte dieses Log verwendert werden.
less /var/log/collectd.log

Quellen :
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Agent-on-first-instance.html
https://github.com/awslabs/collectd-cloudwatch
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-custom-metrics-collectd.html
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create-cloudwatch-agent-configuration-file-wizard.html

Nextcloud 14 : mod_security2 Id's

Meine Nextcloud 14 hat nach dem Update nicht richtig funktioniert. Filetree hat sich nich aufgebaut caldav hat nicht mehr funktioniert. Nachdem ich in der VHost folgenden Eintrag hinzugefügt habe hat wieder alles funktioniert.
<IfModule mod_security2.c>
    # Nextcloud
    SecRuleRemoveById 949110 911100 920420
</IfModule>

Ansible : Debian updaten

Hier ein Beispiel für ein Playbook das ein Update auf einem Debian System ausführt.
    - name: Update Repositories and update Distribution to the latest Version
      apt:
        update_cache: yes
        cache_valid_time: 21600
        upgrade: dist
        dpkg_options: 'force-confold,force-confdef'
      register: update_apt
      tags: update_apt

Check_MK monitoren der haproxy Backends

Kleines lokales Plugin für check_mk um die HAProxy Backends zu monitoren.

das Skript muss unter /usr/lib/check_mk_agent/local angelegt werden.
touch /usr/lib/check_mk_agent/local/haproxy-local.sh
Dort dann den nachfolgenden Code reinkopieren und Konfiguration anpassen.
#!/bin/bash
#
# checks haproxy
#

_awk_bin=$(which awk)
_status_url="http://localhost:9090/haproxy/"
_server_name="ha-cap-"
a=0

# $(curl -s ${_status_url}\;csv | grep "^${_server_name}" | grep -vE "(FRONTEND|BACKEND)")

for line in $(curl -s ${_status_url}\;csv | grep "^${_server_name}" | grep -vE "(FRONTEND|BACKEND)"); do
        _name=$(echo $line | ${_awk_bin} -F',' '{ print $1; }' )
        _host=$(echo $line | ${_awk_bin} -F',' '{ print $2; }' )
        _stat=$(echo $line | ${_awk_bin} -F',' '{ print $18; }')
        STATUSTXT="${_name}  ${_host}  ${_stat}"
        if [ ${_stat} == "UP" ]; then
                _check_response="0"
        else
                _check_response="2"
        fi
        if [ ${a} -lt 10 ]; then
                echo "${_check_response} BEHIND-HAPROXY-0${a} - ${STATUSTXT}"
        else
                echo "${_check_response} BEHIND-HAPROXY-${a} - ${STATUSTXT}"
        fi
        a=$((a+1))
done

Ergebnis sieht dann so aus
check_mk + haproxy
check_mk + haproxy

Natürlich muss auch der haproxy so konfiguriert sein das er die Statusseite ausliefert. Hier Auszug aus der haproxy.cfg
listen status
    bind *:9090
    mode http
    stats enable
    stats uri /haproxy
    acl localhost  src  127.0.0.1
    acl stats      path_beg  /haproxy
    http-request allow if stats localhost
    http-request deny  if stats !localhost
“Das einzig sichere System müsste ausgeschaltet, in einem versiegelten und von Stahlbeton ummantelten Raum und von bewaffneten Schutztruppen umstellt sein.”
Gene Spafford (Sicherheitsexperte)