Jak zezwolić na dostęp tylko do określonych adresów IP za pomocą wbudowanej zapory ogniowej Parallels VZ?

Jak mogę używać programu Parallels Virtuozzo wbudowany w mechanizm zapory ( nazywane psa-firewallpod okap widocznie faktycznie psa-firewallwydaje się być oddzielna interfejs Plesk - Tak czy inaczej, jest to w zasadzie UI dla ograniczonego zarządzania iptables) dla VPSS założyć prostą regułę, która blokuje dostęp do port dla wszystkich połączeń innych niż określone adresy IP?

Wpadłem na pomysł, że reguły zapory sieciowej VZ - podobnie jak reguły iptables, na które (według mnie) są przetłumaczone - zostały wykonane w kolejności od góry do dołu i że mogłem zablokować dostęp do mojego portu z wyjątkiem określonych adresów IP (w tym przypadku , SSH na porcie 22), mając wąskie reguły Zezwól na liście, dla adresu IP xx.xx.xx.xx i portu 22, a następnie regułę odrzucenia na końcu dla dowolnego adresu IP i portu 22.

Pomysł polegał na tym, że w przypadku żądań z podanych adresów IP zostanie osiągnięta reguła Zezwól, więc reguła Odrzucenia nigdy nie zostanie osiągnięta. W pozostałym zakresie reguła Zezwól zostanie zignorowana, a reguła odrzucenia pod nią zostanie osiągnięta.

Ale tak się nie udało . Na początku działało to dokładnie tak, jak zamierzano, ale ~ 20 minut później znalazłem się z dala od SSH, a jedynym sposobem, w jaki mogłem wrócić, było zarówno usunięcie reguły Odrzuć, jak i dodanie (nadmiarowej) Zezwól wszystkim na port 22 na górę listy.

Przy dalszych testach wydaje się, że kolejność reguł w interfejsie użytkownika zapory VZ nie określa czysto kolejności w wynikowej konfiguracji. np. stwierdzam, że posiadanie reguły Zezwalaj wszystkim na 22 na górze listy i Odrzuć wszystkie do 22 na dole wydaje się blokować wszystkie połączenia, podobnie jak robi to dokładnie z odwróconą kolejnością.

Miałem teorię, że narzędzie przygotowuje nowo aktywowane reguły do ​​listy, ale wydaje się, że posiadanie reguły „odrzuć wszystko” zawsze obezwładnia wszelkie reguły „akceptuj jeden” bez względu na pozycję listy lub kolejność ich dodawania.

Nie mogę znaleźć wzoru i nie mogę znaleźć żadnych odpowiednich zasobów w tym narzędziu, które by to wyjaśniły. Nie mogę też znaleźć innych podejść.

Powodem, dla którego używam narzędzia zapory sieciowej VZ, a nie tylko bezpośredniego korzystania z iptables , jest to, że chcę, aby administratorzy mogli aktualizować reguły i dodawać adresy IP z białej listy bez żadnego niebezpieczeństwa, że ​​zablokują się na stałe. Przydaje się możliwość administrowania dostępem SSH za pomocą narzędzia, które samo w sobie nie wymaga dostępu SSH.

ps Bardzo trudno jest znaleźć wysokiej jakości informacje na temat zapory sieciowej VZ. Wszędzie, gdzie patrzę, zabiera mnie albo żałośnie niekompletne zasoby w stylu manekinów, albo informacje o bezpośredniej konfiguracji iptables. Nie mogę znaleźć niczego na temat interpretacji ustawień interfejsu użytkownika za kulisami ani ich związku z istniejącymi ustawieniami iptables. Docenione zostaną również wszelkie ogólne wskazówki dotyczące szczegółowych informacji o jakości na temat tego, co dzieje się za kulisami narzędzia zaporowego VZ.

To po prostu moja najlepsza teoria do tej pory testowania. To wygląda jak:

• W przypadku zmian narzędzie zapory sieciowej VZ wyszukuje istniejącą regułę, usuwa ją i dodaje nową regułę zamiast resetowania reguł. Wygląda na to, że może to nie być w 100% niezawodne i że można edytować reguły i uzyskać „regułę widma”, która pozostaje do momentu zresetowania IPtables.
• Wygląda na to, że narzędzie okresowo opróżnia i ponownie uruchamia reguły (oraz wszelkie zakodowane w / etc / firewall / include).
• Wygląda na to, że reguły skonfigurowane za pomocą interfejsu użytkownika narzędzia są ułożone w kolejności i zachowują się tak, jak się spodziewałem - chyba że za sceną stoi jedna z tych „duchów”.

Jeśli to prawda, jeśli ktoś znajdzie się w sytuacji, w której byłem, powinieneś być w stanie zapory ogniowej VZ, aby zachowywać się racjonalnie, używając VZ do ponownego uruchomienia „usługi” iptables w „Usługach systemowych” . Dodaj tymczasową regułę zezwalającą na początek łańcucha, jeśli twierdzi, że nie jest w stanie zrestartować usługi.

( zachowaj ostrożność przy używaniu iptables -Fdo opróżniania reguł iptables, ponieważ wydaje się, że wszystko to opróżnia, łącznie z regułami, które przyznają narzędziom VZ odpowiedni dostęp. Narzędzie do ponownego uruchamiania systemu odświeża iptables wszystkim, w tym konfiguracją VZ pod maską, konfiguracją twojego hosta, skonfigurowanymi regułami w narzędziu, a niestandardowe reguły w /etc/firewall/include. iptables -Fnie. Jeśli jest ustawione domyślnie na odrzucanie lub upuszczanie, możesz całkowicie się zablokować)

Edycja: najwyraźniej to nie wszystko ... Nagle narzędzie zapory sieciowej VZ zaczęło w ogóle nie mieć wpływu na podstawowe reguły iptables , i używając iptables -n -L INPUT|grep dpt:22do wyświetlenia listy wszystkich reguł iptables, które określają port dport 22, widzę wiele starych reguł śmieci, które zostały usunięte, które nie są usuwane przy ponownym uruchomieniu, nawet po opróżnieniu iptables i ponownym uruchomieniu usługi. Czytanie http://www.webhostingtalk.com/showthread.php?t=1166215 sugeruje, że zapora sieciowa VZ ma również bazę danych reguł, które mogą się nie zsynchronizować z kodem i interfejsem użytkownika ... ale nie daje pojęcia, jak aby uzyskać dostęp do tej bazy danych.

Edycja 2: Wygląda na to, że coś spowodowało, że iptables i zapora sieciowa Virtuozzo zaczęły po prostu czytać z pliku /etc/sysconfig/iptableszamiast poprawnie się regenerować. Nieudolna poprawka, którą znalazłem w tym celu, polegała zasadniczo na zmianie nazwy plików /etc/sysconfig/iptablesi /etc/sysconfig/iptables.savekopii zapasowych, a następnie skorzystaniu z VZ Firewall Setup, aby całkowicie zresetować zapory ogniowe, które wygenerowały puste iptablespliki, a następnie ponownie uruchomiłem usługę iptables - po wykonaniu tego wszystkiego, ustawienia w zaporze VZ użyteczność zaczęła mieć swoje przewidywane efekty.

Co ciekawe, po wykonaniu powyższego łańcuchy iptables mają nazwy takie jak VZ_INPUT zamiast INPUT, więc aby wyświetlić listę reguł iptables dla portu, muszę użyć iptables -n -L|grep dpt:22lub iptables -n -L VZ_INPUT|grep dpt:22zamiast iptables -n -L INPUT|grep dpt:22. Dziwny.

Mam nadzieję, że jeśli ktoś inny utknie w niewłaściwie zachowawczej usłudze zapory Virtuozzo, coś tutaj pomoże.