Žijeme v bezdrátové budoucnosti, už to není taková sranda jako tehdy. Předtím, což bylo ještě před budoucností, hyperkonvergencí a všudypřítomnou globální apokalypsou, se tu dlouho objevovaly dost nadčasové myšlenky pokročilého enterprise přístupu pomocí jasně daných opensource nástrojů, tedy konkrétně využití Samby a další omáčky okolo v co nejplnohodnotnější implementaci Active Directory řadiče domény pro ryze heterogenní prostředí, ať už jím bude cokoliv – tedy jednak zachování kompatibility s konfigurací nějakých Windows strojů a Windows sítí, ale zároveň i dost obyčejného, ale spolehlivého centrálního LDAP místa pro všechny účty, navíc s velmi snadnou implementací WPA-Enterprise díky FreeRADIUSu, případně přístupu k PAM přes NSS. Sestavit na koleně se dá nakonec všechno, neexistují žádné limity.
No ale každopádně. Nad každou takovou myšlenkou vždycky straší vize udržitelnosti i do vzdálené a ještě vzdálenější budoucnosti, ať už bude taková spočívat v migraci na jiné a efektivní platformy, nebo prostě v co nejkratším vytvoření a případném ostrém nasazení krizového plánu pro okamžik, kdy dotační projekty vyprší a bude najednou potřeba ze současného vendor lock-inu znovu přejít na důvěryhodné systémy bez zásahu státu a jeho zkorumpovaných institucí, a to lusknutím prstu do dvou dnů. Jistou odpovědí jsou distribuční balíčky, ideálně ty stabilní. Balíčky v distrech jsou pochopitelně předpřipravené binárky se strukturami a propojeními na míru šitými celému systému, obvykle nějakému GNU s Linuxem. Tím může být třeba mission-critical RHEL, který je teď nějak free nebo co, nebo jakákoliv jiná, ale tradičně spolehlivá distribuce. Alternativní a prakticky o dost dobrodružnější cestou by pak bylo použít BSD systémy a všechno si automatizovaně in-house kompilovat na míru z portů, ale v takovém případě by se asi vyplatilo služby škálovat na víc jednotlivých míst. Nespornou výhodou by ale byla kontrola nad kompilační konfigurací jednotlivých programů od prefixů po specifickou podporu jiných knihoven a funkcí. Ono totiž ještě donedávna platilo, že svobodné binárky nešlo pro ADčka úplně prakticky použít, protože byly vázané buď na nějaké redistribuční licence, nebo prostě neexistovala jejich non-free varianta. Teď je situace po dlouhých a dlouhých letech možná konečně trochu jiná.
Použít Debian GNU/Linux je pro mě osobně docela snadná volba, protože je tu fakt dlouho a prostě funguje, dokonce nechat ho i dlouhodobě rolovat v kanálu testing s automatickými aktualizacemi není zase taková tragédie, jak by se mohlo zdát. Obyčejně se něco rozbije v poměrně krátkém časovém okně hned před nebo po uzávěrce příštího vydání, ale případná oprava nezabere zase tolik času, i když, ironií osudu, migrace konfigurace z freeradius 2 na freeradius 3, zas taková pohoda nebyla, na to bylo potřeba se podívat, tedy sednout si k tomu a pořádně se na to podívat. Ale kromě toho tím byly postižené snad jen databáze, takže suma sumárum, za deset let běhu testing kanálu byly snad jenom tři závažné havárie, vyřešené v horizontu nejvýše jednoho dne a půl – tedy výrazně méně než v případě změn nebo oprav hardwaru.
Tudíž dneska, oč tu půjde? Zvolna navážeme na kouzelný svět Active Directory a pokusíme co nejjednodušším a extrémně rychlým způsobem postavit nový doménový řadič DC2 s podporou všech dalších služeb, tedy AAA a zónovým serverem, o DHCP a certifikační autoritě bych zkusil mluvit zas někdy později. Tento nový řadič připojíme do existující sítě EIDA.LAN v nějaké ukázkové 10.5.5.0/24, 2001:ab:cd:ef::/64 s hypervizorem a primárním slave DNS .100, ::a, jako .102, ::dc2 paralelně k DC1 .101, ::dc1 a domácím AP/bránou .1, ::1. Jakmile to bude, zkusíme ověřit replikaci a následně DC2 nastavit jako primární a DC1 zcela odpojit a zahodit. To už zní jako plán. Ještě by to mohlo být na nějakém aarch64, ale ukázku po ostrém dni zkoušení v KVM píšu ve vmWare, tak snad to ničemu nevadí.
Současný Debian testing se jmenuje Bullseye a má tu vlastnost, že je v něm Samba 4.13, BIND 9.16, NTP 4.2.8, FreeRADIUS 3.0, Python 3.9, OpenSSH 8.4, systemd 247 a jádro 5.10.0. Výše uvedené obrázky ukazují jeho instalaci přímo z určeného netinst média, nicméně zrovna u té Samby se ukázalo několik poměrně nepříjemných chyb a zpětně vzato by asi nejpohodlnější postup mohl být nainstalovat nejdříve Debian jako stable i s balíky, pokusit se ho připojit k doméně a až následně povýšit se vším všudy na testing a aktualizovat, ale to jsou prostě věci, které těžko jdou ovlivnit bez předchozích zkušeností.
Celý systém – řadič – je tu uvažovaný jako virtuální strojek pro malou síť s externím DHCP, takže dostane opravdové minimum zdrojů. Jedno CPU jádro, 768 MB RAM a disk rozdělený na 1G /boot pro automaticky stahovaná jádra, případný 2GB swap a vlastní root oddíl na systému ext4 s již předpřipraveným atributem user_xattr, který instalátor přímo nabízí. Nutno dodat, že pro běh řadiče je nutná přímá podpora ACL a dále Samba sama doporučuje na žurnálovaných systémech ještě nastavit barrier=1 pro zaručení správného pořadí zápisu tdb transakcí při výpadku… proudu nebo disku, ono těžko říct, jak špatně by se něco takového vlastně mohlo projevit ve virtuálu, řekněme pod KVM/qcow2, který stejně nakonec poběží na hypervizoru zálohovaném UPSkou.
UUID=XYZ01 / ext4 acl,user_xattr,barrier=1,errors=remount-ro 0 1 UUID=XYZ02 /boot ext4 defaults 0 2 UUID=XYZ03 none swap sw 0 0
Hnedka po spuštění bych to viděl na okamžitou instalaci všeho co bude potřeba. Pointa spočívá v tom, že toho vlastně fakt není moc. Důležité je pro správný běh Samby v režimu AD DC nezapomenout hlavně na manuální instalaci balíků winbind (není kupodivu závilostí balíku samba) a dnsutils, na což se často zapomíná, který je nezbytný pro manipulaci s DLZ.
root@dc2:/home/eida# apt install acl samba winbind ntp krb5-user bind9 dnsutils freeradius netfilter-persistent
Co mi přijde jako opravdu vtipné, že vlastně výchozí instalace Debianu, pokud zvolíme heslo roota a dále ještě extra běžného uživatele, neobsahuje sudo, takže to pak dost lidí neumí vlastně používat. Ono přepnutí se – su – sice poskytne rootovský účet, ale jaksi v cestách pak budou chybět věci jako /usr/sbin/, což znemožní třeba snadný restart a podobné vychytávky. Způsob, jak zprovoznit sudo, je ale poměrně přímočarý – nahodí se balík a požadovaný uživatel se přidá do nové skupiny sudo, pak se musí odhlásit, je-li přihlášený, aby to vešlo v platnost. Ono to sudo je pak stejně pořeba na klientech, viz minule, kde chceme, aby NSSkou vylistovaný uživatel z AD měl nějaká práva.
root@dc2:/home/eida# apt install sudo Načítají se seznamy balíků… Hotovo Vytváří se strom závislostí… Hotovo Načítají se stavové informace… Hotovo Následující NOVÉ balíky budou nainstalovány: sudo 0 aktualizováno, 1 nově instalováno, 0 k odstranění a 0 neaktualizováno. Nutno stáhnout 1 057 kB archivů. Po této operaci bude na disku použito dalších 4 695 kB. Stahuje se:1 http://deb.debian.org/debian bullseye/main amd64 sudo amd64 1.9.5p2-2 [1 057 kB] Staženo 1 057 kB za 0s (4 007 kB/s) Vybírá se dosud nevybraný balík sudo. (Načítá se databáze … nyní je nainstalováno 33242 souborů a adresářů.) Připravuje se nahrazení …/sudo_1.9.5p2-2_amd64.deb … Rozbaluje se sudo (1.9.5p2-2) … Nastavuje se balík sudo (1.9.5p2-2) … Zpracovávají se spouštěče pro balík man-db (2.9.4-2) … root@dc2:/home/eida# /usr/sbin/usermod -a -G sudo eida
Další úskalí Debianu je z nějakého důvodu poměrně problematický způsob nastavení statických adres, zejména pak IPv6. Nemluvě o statických adresách na mostech, ale tohle není ten případ. Během instalace se totiž nenabídne snadný dialog statické konfigurace IPv6, přestože může běžet, pokud je v síti k dispozici něco adresy automaticky přidělující. Na rozdíl od přímočaré statické konfigurace IPv4 potřebuje šestka po nahození rozhraní trochu pošťouchnout přidáním trasy přes adresu brány na daném rozhraní, tady tedy ens3.
root@dc2:/home/eida# cat /etc/network/interfaces source /etc/network/interfaces.d/* auto lo iface lo inet loopback # IPv4 allow-hotplug ens3 iface ens3 inet static address 10.5.5.102/24 gateway 10.5.5.1 dns-nameservers 10.5.5.100 dns-search eida.lan # IPv6 iface ens3 inet6 static address 2001:ab:cd:df::dc2 netmask 64 gateway 2001:ab:cd:df::1 dns-nameservers 2001:ab:cd:df::a up /sbin/ip -6 route add default via 2001:ab:cd:df::1 dev ens3 onlink || true root@dc2:/home/eida# cat /etc/resolv.conf domain eida.lan search eida.lan nameserver 10.5.5.100 nameserver 2001:ab:cd:ef::a
Pokud jede síť, už by to chtělo přistupovat pouze vzdáleně a negraficky, tedy rozjet si trochu přizpůsobenější SSH. V první řadě doporučuji smazat všechny klíče krom Ed25519 a ze zamýšleného klienta (v případě virtuálu by to ale nejlépe mohl být stejně jen hypervizor) si hnedka zkopírovat klíček pomocí ssh-copy-id a pak vypnout veškeré heslování. Je zajímavé, že hodně BSD variant má přihlášení s heslem prostě zakázané už v základu, ale tady ta linuxová distra trochu zaostávají.
root@dc2:/home/eida# rm /etc/ssh/host_key_rsa_key* root@dc2:/home/eida# rm /etc/ssh/host_key_ecdsa_key* root@dc2:/home/eida# cat /etc/ssh/sshd_config | grep -v ^# | grep -v ^$ Include /etc/ssh/sshd_config.d/*.conf HostKey /etc/ssh/ssh_host_ed25519_key PermitRootLogin no PubkeyAuthentication yes PasswordAuthentication no PermitEmptyPasswords no ChallengeResponseAuthentication no UsePAM yes AllowTcpForwarding no X11Forwarding no PrintMotd no AcceptEnv LANG LC_* Subsystem sftp /usr/lib/openssh/sftp-server root@dc2:/home/eida# /etc/init.d/ssh restart
Balíček Samby v tuhle chvíli není nastavený pro běh v režimu AD DC, tedy běží spíše samostatné programy, než aby to byl jeden velký démon ve stylu prostého spuštění příkazu samba instalovaného přímo ze zdrojů. Tady musí dojít trochu na magii se systemd, ale prostě asi jako u každého systému s nějakými rc skripty a initem a launchd a cokoliv, zkrátka samostatné služby se zakáží a povolí se ta jedna všemocná.
root@dc2:/home/eida# systemctl stop smbd nmbd winbind root@dc2:/home/eida# systemctl disable smbd nmbd winbind Synchronizing state of smbd.service with SysV service script with /lib/systemd/systemd-sysv-install. Executing: /lib/systemd/systemd-sysv-install disable smbd Synchronizing state of nmbd.service with SysV service script with /lib/systemd/systemd-sysv-install. Executing: /lib/systemd/systemd-sysv-install disable nmbd Synchronizing state of nmbd.service with SysV service script with /lib/systemd/systemd-sysv-install. Executing: /lib/systemd/systemd-sysv-install disable winbind Removed /etc/systemd/system/multi-user.target.wants/nmbd.service. Removed /etc/systemd/system/multi-user.target.wants/smbd.service. Removed /etc/systemd/system/multi-user.target.wants/winbind.service. root@dc2:/home/eida# systemctl unmask samba-ad-dc Removed /etc/systemd/system/samba-ad-dc.service. root@dc2:/home/eida# systemctl enable samba-ad-dc Synchronizing state of samba-ad-dc.service with SysV service script with /lib/systemd/systemd-sysv-install. Executing: /lib/systemd/systemd-sysv-install enable samba-ad-dc Created symlink /etc/systemd/system/multi-user.target.wants/samba-ad-dc.service → /lib/systemd/system/samba-ad-dc.service.
Pokud to je, tohle je dobrý okamžik na zhruba doslovný přepis konfigurace Samby z DC1, jen se prostě přehodí jméno na DC2, žádná velká věda.
[global]
netbios name = DC2
realm = EIDA.LAN
server role = active directory domain controller
server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc, drepl, winbindd, ntp_signd, kcc, dnsupdate
workgroup = EIDA
idmap_ldb:use rfc2307 = yes
username map = /etc/samba/user.map
ntlm auth = mschapv2-and-ntlmv2-only
allow dns updates = secure
dsdb:schema update allowed = true
[netlogon]
path = /var/lib/samba/sysvol/eida.lan/scripts
read only = No
[sysvol]
path = /var/lib/samba/sysvol
read only = No
Věda začíná tady. Nový DC2 je potřeba připojit ke stávající doméně EIDA.LAN, která by měla být vidět na síti, a to jako sekundární řadič. Rovnou tady volím DNS backend jako DLZ pro BIND. Pokud se všechno povedlo a zvolený účet (-U eida) má práva domain admin, po zadání hesla by se měl řadič DC2 bez problémů připojit. Vytvoří se mu taky v /var/lib/samba už nějaká specifická konfigurace, ze které je dobré vzít si co nejdřív nastavení pro Kerberos. No a vlastně pokud není moc rozdílů mezi verzemi v DC1 a DC2, což při prvním pokusu o přenos z 4.13 na 4.9 bylo, měla by téměř okamžitě začít replikace domény mezi oběma řadiči.
root@dc2:/home/eida# samba-tool domain join eida.lan DC -U eida --dns-backend=BIND9_DLZ
INFO 2021-03-06 23:24:56,464 pid:723 /usr/lib/python3/dist-packages/samba/join.py #107: Finding a writeable DC for domain 'eida.lan'
INFO 2021-03-06 23:24:56,479 pid:723 /usr/lib/python3/dist-packages/samba/join.py #109: Found DC dc1.eida.lan
Password for [EIDA\eida]:
...
INFO 2021-03-06 23:25:18,637 pid:723 /usr/lib/python3/dist-packages/samba/join.py #1559: Joined domain EIDA (SID S-1-5-21-X-Y-Z) as a DC
root@dc2:/home/eida# cp /var/lib/samba/private/krb5.conf /etc
root@dc2:/home/eida# chmod 0644 /etc/krb5.conf
root@dc2:/home/eida# cat /etc/krb5.conf
[libdefaults]
default_realm = EIDA.LAN
dns_lookup_realm = false
dns_lookup_kdc = true
[realms]
EIDA.LAN = {
default_domain = eida.lan
}
[domain_realm]
DC2 = EIDA.LAN
root@dc2:/home/eida# samba-tool drs showrepl
Default-First-Site-Name\DC2
DSA Options: 0x00000001
DSA object GUID: f9e268d7-X-Y-Z-3787aad77574
DSA invocationId: b1c9ce40-X-Y-Z-4a3d8fd9033d
==== INBOUND NEIGHBORS ====
CN=Configuration,DC=eida,DC=lan
Default-First-Site-Name\DC1 via RPC
DSA object GUID: d2bd2987-A-B-C-5ba7691aadef
Last attempt @ Sat Mar 6 23:39:36 2021 CET was successful
0 consecutive failure(s).
Last success @ Sat Mar 6 23:39:36 2021 CET
...
==== OUTBOUND NEIGHBORS ====
CN=Configuration,DC=eida,DC=lan
Default-First-Site-Name\DC1 via RPC
DSA object GUID: d2bd2987-A-B-C-5ba7691aadef
Last attempt @ NTTIME(0) was successful
0 consecutive failure(s).
Last success @ NTTIME(0)
...
==== KCC CONNECTION OBJECTS ====
Connection --
Connection name: 5a4b78fa-A-B-C-eca1e621c4de
Enabled : TRUE
Server DNS name : dc1.eida.lan
Server DN name : CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=eida,DC=lan
TransportType: RPC
options: 0x00000001
Warning: No NC replicated for Connection!
Nastavení NTP, ve smyslu balíčku ntp a nikoliv démona OpenNTPd, je pak důležité pro časové značky a synchronizaci času Windows pomocí NT5DS. K tomu se používá socket ntp_signd a může být trochu složité ho nastavit, protože jakákoliv přímá změna oprávnění adresáře doslova znemožní spuštění samby, tudíž je tu potřeba si trochu pomoct zase ACL, ale ve finále žádná věda. Celková konfigurace může pak vypadat třeba následovně, kde si NTP bere upstream čas z jiného počítače v síti a když se to nepovede, pak z Apple.
root@dc2:/home/eida# cat /etc/ntp.conf driftfile /var/lib/ntp/ntp.drift leapfile /usr/share/zoneinfo/leap-seconds.list statistics loopstats peerstats clockstats filegen loopstats file loopstats type day enable filegen peerstats file peerstats type day enable filegen clockstats file clockstats type day enable pool [SERVER].eida.lan # jako pool - hlavní NTP v síti server time.euro.apple.com # fallback restrict -4 default kod limited nomodify notrap nopeer mssntp restrict -6 default kod limited nomodify notrap nopeer mssntp restrict 127.0.0.1 restrict ::1 restrict default kod nomodify notrap nopeer mssntp restrict source notrap nomodify noquery mssntp ntpsigndsocket /var/lib/samba/ntp_signd/ root@dc2:/home/eida# setfacl -m u:ntp:rwx /var/lib/samba/ntp_signd/
Poslední nejméně důležitá věc na celém AD je vlastní DNS server, kterým je BIND a Samba mu jen poskytuje DLZ vlastní(ch) zón(y). Konfigurace je poměrně jednoduchá, viz dále, ovšem drobná vada na kráse by se tu našla. Z nějakého důvodu se při přímém připojení Samby 4.13 s BIND backendem nesprávně vytvoří Kerberos tikety pro manipulaci se zónou – v ukázce mám tedy v parametru tkey-gssapi-keytab zapsanou skutečnou cestu, ta zamýšlená se dá samozřejmě vytvořit symbolickým odkazem, dále je také nutné se ujistit, že BIND má ke všem těmto adresářům Samby přístup. On by měl mít, od toho je to balíčkované, dokonce Debianí balíčky i správně nastavují AppArmor, aby to bylo možné.
root@dc2:/home/eida# cat /etc/bind/named.conf
include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";
include "/var/lib/samba/bind-dns/named.conf";
root@dc2:/home/eida# cat /etc/bind/named.conf.options
acl "trusted" {
10.5.0.0/16;
2001:ab:cd:ef::/64;
localhost;
localnets;
};
acl "server" {
10.5.5.102/32; // DC2
10.5.5.100/32; // primární DNS
2001:ab:cd:ef::dc2; // DC2
2001:ab:cd:ef::a; // primární DNS
};
options {
directory "/var/cache/bind";
tkey-gssapi-keytab "/var/lib/samba/private/dns.keytab";
forwarders {
10.5.5.100;
2001:ab:cd:ef::a;
};
dnssec-validation auto;
auth-nxdomain no;
listen-on { 10.5.5.102; };
listen-on-v6 { 2001:ab:cd:ef::dc2; };
};
root@dc2:/home/eida# setfacl -m u:bind:rw /var/lib/samba/private/dns.keytab
root@dc2:/home/eida# setfacl -R -m u:bind:rwx /var/lib/samba/bind-dns/
Teď by to asi restartoval, pro jistotu. Poslední dva kritické příkazy, první spouštěný z DC2 a druhý z DC1, provádějí změnu primárního řadiče domény se všemi jeho rolemi na DC2 a následně dotazem na DC2 v roli PDC odpojují řadič DC1 od domény. Vypisuje to obyčejně docela dost hlášek, podstatné je správné převzetí rolí.
root@dc2:/var/lib/samba# samba-tool fsmo transfer --role=all ... root@dc1:/home/eida# samba-tool domain demote -U eida --server=dc2.eida.lan ...
V ideálním případě se to prostě povede a není potřeba se o to starat a je to asi tisíckrát snazší, než to provádět třeba v RSAT jednotlivým klikáním na různá zákoutí MMC snap-inů. Důležité je ale si dát ještě před definitivním odpojením DC1 pozor především na DNS, protože ta si přenáší je to podstatné pro sebe a okolní záznamy může ignorovat. Ono v malé síti prostě není na škodu mít velký centrální DNS server nastavený jako slave pro AD zóny a DNS servery na AD pro překlady prakticky vůbec nepoužívat; navíc se přímo nabízí možnost vytvářet si tam poměrně jednoduchým klikáním a díky DLZ nějaké ad-hoc úpravy v podobě jiných primárních zón, například když je v síti potřeba nějaký hairpin pro vývoj, ale nemáme přístup k tomu zatracenýmu Mikrotiku tam nahoře. Potom ale logicky nedojde k přenosu těchto vlastně cizích NS, takže to je potřeba si ohlídat manuálně.
-
DC2 je připojen vedle PDC DC1
-
S vypnutou Sambou automaticky funguje failover z jednoho DC na druhý
-
Správně pracující synchronizace času z nového PDC
Pokud vše z tohoto pohledu pracuje, jak má, je možná čas spustit ještě teda ten FreeRADIUS přímo na DC2. Nic snazšího, prostě tady vezmu z původního serveru (tady rovnou DC1) celou konfiguraci jak je a napaštím ji na tento stroj. Protože je ale možné, že původní konfigurace počítala s využitím programů Samby kompilované ze zdrojů, je potřeba zkontrolovat prefix, aby byl jaksepatří debianizovaný. Tady konkrétně půjde o ntlm_auth, který nebude mít prefix /usr/local/samba/bin, ale prostě /usr/bin.
Dál je tady vlastně zajímavá věc, že balík přímo vytvořil systémovou skupinu winbindd_priv, do které stačí přidat uživatele freerad a je vymalováno, žádné těžko vysledovatelné ACL pro socket winbindu není potřeba.
root@dc1:/home/eida# tar cJf /tmp/radius-conf.tar.xz /etc/freeradius/3.0/ tar: Odstraňuje se úvodní „/“ z názvů prvků root@dc1:/home/eida# chown eida:eida /tmp/radius-conf.tar.xz root@dc1:/home/eida# md5sum /tmp/radius-conf.tar.xz a2cb575ea3c8b51b6ab2bd1becf8d6b2 /tmp/radius-conf.tar.xz eida@dc2:~# scp dc1:/tmp/radius-conf.tar.xz /tmp/ radius-conf.tar.xz 100% 164KB 35.3MB/s 00:00 eida@dc2:~$ sudo su [sudo] heslo pro eida: root@dc2:/home/eida# md5sum /tmp/radius-conf.tar.xz a2cb575ea3c8b51b6ab2bd1becf8d6b2 /tmp/radius-conf.tar.xz root@dc2:/home/eida# service freeradius stop root@dc2:/home/eida# tar xf /tmp/radius-conf.tar.xz --directory / root@dc2:/home/eida# usermod -a -G winbindd_priv freerad root@dc2:/home/eida# service freeradius start
No a na závěr jenom stručný nápad, jak to celé trochu víc ještě izolovat v LANě, prostě ve firewallu, kterým je tady netfilter ještě s dialektem starých iptables, prostě povolit jen ty potřebné služby. Je to jen návrh, realita se může lišit, ale zhruba by to takhle mohlo být.
root@dc2:/home/eida# cat /etc/iptables/rules.v4 *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -i lo -j ACCEPT -A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP -A INPUT -f -j DROP -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -d 10.5.5.102/32 -p icmp -m icmp --icmp-type 8 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT -A INPUT -d 10.5.5.100/32 -p icmp -m icmp --icmp-type 8 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT -A INPUT -s 10.5.5.100/32 -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -s 10.5.5.1/32 -p udp -m udp --dport 1812 -j ACCEPT -A INPUT -s 10.5.5.1/32 -p udp -m udp --dport 1813 -j ACCEPT -A INPUT -s 10.5.5.1/32 -p udp -m udp --dport 1814 -j ACCEPT -A INPUT -s 10.5.5.100/32 -p udp -m udp --dport 53 -j ACCEPT -A INPUT -s 10.5.5.100/32 -p tcp -m tcp --dport 53 -j ACCEPT -A INPUT -s 10.5.5.100/32 -p tcp -m tcp --dport 953 -j ACCEPT -A INPUT -s 10.5.0.0/16 -p udp -m udp --dport 88 -j ACCEPT -A INPUT -s 10.5.0.0/16 -p tcp -m tcp --dport 88 -j ACCEPT -A INPUT -s 10.5.0.0/16 -p udp -m udp --dport 123 -j ACCEPT -A INPUT -s 10.5.0.0/16 -p tcp -m tcp --dport 445 -j ACCEPT -A INPUT -s 10.5.0.0/16 -p tcp -m tcp --dport 135 -j ACCEPT -A INPUT -s 10.5.0.0/16 -p tcp -m tcp --dport 139 -j ACCEPT -A INPUT -s 10.5.0.0/16 -p udp -m udp --dport 137 -j ACCEPT -A INPUT -s 10.5.0.0/16 -p udp -m udp --dport 138 -j ACCEPT -A INPUT -s 10.5.0.0/16 -p tcp -m tcp --dport 389 -j ACCEPT -A INPUT -s 10.5.0.0/16 -p udp -m udp --dport 389 -j ACCEPT -A INPUT -s 10.5.0.0/16 -p tcp -m tcp --dport 464 -j ACCEPT -A INPUT -s 10.5.0.0/16 -p udp -m udp --dport 464 -j ACCEPT -A INPUT -s 10.5.0.0/16 -p tcp -m tcp --dport 636 -j ACCEPT -A INPUT -s 10.5.0.0/16 -p tcp -m tcp --dport 3268 -j ACCEPT -A INPUT -s 10.5.0.0/16 -p tcp -m tcp --dport 3269 -j ACCEPT -A INPUT -s 10.5.0.0/16 -p tcp -m multiport --dports 1024:1300,49152:65535 -j ACCEPT COMMIT root@dc2:/home/eida# cat /etc/iptables/rules.v6 *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -i lo -j ACCEPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -s fe80::/10 -p ipv6-icmp -j ACCEPT -A INPUT -s 2001:ab:cd:ef::/64 -p ipv6-icmp -j ACCEPT -A INPUT -s 2001:ab:cd:ef::a/128 -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -s 2001:ab:cd:ef::1/128 -p udp -m udp --dport 1812 -j ACCEPT -A INPUT -s 2001:ab:cd:ef::1/128 -p udp -m udp --dport 1813 -j ACCEPT -A INPUT -s 2001:ab:cd:ef::1/128 -p udp -m udp --dport 1814 -j ACCEPT -A INPUT -s 2001:ab:cd:ef::a/128 -p udp -m udp --dport 53 -j ACCEPT -A INPUT -s 2001:ab:cd:ef::a/128 -p tcp -m tcp --dport 53 -j ACCEPT -A INPUT -s 2001:ab:cd:ef::/64 -p tcp -m multiport --dports 1024:1300,49152:65535 -j ACCEPT -A INPUT -s 2001:ab:cd:ef::a/128 -p tcp -m tcp --dport 953 -j ACCEPT -A INPUT -s 2001:ab:cd:ef::/64 -p udp -m udp --dport 88 -j ACCEPT -A INPUT -s 2001:ab:cd:ef::/64 -p tcp -m tcp --dport 88 -j ACCEPT -A INPUT -s 2001:ab:cd:ef::/64 -p udp -m udp --dport 123 -j ACCEPT -A INPUT -s 2001:ab:cd:ef::/64 -p tcp -m tcp --dport 445 -j ACCEPT -A INPUT -s 2001:ab:cd:ef::/64 -p tcp -m tcp --dport 135 -j ACCEPT -A INPUT -s 2001:ab:cd:ef::/64 -p tcp -m tcp --dport 139 -j ACCEPT -A INPUT -s 2001:ab:cd:ef::/64 -p udp -m udp --dport 137 -j ACCEPT -A INPUT -s 2001:ab:cd:ef::/64 -p udp -m udp --dport 138 -j ACCEPT -A INPUT -s 2001:ab:cd:ef::/64 -p tcp -m tcp --dport 389 -j ACCEPT -A INPUT -s 2001:ab:cd:ef::/64 -p udp -m udp --dport 389 -j ACCEPT -A INPUT -s 2001:ab:cd:ef::/64 -p tcp -m tcp --dport 464 -j ACCEPT -A INPUT -s 2001:ab:cd:ef::/64 -p udp -m udp --dport 464 -j ACCEPT -A INPUT -s 2001:ab:cd:ef::/64 -p tcp -m tcp --dport 636 -j ACCEPT -A INPUT -s 2001:ab:cd:ef::/64 -p tcp -m tcp --dport 3268 -j ACCEPT -A INPUT -s 2001:ab:cd:ef::/64 -p tcp -m tcp --dport 3269 -j ACCEPT -A INPUT ! -s 2001:ab:cd:ef::/64 -j DROP COMMIT root@dc2:/home/eida# iptables-nft-restore < /etc/iptables/rules.v4 root@dc2:/home/eida# ip6tables-nft-restore < /etc/iptables/rules.v6
Oproti očekávání katastrofy lze tohle celé spáchat tedy opravdu velmi rychle a zreplikovat a přesunout si celou věc docela snadno na nějaké nové platformy a dobrodružství. Budiž to tedy světlým bodem v lockdownu, že někde skutečně už mohou vládnout balíci a poměrně usnadňovat různě složitou údržbu automatickými aktualizacemi.