Piszki Lab

Analiza przypadku w języku przodków…

NAS w domu, suplement.

| 0 comments

Kwestie bezpieczeństwa.

Mój Synology jest od dłuższego czasu wystawiony w strefie DMZ bezpośrednio do Internetu. Korzystam z praktycznie wszystkich elementów sieciowych jakie udostępnia DSM 4.3 i muszę przyznać, że poziom zabezpieczeń jest zadowalający. Z jednym wyjątkiem, ale o tym za chwilę. Czasy mamy takie, że Internet od dawna nie jest miłym i spokojnym jeziorkiem, to raczej czarny ocean z wielkimi falami przyboju. Wystawianie czegokolwiek na zewnątrz wiąże się ze sporym ryzykiem o ile nie posiadamy trochę doświadczenia, odpowiednich narzędzi, oraz sporej dawki szczęścia.

Gdy wystawiamy “pudełkowe” rozwiązanie, ryzyko jest jeszcze większe. Z jednej strony producent dba o bezpieczeństwo, z drugiej mamy tylko te narzędzia, które on nam daje. W przypadku DSM 4.3 mamy jedno całkiem fajne rozwiązanie i drugie, które jest mniej fajne. Pierwszym jest możliwość automatycznego blokowania hostów z których podejmowane są (nieudane) próby logowania do systemu (ataki na pocztę, ssh). Jest to troszkę uproszczone rozwiązanie rodem z DenyHost, działa bardzo prosto, dodaje hosty do pliku host.deny, w pełni konfigurowalne i zadziwiająco skuteczne.

blokowanie

Drugim rozwiązaniem, takim mniej fajnym, jest firewall. Konfiguracja jest prosta, łatwa i przyjemna, ale jak widać poniżej poza najprostszymi regułami zezwól/zabroń niewiele zrobimy.

firewall

A problem jest, i to poważny, w momencie gdy używamy własnego serwera DNS. Aktualnie najpopularniejszym atakiem w sieci na serwery nazw jest DNS Aplification. Przy takim ataku nie jesteśmy ofiarami, jesteśmy współudziałowcami. Objawia się takimi wpisami w logu:

26-Sep-2013 13:12:14.649 security: client 180.210.203.237#25345 (isc.org): query (cache) ‘isc.org/ANY/IN’ denied
26-Sep-2013 13:12:15.669 queries: client 180.210.203.237#25345 (isc.org): query: isc.org IN ANY +ED (192.168.0.200)
26-Sep-2013 13:12:15.670 security: client 180.210.203.237#25345 (isc.org): query (cache) ‘isc.org/ANY/IN’ denied
26-Sep-2013 13:12:16.684 queries: client 180.210.203.237#25345 (isc.org): query: isc.org IN ANY +ED (192.168.0.200)
26-Sep-2013 13:12:16.684 security: client 180.210.203.237#25345 (isc.org): query (cache) ‘isc.org/ANY/IN’ denied
26-Sep-2013 13:12:17.702 queries: client 180.210.203.237#25345 (isc.org): query: isc.org IN ANY +ED (192.168.0.200)
26-Sep-2013 13:12:17.702 security: client 180.210.203.237#25345 (isc.org): query (cache) ‘isc.org/ANY/IN’ denied
26-Sep-2013 13:12:18.715 queries: client 180.210.203.237#25345 (isc.org): query: isc.org IN ANY +ED (192.168.0.200)
26-Sep-2013 13:12:18.740 security: client 180.210.203.237#25345 (isc.org): query (cache) ‘isc.org/ANY/IN’ denied

Denied wcale nie oznacza że jest ok, dopiero drop na zaporze rozwiązałby problem. Przeciwdziałać można więc na dwa sposoby, dodając atakujące podsieci do “zabroń” w zaporze (ręcznie, czyli na dłuższą metę nie do opanowania) lub filtrując stringi z popularnymi zapytaniami takimi jak np. isc.org.

DiskStation> cd /lib/iptables
DiskStation> ls
libip6t_LOG.so        libipt_LOG.so         libipt_icmp.so        libxt_multiport.so    libxt_tcp.so
libip6t_icmp6.so      libipt_MASQUERADE.so  libxt_MARK.so         libxt_standard.so     libxt_udp.so
libipt_DNAT.so        libipt_REDIRECT.so    libxt_limit.so        libxt_state.so

Niestety, to tyle, więcej modułów iptables w DSM nie znajdziemy, bardziej inteligentne filtrowanie nie jest możliwe. W moim przypadku oznaczało to, że po dwóch miesiącach poddałem się i przeniosłem swoje usługi DNS do zewnętrznego hostingu. Bywa Uśmiech

Na pocieszenie mogę powiedzieć, że do bezpieczeństwa usług typu http/https/dav/ssh/poczta nie mogę się przyczepić, wszystko jest ok.

P.S. Istnieje możliwość, że wyższe modele Synology są dostarczane z bardziej rozbudowaną wersją DSM, ale to już ktoś musiałby potwierdzić.

Oceń ten artykuł:
[Total: 1 Average: 5]

Dodaj komentarz

Required fields are marked *.