☰

IPtables effizient verwalten mit Saltstack

tag-icon • tag-icon saltstack
IPtables effizient verwalten mit Saltstack

Ich versuche, mit SaltStack eine flexible iptables-Verwaltungslösung zu konfigurieren, aber ich finde es schwieriger als gedacht.

Meine Hauptanforderung: Ich möchte einen Pillar haben, in dem ich eine Liste von IPs führe, die für den SSH-Zugriff auf alle Minions auf die Whitelist gesetzt werden sollen. Diese IP-Liste ändert sich natürlich von Zeit zu Zeit: Einige IPs werden hinzugefügt, andere IPs werden entfernt. Das Problem, mit dem ich konfrontiert bin, betrifft die entfernten IPs – wenn ich sie aus der Pillar-Datei entferne, entfernt SaltStack die eigentliche Whitelist nicht von den Minions.

Die einzige Problemumgehung, die ich finden konnte, bestand darin, einen neuen Schlüssel mit dem Namen „removed-ips“ zu erstellen und ihn dort hinzuzufügen, wann immer ich eine IP entfernen möchte. Die zweite For-Schleife entfernt sie dann. Natürlich ist dies eine wirklich üble Problemumgehung. Gibt es eine bessere Möglichkeit, dies zu tun?

/srv/pillar/iptables-default.sls:

iptables-default:
  whitelisted-ips:
    - '55.55.55.55'
    - '66.66.66.66'
    - '77.77.77.77'
  removed-ips:
    - '88.88.88.88'

/srv/salt/iptables-default.sls:

{% for ip in salt['pillar.get']('iptables-default:whitelisted-ips') %}
Whitelist OSF IP {{ip}} for SSH access:
  iptables.append:
    - table: filter
    - family: ipv4
    - chain: INPUT
    - jump: ACCEPT
    - match: state
    - connstate: NEW
    - source: '{{ ip }}'
    - dport: 22
    - proto: tcp
    - save: True
{% endfor %}

{% for ip in salt['pillar.get']('iptables-default:removed-ips') %}
Remove old IPs that are not needed anymore:
  iptables.delete:
    - table: filter
    - family: ipv4
    - chain: INPUT
    - jump: ACCEPT
    - match: state
    - connstate: NEW
    - source: {{ ip }}
    - dport: 22
    - proto: tcp
    - save: True
{% endfor %}

Antwort1

Ich habe ein paar Stunden damit verbracht, herauszufinden, wie ich die verschiedenen iptables-Einstellungen am besten mit Salt verwalten kann. Die beste Lösung scheint eine Kombination aus

  1. flache iptables-Konfigurationsdateien (als Jinja-Vorlagen)
  2. Lassen Sie Salt einen Iptables-Flush und eine Wiederherstellung nur durchführen, wenn sich die Flatfile ändert.

so habe ich es in meiner Umgebung und es funktioniert sehr gut. Ich habe versucht, Salt Iptables-Zustände zu verwenden, aber das wird sehr umständlich und unhandlich und man muss es iptables.flushbei jedem Highstate-Lauf zwangsweise tun,

Nachfolgend finden Sie einen einfacheren und handlicheren Ansatz, der die Verwendung von Säulen vollständig vermeidet.

Erstellen Sie für jeden Host eine Flatfile mit {{ grains.id }}.j2 als Layout.

cat /srv/salt/state/iptables/files/nycweb1.j2


##############################################################
## This file is managed by SALTSTACK - Do not modify manually
##############################################################

*filter
:INPUT ACCEPT
:FORWARD ACCEPT
:OUTPUT ACCEPT

## Allow all loopback (lo0) traffic
-A INPUT -i lo -j ACCEPT

## Drop all traffic to 127/8 that doesn't use lo0
-A INPUT ! -i lo -d 127.0.0.0/8 -j DROP

## Accept inbound traffic for already established connections.
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

## Effectively allow all outbound traffic.
-A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

## Allow ping
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT

## Blacklist
-A INPUT -s 0.0.0.0/32 -p tcp -m tcp --dport 22 -j REJECT --reject-with icmp-port-unreachable

## Whitelist     
-A INPUT -s 121.236.129.235/32 -p tcp -m tcp --dport 22 -j ACCEPT {# NY office pub #}
-A INPUT -s 192.168.10.0/24 -p tcp -m tcp --dport 22 -j ACCEPT {# NY office priv #}


COMMIT


*nat
:PREROUTING ACCEPT
:INPUT ACCEPT
:OUTPUT ACCEPT
:POSTROUTING ACCEPT
-A PREROUTING -p tcp -m tcp --dport 27015 -j DNAT --to-destination 192.168.38.20
-A OUTPUT -p tcp -m addrtype --src-type LOCAL --dst-type LOCAL -m tcp --dport 1266 -j DNAT --to-destination 169.254.1.1:443
-A POSTROUTING -s 192.168.1.2/32 -d 10.3.4.65/32 -p tcp -m tcp --dport 48854 -j MASQUERADE
-A POSTROUTING -d 10.0.2.15/24 -p tcp -m tcp --dport 27045 -j SNAT --to-source 192.168.99.11 {# description #}

COMMIT
{# EOF #}

eine Statusdatei erstellen,

cat /srv/salt/state/iptables/init.sls

# STATE - IPTABLES

{% set iptables_file = '/etc/sysconfig/iptables' %}

iptables_pkg:
    pkg.installed:
        - name: iptables

{{ iptables_file }}:
    file.managed:
        - user: root
        - group: root
        - mode: 644
        - source: salt://{{ slspath }}/files/{{ grains.id }}.j2
        - template: jinja

flush_tables:
    iptables.flush:
        - table: filter
        - family: ipv4
        - onchanges:
            - file: "{{ iptables_file }}"

restore_tables: 
    cmd.run:
        - name: "/usr/sbin/iptables-restore < {{ iptables_file }}"
        - onchanges:
            - file: "{{ iptables_file }}"

das ist es, wenn Sie Highstate auf Ihren Zielen ausführen, führen sie nur dann Flush+Restore aus, wenn die Flatfile geändert wird. Ihre Konfiguration ist auch im nativen iptables-Format, nicht im Pillar-Format

Jetzt den Status anwenden oder zu Ihrem Highstate hinzufügen

salt nycweb01 state.sls iptables

Antwort2

Für solche Zwecke führen wir eine Liste mit IP-Adressen, die von iptables verwendet werden können. Wir erstellen eine Vorlage für die Konfigurationsdatei „ipset“ und verwenden iptables-Regeln, die diese für Zulassungs- oder Sperrlisten referenzieren. Ein ipset zahlt sich bei großen Sets aus, und wenn man sie auf diese Weise verwaltet, wird das Problem des „Entfernens einer Adresse“ eliminiert; die Sets werden bei jeder Änderung vollständig neu geladen.

Wir verwalten zentral Netzwerke mit Tausenden von Servern mit strengen Mitgliedschafts- und Zugriffsanforderungen. Daher ist die Verwendung von Salt und einer Jinja-Vorlage zum Rendern von /etc/sysconfig/ipset für uns sinnvoll.

verwandte Informationen