Welche Listen gibt es?

Reine Text-Listen solcher IP-Adressen (um diese elektronisch weiterzuverarbeiten) findest du auf den Seiten https://www.projecthoneypot.org, https://www.maxmind.com, https://danger.rulez.sk, https://www.spamhaus.org, https://lists.blocklist.de, etc.

Via http://ipverse.net/ipblocks/data/countries/XX.zone kannst du sogar länderbasiert IP-Adressen blockieren. XX steht hierbei für den 2-digit-Countrycode.

Beim Nutzen solcher Listen gilt im Übrigen dasselbe wie beim generellen Anlegen automatisierter Firewall-Blockierungen: Achte immer darauf, dass du nicht dein eigenes Interface und auch nicht deine eigene IP-Adresse blockierst. Diese solltest Du whitelisten!

Wie funktioniert ipset?

Das einzelne Blockieren von IP-Adressen erzeugt natürlich einen entsprechenden Aufwand für iptables – zumindest dann, wenn ganze IP-Adressensammlungen im fünf- oder sechsstelligen Bereich blockiert werden sollen. Und hier kommt ipset ins Spiel – eine Netfilter-Erweiterung. Mit ipset kannst du diese ganzen Listen in ein Set laden und diese mit nur einer einzigen iptables-Regel blockieren. ipset installierst Du mit dem Paketmanager deines Linux-Systems (apt-get, pacman, etc.).

Trick77/ipset-blacklist

Du kannst solche Listen sehr angenehm über ein bereits fertiges Script auf deinem Server organisieren: https://github.com/trick77/ipset-blacklist

In der Readme.md-Datei ist die schnelle Installation in fünf Schritten und Ausführung des Scripts beschrieben. Wichtig ist dabei auch, dass Du den beschriebenen Cronjob einrichtest und diesen einmal täglich ausführst. Auf diese Weise werden die IP-Listen aktualisiert. Denn täglich kommen natürlich neue IP-Adressen hinzu, bzw. werden auch IP-Adressen wieder freigegeben. Nach dem Anpassen der Datei /etc/ipset-blacklist/ipset-blacklist.conf an die eigenen Bedürfnisse, werden die IP-Adresslisten wie von dir ausgewählt automatisiert hinzugefügt.

Manuelles hinufügen von IP-Adressen

Du kannst desweiteren manuell IP-Adressen kurzfristig via ipset (ipset add [BLACKLISTNAME] [IP-ADRESSE]) zu deiner blacklist hinzufügen, oder langfristig die Datei /etc/ipset-blacklist/ip-blacklist-custom.list pflegen (nachdem diese in der Konfigurationsdatei aktiviert wurde).

Aussicht: Automatisiertes Melden von IP-Adressen via Fail2ban

Projekte wie beispielsweise https://www.badips.com leben davon, dass Angriffsversuche gemeldet werden. Erreicht eine IP-Adresse eine bestimmte Menge an Meldungen über Angriffsversuche, landet diese auf der Liste, die selbst wieder zum Blockieren genutzt werden kann. Wie Du dies ebenfalls automatisiert und beispielsweise via Fail2Ban erledigen kannst, schreibe ich in einem der kommenden Beiträge.

The post IP-Blocklisten mit ipset first appeared on NET73.

Der Vorteil von Ansible? Man benötigt keine Client-Agents oder ähnliche Software – eine funktionierende SSH-Verbindung zum Zielrechner ist ausreichend. Ansible ist hierbei auch der Zustand des Zielrechners egal. Wenn z.B. das Paket „apache2“ via APT auf dem debian-basierten Zielrechner installiert werden soll, wird geprüft, ob auf dem Zielrechner bereits apache2 installiert ist. Ist dies der Fall, wird von Ansible nichts weiter unternommen. Ist dies nicht der Fall, installiert Ansible das Paket.
Was ebenfalls ziemlich schick ist: Es wird auch keine Server-Node benötigt. Ansible kann von jedem SSH-fähigen Client oder Server ausgeführt werden. I.d.R. geht man dabei so vor, dass die eigenen Configs, bzw. Aufgaben (bei Ansible „Playbooks“ genannt) versioniert werden (Github, Gitlab, o.ä.) und bei Bedarf versioniert erweitert und angepasst werden können. 12 Server und auf allen soll „htop“ nachinstalliert werden? Eine Zeile in Ansible und die Sache ist geritzt. 

Ein kleines Beispiel einer möglichen Ansible-Anwendung ist das Aktualisieren sämtlicher Server-/Rechner-Nodes, auf welche man generell Zugriff via SSH hat. Im Folgenden als kurze Orientierung das Playbook („in etwa“ YAML-Format):

dist-upgrade.yml

Die Datei „dist-upgrade.yml“ ist das sog. Playbook des Ansible-Auftrags. In dieser Datei wird beschrieben, was auf welchen Hosts ausgeführt werden soll. Grundsätzlich orientiert sich ein Ansible-Playbook an der YAML-Syntax. Tatsächlich findet man allerdings verschiedene Formate und Markups in einer solchen Datei. Neben reinem YAML kommen zusätzlich eigene sog. „Custom Keys“, Python-Code und stellenweise Jinja2-Syntax vor.

---
- hosts:
    all 
  become: true
  gather_facts: no
  vars:
    verbose: true 
    log_dir: "log/dist-upgrade/{{ inventory_hostname }}"
  pre_tasks:
    - block:
        - setup:
      rescue:
        - name: "Install required python-minimal package"
          raw: "apt-get update && apt-get install -y --force-yes python-apt python-minimal"
        - setup:
  tasks:
    - name: Update packages
      apt:
        update_cache: yes
        upgrade: dist
        autoremove: yes
      register: output

    - name: Check changes
      set_fact:
        updated: true
      when: not output.stdout is search("0 upgraded, 0 newly installed")

    - name: Display changes
      debug:
        msg: "{{ output.stdout_lines }}"
      when: verbose or updated is defined

    - block:
      - name: "Create log directory"
        become: no
        file:
          path: "{{ log_dir }}"
          state: directory
        changed_when: false

      - name: "Write changes to logfile"
        become: no
        copy:
          content: "{{ output.stdout }}"
          dest: "{{ log_dir }}/dist-upgrade_{{ ansible_date_time.iso8601 }}.log"
        changed_when: false

      when: updated is defined
      connection: local

ansible.cfg

In der ansible.cfg-Datei werden Einstellungen für Ansible gespeichert. Wichtig: Ansible nutzt eine solche Datei, wenn der Befehl im selben Verzeichnis ausgeführt werden soll. Befindet sich keine ansible.cfg-Datei im aktuellen Verzeichnis, greift Ansible auf die globale Einstellungsdatei unter [cci lang=“bash“]/etc/ansible/ansible.cfg[/cci] zurück. Dies ist der Speicherort unter Arch Linux bei Installation via Pacman.

[defaults]
inventory = ./hosts

Aufgerufen wird das Playbook – also die YAML-Datei über den Befehl [cci]ansible-playbook dist-upgrade.yml [/cci]. Im Anschluss wird jeder Server aus der hosts-Datei abgearbeitet und entsprechende Rückmeldungen – falls es welche gibt – in einer Log-Datei pro Server und Durchlauf festgehalten.

The post Ansible: Server-Updater first appeared on NET73.