Eida.cz - Enterprise transfer rovnou z balíku

Enterprise transfer rovnou z balíku

Eida

Ž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.

Distribucím by měli vládnout balíci.

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.

02-fstab.conf 210 bajtů
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
Úprava fstab pro /. acl, user_xattr, barrier=1

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.

01-install.txt 112 bajtů
root@dc2:/home/eida# apt install acl samba winbind ntp krb5-user bind9 dnsutils freeradius netfilter-persistent
Počáteční instalace základních balíků. Více netřeba. Podstatné je nezapomenout na acl, winbind a dnsutils.

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.

03-sudo.txt 918 bajtů
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
Práce pod klasickým rootem nemá úpně všechny cesty v pořádku, ale hodně lidí neumí nahodit sudo.

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.

04-network.txt 593 bajtů
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
Konfigurace statických adres je pro řadiče klíčová. IPv6 pořád nejde nastavit nějakou příjemnou cestou, ale zase umožňuje hry se slovy typu dc.

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í.

05-ssh.txt 555 bajtů
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
OpenSSH server už jedině přes Ed25519 klíče.

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.
Povolení běhu Samby v režimu AD DC.

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.

07-smb.conf 614 bajtů
[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
Zkopírovaný smb.conf ze starého řadiče, jen s novým názvem.

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!
Přidání sekundárního řadiče do domény, automaticky se spustí replikace.

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.

09-ntp.txt 769 bajtů
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/
Konfigurace balíčkového NTP pro synchronizaci času přes NT5DS.

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é.

10-bind.txt 908 bajtů
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/
BIND 9.16 jako master pro zónu.

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í.

11a-demote.txt 146 bajtů
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
...
Změna primárního řadiče na DC2 a odebrání DC1 z domény.

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ě. 

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.

11-radius.txt 774 bajtů
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
Kopie konfigurace FreeRADIUS, změny je potřeba udělat pouze v prefixech cest NTLM autentizátoru.

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
Zhruba nástřel realizace firewallu v dialektu starých iptables.

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.

Tento článek přečetlo již 536 čtenářů (0 dnes).

Komentáře

Nový komentář