- 16 Styczeń 2018
- 1 347
- 2
- 491
- 113
- 38
- QNAP
- TVS-h1288X
- Ethernet
- 10 GbE
Zacznę od utopii bezpieczeństwa NASa - zabezpieczeń nie do złamania. Jak tylko kupujesz nowy NAS, pierwsze co robimy to wyciągamy z kartonu i stawiamy na półce, ALE UWAGA kluczowe - bez podłączenia do sieci. W ten sposób macie zabezpieczony NAS w 100% przed jakimikolwiek atakami.
Tyle z żartów. Nie da się zabezpieczyć komputera / serwera / czegokolwiek w 100%, bo zawsze, w każdym oprogramowaniu ktoś znajdzie jakąś dziurę. Pamiętam, jak na studiach ok 2005 FreeBSD szczycił się tym, że to najbezpieczniejszy system, bo przez kilka lat znaleźli kilka dziur. Dosłownie kilka. Tylko czasy się zmieniły - dziś nikt praktycznie nie wypuszcza świetnie dopracowanego produktu, tylko wczesne wersje beta - bo tego wymaga rynek. Daleko nie trzeba szukać CyberPunk 2077.
Co do zabezpieczeń NASa, jednym z lepszych pomysłów, na dostęp do Qnapa jest dostęp tylko przez VPN. Dlaczego? Bo skanowanie portów UDP jest trudniejsze niż TCP:
1. Więc - MyQnapCloud Link -> UPnP off, MyDDNS off, MyQnapLink off. Nie wystawiamy portów Qnapa do łączenia się po http czy https na zewnątrz - nic. Tylko porty do VPN. Jeżeli ktoś chce:
2. Jeżeli musisz wystawić porty np. http lub https - dobrze mieć jakiegoś Firewalla z odpowiednią polityką. QNAP ostatnio wprowadził do sklepu QuFirewall - z 3 predefiniowanymi ustawieniami. Minimum to Basic - oraz dopuszczanie po geolokacji - wybieramy Polska i tylko "polskie" IP będą mogły się podłączyć do Qnapa. Takie ustawienia, daję dobry poziom zabezpieczeń i pewności, że nie powinno stać się nic złego. Utopią jest - wrzucenie poszczególnych adresów IP które mogą się łączyć - ale bądźmy szczerzy - cieżko to zrealizować - jako, że dziś łączymy się z różnych miejsc na świecie.
3. Jak Qnap to uber serwer do wszystkiego, masz miliard usług i to centrum świata - wypada mieć porządnego Firewalla z IPSem. Posłużę się moim przypadkiem, gdzie mam Ubiquiti Dream Machine Pro (Ubi powinno mi płacić za chwalenie produktu
) z włączonym IPS (IDS/IPS systemy wykrywania i zapobiegania włamaniom) które min. ma listy sieci botnet i je blokuje, malware i trojanów, zablokowałem sieci TOR, IPS ma odpierać ataki na usługi hostingowe i pocztowe, z automatu odrzuca połączenia z list min. CI Army, DShield. Dzięki temu, uważam że sieć jest dobrze zabezpieczona i ja się opieram jakimkolwiek atakom, od kiedy mam DMP. Nie mam myqnapcloud, żadnego UPnP, ale mam na prawdę sporo portów wystawionych - i jest bezpiecznie. Ale zdaję sobie sprawę, że tu może być jakaś luka i:
Na naszym forum jest od groma informacji o tym, że trzeba się zabezpieczyć i być świadomym zagrożeń, ale większość z Was to bagatelizuje, "co ja tam mam na tym serwerze". Wiele osób się nie zna, ale też nie przejawia chęci to poświęcenia chwili i zrobienia audytu swojej sieci - żeby wykazać minimum inicjatywy, aby sytuacja z Qlockerem nikogo więcej nie dotknęła. Albo przynajmniej minimalizować ryzyko do 0.
Niech każdy wykaże odrobinę chęci i poświęci trochę czasu na sprawdzenie - co może zrobić, żeby chronić się przed atakami, których - bądźmy szczerzy - będzie co raz więcej, bo to łatwy pieniądz.
Tyle z żartów. Nie da się zabezpieczyć komputera / serwera / czegokolwiek w 100%, bo zawsze, w każdym oprogramowaniu ktoś znajdzie jakąś dziurę. Pamiętam, jak na studiach ok 2005 FreeBSD szczycił się tym, że to najbezpieczniejszy system, bo przez kilka lat znaleźli kilka dziur. Dosłownie kilka. Tylko czasy się zmieniły - dziś nikt praktycznie nie wypuszcza świetnie dopracowanego produktu, tylko wczesne wersje beta - bo tego wymaga rynek. Daleko nie trzeba szukać CyberPunk 2077.
Co do zabezpieczeń NASa, jednym z lepszych pomysłów, na dostęp do Qnapa jest dostęp tylko przez VPN. Dlaczego? Bo skanowanie portów UDP jest trudniejsze niż TCP:
Dla skanera sieci ważnym procesem jest etap wykrywania otwartych portów TCP i UDP na badanym zdalnym hoście. Najpopularniejszą techniką skanowania portów TCP jest metoda TCP SYN scan – szybka, działająca z każdą implementacją stosu TCP, a dodatkowo nigdy nie ustanawia kompletnego połączenia TCP, co zapewnia częściową dyskrecję skanowania. Zasada działania metody nie jest skomplikowana – skaner portów wysyła pakiet SYN podobnie jak w przypadku nawiązywania rzeczywistego połączenia, a następnie oczekuje na odpowiedź. Odpowiedź w postaci pakietu SYN/ACK wskazuje otwarty port, natomiast odpowiedź w postaci pakietu RST oznacza brak nasłuchiwania na określonym porcie. Jeżeli nie pojawia się odpowiedź po kilku próbach retransmisji, port jest określany jako filtrowany. Inne popularne metody skanowania portów TCP to: TCP connect scan, SCTP INIT scan, TCP ACK scan.
Połączenia TCP są zorientowane na połączenie i zestawianie połączenia do zdalnego hosta za pomocą trójstronnego procesu. UDP jest protokołem niezestawiającym połączenia. Połączenie UDP polega na wysłaniu pakietu do usługi UDP bez konieczności wcześniejszego zestawienia połączenia. Z tego powodu badanie otwartych portów UDP jest zdecydowanie trudniejsze niż TCP. W momencie wysyłania pakietu na określony port zdalnego hosta możemy spodziewać się kilku sytuacji zwrotnych. Jeżeli port UDP jest otwarty, pakiet zostanie akceptowany przez docelowy host, a skaner nie otrzymuje odpowiedzi. Jeżeli port jest zamknięty, docelowy host wysyła w odpowiedzi pakiet ICMP z odpowiednim kodem błędu, przykładowo: ICMP Destination Unreachable. Skanowanie ICMP nie polega na odbieraniu potwierdzeń ze zdalnego hosta, jak to jest w TCP, ale kolekcjonowaniu błędów, które wysyła badany host do każdego zamkniętego portu. Zamknięte porty UDP są wykrywane poprzez obecność pakietów odpowiedzi ICMP, otwarte porty są wykrywane przez brak odpowiedzi na wysłany pakiet. Skanowanie UDP ma kilka ograniczeń. Wiele systemów operacyjnych wykorzystuje w implementacji stosu bufory, umożliwiające kolejkowanie przychodzących pakietów. Bufor dla pakietów UDP jest bardzo ograniczony, co powoduje, że pakiety UDP wysyłane zbyt szybko nie są przetwarzane przez badany host. Z tego powodu skanowanie portów UDP jest znacznie wolniejsze niż skanowanie portów TCP i domyślnie obejmuje niewielki zakres portów. Problemem są także zapory sieciowe, które mogą zmieniać wyniki odpowiedzi. Pakiety ICMP są często filtrowane w zaporze sieciowej, co powoduje brak odpowiedzi ICMP na zapytanie wysyłanie przez skaner, w celu testowania portu UDP, który nie jest otwarty. Detekcja usług i otwartych portów UDP jest realizowana poprzez wysłanie pakietu odpowiadającego usłudze normalnie uruchomionej na porcie UDP. Przykładowo zapytanie na port 53 i brak odpowiedzi oznacza otwarty port dla usługi DNS.
Połączenia TCP są zorientowane na połączenie i zestawianie połączenia do zdalnego hosta za pomocą trójstronnego procesu. UDP jest protokołem niezestawiającym połączenia. Połączenie UDP polega na wysłaniu pakietu do usługi UDP bez konieczności wcześniejszego zestawienia połączenia. Z tego powodu badanie otwartych portów UDP jest zdecydowanie trudniejsze niż TCP. W momencie wysyłania pakietu na określony port zdalnego hosta możemy spodziewać się kilku sytuacji zwrotnych. Jeżeli port UDP jest otwarty, pakiet zostanie akceptowany przez docelowy host, a skaner nie otrzymuje odpowiedzi. Jeżeli port jest zamknięty, docelowy host wysyła w odpowiedzi pakiet ICMP z odpowiednim kodem błędu, przykładowo: ICMP Destination Unreachable. Skanowanie ICMP nie polega na odbieraniu potwierdzeń ze zdalnego hosta, jak to jest w TCP, ale kolekcjonowaniu błędów, które wysyła badany host do każdego zamkniętego portu. Zamknięte porty UDP są wykrywane poprzez obecność pakietów odpowiedzi ICMP, otwarte porty są wykrywane przez brak odpowiedzi na wysłany pakiet. Skanowanie UDP ma kilka ograniczeń. Wiele systemów operacyjnych wykorzystuje w implementacji stosu bufory, umożliwiające kolejkowanie przychodzących pakietów. Bufor dla pakietów UDP jest bardzo ograniczony, co powoduje, że pakiety UDP wysyłane zbyt szybko nie są przetwarzane przez badany host. Z tego powodu skanowanie portów UDP jest znacznie wolniejsze niż skanowanie portów TCP i domyślnie obejmuje niewielki zakres portów. Problemem są także zapory sieciowe, które mogą zmieniać wyniki odpowiedzi. Pakiety ICMP są często filtrowane w zaporze sieciowej, co powoduje brak odpowiedzi ICMP na zapytanie wysyłanie przez skaner, w celu testowania portu UDP, który nie jest otwarty. Detekcja usług i otwartych portów UDP jest realizowana poprzez wysłanie pakietu odpowiadającego usłudze normalnie uruchomionej na porcie UDP. Przykładowo zapytanie na port 53 i brak odpowiedzi oznacza otwarty port dla usługi DNS.
1. Więc - MyQnapCloud Link -> UPnP off, MyDDNS off, MyQnapLink off. Nie wystawiamy portów Qnapa do łączenia się po http czy https na zewnątrz - nic. Tylko porty do VPN. Jeżeli ktoś chce:
- OpenVPN to standardowym portem jest 1194 UDP
- L2TP - 500, 1701, 4500 -> wszystkie UDP
- Qbelt - standardowo 443 UDP
- PPTP - jak najdalej od tego VPN. Nie powinno się go dziś w ogóle używać.
2. Jeżeli musisz wystawić porty np. http lub https - dobrze mieć jakiegoś Firewalla z odpowiednią polityką. QNAP ostatnio wprowadził do sklepu QuFirewall - z 3 predefiniowanymi ustawieniami. Minimum to Basic - oraz dopuszczanie po geolokacji - wybieramy Polska i tylko "polskie" IP będą mogły się podłączyć do Qnapa. Takie ustawienia, daję dobry poziom zabezpieczeń i pewności, że nie powinno stać się nic złego. Utopią jest - wrzucenie poszczególnych adresów IP które mogą się łączyć - ale bądźmy szczerzy - cieżko to zrealizować - jako, że dziś łączymy się z różnych miejsc na świecie.
3. Jak Qnap to uber serwer do wszystkiego, masz miliard usług i to centrum świata - wypada mieć porządnego Firewalla z IPSem. Posłużę się moim przypadkiem, gdzie mam Ubiquiti Dream Machine Pro (Ubi powinno mi płacić za chwalenie produktu
) z włączonym IPS (IDS/IPS systemy wykrywania i zapobiegania włamaniom) które min. ma listy sieci botnet i je blokuje, malware i trojanów, zablokowałem sieci TOR, IPS ma odpierać ataki na usługi hostingowe i pocztowe, z automatu odrzuca połączenia z list min. CI Army, DShield. Dzięki temu, uważam że sieć jest dobrze zabezpieczona i ja się opieram jakimkolwiek atakom, od kiedy mam DMP. Nie mam myqnapcloud, żadnego UPnP, ale mam na prawdę sporo portów wystawionych - i jest bezpiecznie. Ale zdaję sobie sprawę, że tu może być jakaś luka i:- mimo wszystko robię regularnie kopię VM na zdalny serwer NAS u znajomego - bo licho nie śpi
- planuję kupić drugi serwer, bo nie mogę sobie pozwolić na przerwę w działaniu usług i serwer będzie uruchamiany tylko po to żeby wykonać na niego kopię zapasową i tyle
Na naszym forum jest od groma informacji o tym, że trzeba się zabezpieczyć i być świadomym zagrożeń, ale większość z Was to bagatelizuje, "co ja tam mam na tym serwerze". Wiele osób się nie zna, ale też nie przejawia chęci to poświęcenia chwili i zrobienia audytu swojej sieci - żeby wykazać minimum inicjatywy, aby sytuacja z Qlockerem nikogo więcej nie dotknęła. Albo przynajmniej minimalizować ryzyko do 0.
Niech każdy wykaże odrobinę chęci i poświęci trochę czasu na sprawdzenie - co może zrobić, żeby chronić się przed atakami, których - bądźmy szczerzy - będzie co raz więcej, bo to łatwy pieniądz.
