Search the Community
Showing results for tags 'security'.
-
Цель: организовать интернет здорового человека на конечных устройствах (нас, пк, ноуты, телефоны) оптимальным вариантом по простоте и скорости настройки. Краткий roadmap документа: 1. Выбор и покупка VPS 2. Установка OpenVPN на VPS 3. Подключение клиентов 4. Tips & Triks 5. Ссылки "И сказал он: Поехали! " 1. Выбор и покупка VPS На самом деле вариантом VPS с Linux на борту масса, другое дело что их придется поискать. Из зарубежных можно рекомендовать https://www.digitalocean.com/, https://www.vultr.com/, https://www.ovh.com/, https://www.arubacloud.com, ну или поискать на https://lowendbox.com. Не реклама, не претендую на истину в последней инстанции, вполне возможны варианты лучше приведенных. Я воспользовался VPS от arubacloud.com за 1 € (1 vcore, 20 ssd, 1 gb ram, 2 tb inet) расположенной в Италии. После оплаты и проверки платежа, VPS будет доступна через некоторое время. Из предлагаемых ОС я выбрал Ubuntu, манов на русском/английском как настроить OpenVPN на эту систему достаточно. 2. Установка OpenVPN на VPS Подготовка Первым делом сменим пароль суперпользователя root ( и запомним его :)): passwd root Обновим источники приложений и операционную систему до актуального состояния apt-get update apt-get upgrade Установим консольную утилиту Easy-RSA для генерации сертификата сервера и сертификатов для каждого из клиентов, которые будут использоваться для подключения: apt-get install easy-rsa cd /usr/share/easy-rsa nano ./vars Задаем переменную длины ключа: export KEY_SIZE= 1024 Это стандартное значение. Если требуется повышенная безопасность, то можно установить значение 2048. Однако следует помнить, что нагрузка на сервер будет изменяться пропорционально этому значению.Остальные параметры заполняются в соответствие с вашими пожеланиями, например export KEY_COUNTRY="RU" export KEY_PROVINCE="RU" export KEY_CITY="Moscow" export KEY_ORG="MyCompany LTD." export KEY_EMAIL="your_email_address" Включаем использование наших переменных source ./vars Очищаем папку с ключами ./clean-all Генерируем корневой сертификат. В процессе генерации утилита будет использовать уже указанные нами данные в переменных, поэтому нажимаем Enter на все вопросы. ./build-ca Генерируем таким же образом сертификат сервера. Отвечаем Y на запрос о подписывании сертификата. ./build-key-server server Теперь генерируем сертификаты для каждого устройства, которое планируется подключать к серверу. Повторяем команду нужное количество раз, изменяя имя сертификата (в примере сертификат называется macbook) ./build-key macbook Генерируем ключ Диффи-Хеллмана: ./build-dh В результате в папке /usr/share/easy-rsa/keys у нас теперь лежат наши сертификаты и ключи. Установка OpenVPN Ставим vpn: apt-get install openvpn Для версии 2.4-2.5 Если нужна поддержки новых опций таких как tls-crypt, lz4-v2 и прочего, нужно ставить версию 2.4. В репо Ubuntu по умолчанию только 2.3. Правда, к сожалению, эти опции не поддерживаются клиентом Syno, или я просто не смог до конца разобраться как их запустить. Hide Копируем все наши сгенерированные сертификаты и ключи: mkdir /etc/openvpn/keys cp -R /usr/share/easy-rsa/keys/ /etc/openvpn/keys Мы сконфигурируем сервер таким образом, чтобы при подключении к нему с любого устройства весь интернет-трафик заворачивался в туннель и таким образом сменим собственный IP-адрес на IP-адрес нашего VPS. Повышенная секурность Для большей секурности предлагаю создать отдельного, не привилегированного пользователя для запуска службы: adduser --system --shell /usr/sbin/nologin --no-create-home ovpn ( по выбору ) groupadd ovpn ( по выбору ) usermod -g ovpn ovpn Hide Сгенерировать и дать правильные права на чтение ключу ta.key Положить его в папку /etc/openvpn/keys cd /etc/openvpn/keys openvpn --genkey --secret ta.key chmod 544 ta.key Вносим в файл конфигурации сервера openvpn следующие строки: nano /etc/openvpn/server.conf Конфиг сервера # #General # port 1194 #порт OpenVPN сервера proto tcp #протокол на котором он работает, есть вариант с udp dev tun #тип тунеля, бывает еще и tap user ovpn #наш пользователь созданный выше group ovpn #группа нашего пользователя persist-key persist-tun status /var/log/openvpn-status.log #логи log /var/log/openvpn.log #логи verb 3 #уровень детализации логов # #Encryption # auth SHA256 #Тут и ниже параметры шифрования и алгоритмы которые используются tls-server tls-auth /etc/openvpn/keys/ta.key 0 key-direction 0 cipher AES-256-CBC ca /etc/openvpn/keys/ca.crt #Пути до ранее сгенерированных ключей и сертификатов cert /etc/openvpn/keys/vanish.crt key /etc/openvpn/keys/vanish.key dh /etc/openvpn/keys/dh1024.pem mssfix 0 #удаление отпечатков браузера comp-lzo adaptive # #Network # server 10.100.0.0 255.255.255.0 #подсеть из которой будут выдаваться ip клиентам ifconfig-pool-persist ipp.txt #когда клиент подключается, здесь появится запись, так же можно прописать конкретный ip push "redirect-gateway def1" #для пропуска трафика через шлюз push "dhcp-option DNS 8.8.8.8" #наши новые DNS сервера push "dhcp-option DNS 8.8.4.4" keepalive 10 120 Hide Теперь необходимо настроить наш VPS в режим работы маршрутизатора, включаем форвардинг: nano /etc/sysctl.conf убрать комментарий (#) на строке: net.ipv4.ip_forward = 1 Включаем трансляцию адресов чтобы клиенты изнутри могли ходить в интернет через наш VPS: iptables -t nat -A POSTROUTING -s 10.100.0.0/24 -o eth0 -j MASQUERADE Чуть позже нужно добавить правило для нормально работы сервисов syno: iptables -A PREROUTING -d ___ip адрес vps____/32 -p tcp -m multiport --dports 80,443,5000,5001(список всех необходимых портов через запятую) -j DNAT --to-destination ___ip_syno_из подсети___ 10.100.0.0/24 Для того чтобы тунель не определяли по обратному пингу я еще блокирую icmp: Iptables -A INPUT -p icmp -m icmp –icmp-type 8 -j REJECT --reject-with icmp-port-unreachable Если куплено доменное имя, то у хостера нужно подправить записи A на ip нашего VPS Это базовый минимум из того что нужно для повседневной работы. Творчество приветствуется. Посмотреть что наворотили можно так: Iptables –vnl Iptables –t nat –vnL Чтобы созданное нами правило пропуска трафика не удалилось после перезагрузки сервера установим пакет iptables-persistent: apt-get install iptables-persistent dpkg-reconfigure iptables-persistent При установке на вопрос о сохранении текущих правил IPv4 отвечаем утвердительно. Стартуем сервер: systemctl start openvpn systemctl status openvpn Вывод нормальной работы Просмотр логов Если интересно смотреть что происходит при старте, можно в отдельном терминале запустить tail –f /var/log/openvpn.log до запуска systemctl start openvpn Hide 3. Настройка клиентов Приступаем к настройке со стороны клиента. Вне зависимости от используемой операционной системы нам всего лишь требуется несколько файлов: корневой сертификат сервера (ca.crt), персональный сертификат клиента и соответствующий ему ключ (macbook.crt и macbook.key), ключ шифрования сессии (ta.key), а также конфигурационный файл для клиента. Первые три файла у нас уже есть на сервере в папке /etc/openvpn/keys - их можно легко скачать с сервера с помощью SFTP или WinSCP. А вот конфигурационный файл нам нужно создать вручную. Создаем на компьютере-клиенте отдельную папку и помещаем туда сертификаты. Затем создаем конфиг для клиента с любым именем и расширением ovpn: Конфиг файл клиента .ovpn сlient dev tun proto tcp remote __ip vps___ 1194 auth SHA256 cipher AES-256-CBC resolv-retry infinite nobind persist-key persist-tun comp-lzo verb 3 mssfix 0 tls-client tls-auth ta.key 1 remote-cert-tls server key-direction 1 ns-cert-type server Hide Сохраняем файл и устанавливаем клиентское приложение. Вариантов множество - для Windows и Linux лучше использовать официальное приложение, которое можно скачать по ссылке https://openvpn.net/index.php/open-source/downloads.html. После установки клиента для Windows достаточно лишь скопировать конфигурационный файл и сертификаты в папку C:\Program Files\OpenVPN\config и запустить подключение. На Android есть два нормальных клиента – OpenVPN Connect (простой интерфейс, быстрая настройка) и OpenVPN для Android – тут выбор тюнинга побогаче. Работают оба стабильно, если сеть меняется с WiFi на сотовую – переключаются корректно. Операция установки аналогична на windows, скормить ovpn, скормить сетрификаты/ключи. А теперь самая мякотка – подключить это все в synology. Xpenology. На готове должны быть ключи, сертификаты, работающий сервер с настройками приведенными выше и доступ по ssh к xpenology. Панель управления – Сеть – Сетевой интерфейс – Создать профиль VPN. К сожалению web-интерфейс рассчитан только на создание подключения с парольной аутентификацией ( и такие сертификаты можно сделать, разница от наших – вводить каждый раз пароль при подключении, что утомительно, но секурнее) Нас же интересует аутентификация по сертификату. Поэтому заполняем предложенные поля любыми данными: *протокол - TCP Щелкаем далее, и устанавливаем следующие настройки: Подключаемся к xpenology по SSh. Затем нам будет необходимо поправить созданный автоматически файл /usr/syno/etc/synovpnclient/openvpn/client_oXXXXXXXXXX. У меня установлен mc, а гуру vi могут это сделать прямо в консоли, остальным может быть удобно скопировать файл к себе в папку общего доступа и отредактировать файл там с использованием более привычных инструментов. При редактировании файла обратите внимание что у Linux и windows разные подходы к обозначению конца строки, поэтому используйте текстовый редактор который сможет сохранить файл в привычном xpenology формате. Конфиг клиента Xpenology В моем случае файл конфигурации выглядит следующим образом: dev tun^M proto tcp^M remote ___ip_VPS___ 1194^M auth SHA256^M cipher AES-256-CBC^M resolv-retry infinite^M nobind^M persist-key^M persist-tun^M comp-lzo^M verb 3^M mssfix 0^M tls-client^M remote-cert-tls server^M key-direction 1^M ns-cert-type server^M ^M up /usr/syno/etc.defaults/synovpnclient/scripts/ovpn-up route-up /usr/syno/etc.defaults/synovpnclient/scripts/route-up redirect-gateway script-security 2 plugin /lib/openvpn/openvpn-down-root.so /usr/syno/etc.defaults/synovpnclient/scripts/ip-down ca ca.crt key ___имя_клиента__.key cert __имя_клиента__.crt tls-auth ta.key 1 Затем с помощью команды mkdir создаем директорию keys в директории /usr/syno/etc/synovpnclient/openvpn/ куда и положим с помощью команды cp имеющиеся у нас файлы сертификатов и ключи от них. С помощью этой же команды необходимо скопировать измененный файл конфигурации обратно в соответствующую директорию. Hide Для того чтобы подключиться к серверу OpenVPN необходимо зайти в Панель управления – Сеть – Сетевой интерфейс, выбрать созданное нами подключение и нажать на кнопку «Подключить» Результат: Все сервисы, в том числе которые в докере/виртуалбоксе будут работать, если вы не забыли указать порты в правилах выше. Доступ к NAS извне будет только через сервер в Италии/Чехии, т.е. увеличится пинг. Заметно. Скорость скачивания торрентов убавится, но зато Ваш провайдер не будет знать чем занимается Ваш NAS. Доступ по локальной сети через Ваш роутер (по адресам вида 192.168.1.ХХ или 192.168.0.ХХ) должен остаться. Даже если в цепочке ноут - NAS у обоих запущен клиент OpenVPN трафик не должен пойти через VPS а напрямую. Таким образом мы сохраним скорость доступа максимально внутри Вашей локальной сети. После подключения и некоторых шаманств с временем (через отдельное приложение в браузере) можно добиться такого результата: Тест думает что мы действительно в Италии. 4. Tricks & Tips Если будем давать пользоваться друзьям то можно сделать подключение проще и красивее. Вместо передачи 4 файлов можно сделать 1. Для этого нужно открыть сгенерированный ранее фалй .ovpn для товарища, и привести его к виду Измененный конфигурационный файл основная часть настроек без изменений ниже добавляем: <tls-auth> -----BEGIN OpenVPN Static key V1----- скопировать данные из файла ta.key -----END OpenVPN Static key V1----- </tls-auth> <ca> -----BEGIN CERTIFICATE----- скопировать данные из файла ca.crt -----END CERTIFICATE----- </ca> <cert> -----BEGIN CERTIFICATE----- скопировать данные из файла имя_клиента.crt -----END CERTIFICATE----- </cert> <key> -----BEGIN PRIVATE KEY----- скопировать данные из файла имя_клиента.key -----END PRIVATE KEY----- </key> Hide И сохранить. Таким образом мы интегрировали необходимые ключи и сертификаты в файл настроек клиента. Теперь для подключения нужно передать только один файл .ovpn Если ранее сгенерированные ключи больше не требуется, их надо правильно отключить. Иначе если кто-нибудь их сможет получить – то будет иметь возможность подключаться к вашему серверу. Отзываем сертификат: cd /usr/share/easy-rsa/ source ./vars ./revoke-full ___имя_клиента__ Созданный файл положить в /etc/openvpn/keys/crl.pem В файле конфигурации openvpn сервера добавить строку crl-verify /etc/openvpn/keys/crl.pem И сделать рестар Systemctl restart openvpn Для удобства отлова проблем при подключении не забываем делать в отдельных консолях: tail -f /var/log/openvpn.log tail -f /var/log/openvpn-status.log 5. Используемые материалы https://habr.com/post/233971/ https://community.vscale.io/hc/ru/community/posts/209661629-Установка-и-первичная-настройка-OpenVPN-на-Ubuntu-16-04 https://docs.openvpn.net/ https://habr.com/post/216197/ https://www.linode.com/docs/networking/vpn/set-up-a-hardened-openvpn-server/#client-configuration-file
-
Multiple vulnerabilities allow remote attackers to conduct denial-of-service attack or execute arbitrary code via a susceptible version of Synology DiskStation Manager (DSM), Synology Router Manager (SRM), VPN Plus Server or VPN Server. More information: https://www.synology.com/en-us/security/advisory/Synology_SA_21_24
-
GeoIP Region Blocking using Synology Firewall I noticed internet performance issues today and was checking my router logs, I found excessive logs showing: Jun 18 20:55:48 dropbear[5405]: Child connection from <My Synology IP>:40894 Jun 18 20:55:49 dropbear[5405]: Exit before auth: Exited normally Jun 18 20:55:49 dropbear[5411]: Child connection from <My Synology IP>:40896 Jun 18 20:55:51 dropbear[5411]: Exit before auth: Exited normally I searched and found it was related to numerous invalid login attempts to the synology login page. This lead me to login to the cli of my synology and check logs for failed attempts. When checking the logs I found the most concerning log was /var/log/httpd/apache22-error_log 2018-06-18T19:28:42-06:00 nas [Mon Jun 18 19:28:42 2018] [error] [client 193.106.30.99] File does not exist: /var/services/web/wp-rdf.php 2018-06-18T20:11:16-06:00 nas [Mon Jun 18 20:11:16 2018] [error] [client 27.29.158.10] script not found or unable to stat: /var/services/web/login.cgi 2018-06-18T21:51:26-06:00 nas [Mon Jun 18 21:51:26 2018] [error] [client 172.18.0.2] File does not exist: /var/services/web/apple-touch-icon-precomposed.png 2018-06-18T21:51:26-06:00 nas [Mon Jun 18 21:51:26 2018] [error] [client 172.18.0.2] File does not exist: /var/services/web/apple-touch-icon.png 2018-06-18T21:51:26-06:00 nas [Mon Jun 18 21:51:26 2018] [error] [client 172.18.0.2] File does not exist: /var/services/web/apple-touch-icon-precomposed.png This lead me to consider blocking all geographical regions except my own. Most brute force attempts and vulnerability attacks are outside of my home country, this will reduce the attack surface significantly. My first attempt at implementing the geoip blocking was problematic, I attempted a "deny all" entry after the "allow local network range" and "allow my region" rules, but this ended up blocking all access to the services I had running. I thought I'd share how I implemented it for others wanting to reduce the surface area for attacks. Enable firewall Open Control Panel Select Connectivity -> Security Go to Firewall tab Check Enable firewall Add "Allow" Rules for internal network Select Edit Rules for the default Firewall Profile (Disregard existing rules in screen shot, these will be created in the following steps) Create rule to allow your internal/home network Add "Allow" Rules for your country/countries Create rule to allow specific locations Set network interface to deny if rules are not matched Select the network interface that is default to your synology (mine is LAN 1, you can find your interface under Connectivity -> Network -> Network Interface) ***This was the secret to getting the deny all after the allow rules to work*** Set "if no rules were matched: Deny Access" Click OK and Apply Test reaching your synology on your internal network and from external networks in your region. You can also validate if the firewall is blocking by using a Tor browser to send traffic from a different country to see if your firewall rules are working properly.
-
Synology NAS systems are - along with QNAPs - currently the target of a wide brute-force attack. A botnet tries to break in via weak passwords and infects the system with ransomware. Once infected, it encrypts all files and data. This affects systems which are reachable over the internet (open firewall ports / NAT). To protect yourself you should - activate the DoS protection including account blocking - apply strong password rules to all users - create a new admin account with a strong password and disable the standard „admin“ account More informations: https://www.synology.com/en-global/company/news/article/2019JulyRansomware
- 14 replies
-
- 1
-
This affects users who have their NAS exposed to the internet (NAT, open ports). It‘s fixed in DSM 6.2.3-25426-3 . Description Multiple vulnerabilities allow remote attackers to execute arbitrary code via a susceptible version of DiskStation Manager (DSM). https://www.synology.com/en-global/security/advisory/Synology_SA_20_26
-
The guys from ESET presented a new WiFi vulnerability named „kr00k“. It affects millions of devices with chips from Broadcom and Cypress. More informations: https://www.zdnet.com/article/new-kr00k-vulnerability-lets-attackers-decrypt-wifi-packets/
-
Multiple vulnerabilities allow remote authenticated users to execute arbitrary commands or conduct denial-of-service attacks, or allow remote attackers to delete arbitrary files via a susceptible version of DiskStation Manager (DSM). Note: Synology recommends to update DSM to 6.2.2-24922-4. Before updating please check the updates report section. If your system is not open to the internet (NAT, port forwarding, QuickConnect, etc.) you should be safe. Further infos on Synology website.
-
CVE-2019-9511, CVE-2019-9513 and CVE-2019-9516 allow remote attackers to conduct denial-of-service attacks via a susceptible version of DiskStation Manager (DSM). Further informations: https://www.synology.com/en-global/security/advisory/Synology_SA_19_33
-
I just noticed a new notification when I logged in to 1 of my NAS'es. A N54L running DSM 5.2-5967 Update 9, after an update from -8 11 days ago. When checking with the Security advisor, I was getting the message in the screendump, telling me : "DSM system files have been modified unexpectedly" Checking another NAS, with the same config, updated at the same time, same message. The BIG question I have, has anyone else seen this? (and, what/how/why... )
-
Here's Synology's actual information about Meltdown/Spectre: https://www.synology.com/en-us/support/security/Synology_SA_18_01