QNAP iptables po aktualizacji z QTS 4.2 do 4.3

Witam!

Używamy QNAP’ów do magazynowania backupów. I mamy jeden taki “większy” QNAP do zabezpieczania backupów, który jest bezpośrednio połączony z innymi QNAP’ami (nasze QNAPy mają po 4 LANy). Ten jeden QNAP był skonfigurowany trochę inaczej, tzn nie przyjmował połączeń z zewnątrz czyli od innych QNAPów.
Domyślna polityka INPUT - DROP
i linijka
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

oczywiście kilka innych, żeby można było się na “porcie serwisowym” - jednym z LANów podłączyć laptopem.
Chodziło o to, że na tym zbiorczym QNAP’ie chodził skrypt, który mapował po cifs udziały pozostałych, sprawdzał status kopi zapasowej czy nie jest zaszyfrowana i robił rsync tej kopi na siebie. Od takie zabezpieczenie kopii przed ransomware.

W związku z Samba-Cry zrobiliśmy aktualizacje do najnowszej wersji 4.3.3 z przed kilku dni… i… przestał działać moduł conntrack:
iptables: No chain/target/match by that name.

Wpisując iptables -A INPUT -m conntrack -h
normalnie wyświetla się help od tego modułu.
Moduł state tak samo. Jest tatk na wszystkich QNAP z 4.3.3 z którymi mam kontakt.

Założyłem temat na forum.qnap.com ale bez odzewu.
https://forum.qnap.com/viewtopic.php?f=73&t=134556

Macie jakieś sugestie?

Pozdrawiam
PCGyver

Myślę, że bez łatki od producenta się nie obejdzie, chyba że napiszesz własną. Podejrzewam, że wycieli to w jajku celowo lub przez przypadek. U mnie w firmie NASy kupuje się dla wygody i tak mnie ciekawi dlaczego w firmie macie QNAPy warte 2x tyle co sprzętowo lepszy serwer z czystym Linuksem? Nie rozumiem tego. Pytam tak po prostu z ciekawości. Support?

Z powodu stref sieciowych. Sprawa dotyczy podwykonawcy sektora energetycznego.
Strefa LAN,CVL (Client VPN LAN), DMZ, i jeszcze jedna związana z konkretnym systemem.
Każda ma swojego QNAP’a. I tak wielkim osiągnięciem kosztowym była zgodna na jednego QNAP’a, który zbiera backupy z pozostałych. Warunkiem była właśnie polityka DROP i stąd BARDZO potrzebuję tej jednej linijki iptables, żeby wpuszczało tylko pakiety zwrotne.
Dyskusje na temat innych rozwiązań i sposobów tych rozwiązań, były ucinane z powodu polityk bezpieczeństwa.

Ale twoja odpowiedź mnie zmartwiła :frowning: Jak taką łatkę zrobić do QNAP’a.
W gentoo czy innych linuxach instalowanych od zera przeze mnie, to wiadomo. Sam sobie kompiluje kernela. A tu w QNAPie?

No ja też mam serwery na Gentoo i Synology oraz Netgeary. Te drugie ze względu na wygodę, szczególnie gdzie jest mały budżet.

Soft jest przygotowany przez producenta, więc tu pozostaje jedynie czekanie na reakcję producenta. Jeśli programujesz i producent da Ci dostęp do kodu, to możesz spróbować.

Proponuję zwrócić się do supportu, tak najszybciej uzyskasz pomoc i ewentualną łatkę, która może być napisana tylko dla Twoich potrzeb lub dostaniesz ją szybciej. Miałem niedawno inny przypadek. W jednej z firm mamy za namową switche TP Linka. My wdrażamy tam Netgeary, gdyż TP Linki nie ogarniały ruchu sieciowego i nie spełniały naszych norm. Okazało się, że TP Link nie potrafi dogadać się na łączach światłowodowych z Netgearem i powodowały pętle w sieci. Kolega zwrócił się o pomoc do supportu TP Linka i okazało się, że jest to błąd w sofcie switcha. Napisali dla nas łatkę, jednak i to spierniczyli, bo połączenie negocjowało tylko pół dupleks.

Jest nowy firmware 4.3.3.0299 z 20170901 i dalej to samo. A temat z helpdeska został przez QNAP’a zamknięty

Jeśli nie udzieliłeś odpowiedzi w odpowiednim czasie, to automat pewnie zamknął temat. Napisz do nich, to temat powinien się otworzyć. Generalnie z rozwiązaniami typu QNAP, Synology jest tak, że nie grzebie się w shellu, bo później są właśnie takie niespodzianki.