Комментарии 32
if ($host !~ ^(example.com|www.example.com|docs.example.com)$ ) {
return 444;
}
Не лучше ли как-то так?
server {
listen 80 default_server;
listen 443 ssl default_server;
return 444;
}
тогда уж для 443 лучше так
server {
listen 443 default_server ssl;
listen [::]:443 default_server ssl;
ssl_certificate /etc/certs/ssl-cert-snakeoil.pem;
ssl_certificate_key /etc/certs/ssl-cert-snakeoil.key;
ssl_session_tickets off;
return 444;
}
Это детали настройки NGINX, у меня на моем сервере так и настроено как указано у вас:
server {
listen 443 ssl;
listen [::]:443 default_server ssl;
ssl_certificate /ssl/nginx.crt;
ssl_certificate_key /ssl/nginx.key;
ssl_session_tickets off;
access_log /var/log/nginx/data-access.log combined;
return 444;
location / {
proxy_pass XXXX;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_redirect http:// https://;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_read_timeout 20d;
proxy_buffering off;
}
}Спасибо большое!
ещё, можно избавиться от процессов docker-proxy, поместив в (или создав) файл /etc/docker/daemon.json
{
"userland-proxy": false
}
ну, а чтобы не светить портом 9090 наружу, проще при запуске докер-контейнера вообще не публиковать этот порт, раз всё равно доступ к нему только из контейнера nginx
Не проще запретить все входящие соединения, а потом разрешить только на нужные порты? Не установлен fail2ban.
Да, это вообще best-practies. Цель открытых и закрытых портов средствами iptables показан как раз для того, чтобы новички имели представление, как это работает. Соглашусь, что лучше закрыть всё, кроме избранного.
Ещё лучше сразу внушить новичкам, что все сервисы, не предназначенные для сторонних глаз должны перенастраиваться слушать не 0.0.0.0, а 127.0.0.1 (или любой из 127.0.0.0/8 адресов в случае разделения совпадающих портов). Не выводить наружу внутренние сервисы изначально - это реально best practice.
Использование же файрвола должно быть уже частью тюнинга - например разрешить извне доступ к порту базы данных только с IP ваших других серверов, предназначенных для репликации БД.
Если хочется безопасности и удобства, то первый шаг после покупки VPS это установка ОС с образа загруженного с debian.org, ubuntu.com,...
Токсичный комментарий, не раскрывающий ничего
Наверное, человек выше имеет ввиду что Вы получите чистую систему без доп.сервисов от провайдера (qemu-guest-agent и другие сервисы для управления ВМ). Гарантированно "чистое" ядро.
Так же, некоторые хостинги добавляют собственные ssh-ключи, даже очень популярные это практиковали(Уловные, лет 7 назад в этом был замечен Firstvds).
Это все мои предположения, по поводу комментария Выше. Возможно автору комментария есть что добавить.
Да, как раз таки хочется не додумывать за автором комментария, а в чистой дискуссии обсудить выбор диструбутива.
А по поводу чистого ядра и системы - с Вами согласен. В принципе, ничего нет безопаснее того, что ты контролируешь сам, начиная от ОС, заканчивая железкой. Материал образовательный и для новичков как в плане хостинга серверов, так и в в принципе в карьере IT: подавал примеры на распространенные случаи, частые ошибки.
Многие поставщики услуг vps\vds и сейчас добавляют ключи, насколько знаю, для поддержки. И много где закрыта возможность через VMware и без этих ключей взять и настроить (на очень бюджетных хостингах и датацентрах)
В руководстве "VPS для чайников" в первой главе сказано, VPS - это в первую очередь компьютер подключенный к сети Интернет, поэтому сперва давайте ограничим доступ к нему из сети Интернет, а затем уже приступим к настройке, первая команда в консоле: # iptables -A INPUT -s <ваш IP> -p tcp -m tcp --dport 22 -j ACCEPT && iptables -A INPUT -j REJECT --reject-with icmp-proto-unreachable .
Но, тут оказывается, что покупая услугу VPS, практически у большинства популярных бюджетных хостинг-провайдеров, выполнив шаг 1(см выше) мы рискуем получить ошибку. Как, почему, откуда? Дело тут в том, что почти все массовые хостинг-провайдеры предоставляют модифицированные версии популярных ОС debian, ubuntu,.. например, там может быть и iptables, iptables-legacy, nftables, nft, ufw, firewalld, и все уже со своими "особенно правильными и удобными" предустановленными цепочками правил. Хорошо это или плохо - это отдельная статья. Но об этом нужно помнить "самым маленьким", потому, что если мы считаем что система уже скомпрометирована, то дальнейшие действия по безопасности бессмысленны.
Очень круто, спасибо за развернутый ответ! А можете, пожалуйста, поделиться ссылкой на подобные руководства для чайников? Я думаю, что читателям было бы полезно.
Про модифицированные версии согласен, очень много предустановленного ПО и нет возможности во многих бюджетных хостингах просто взять и поставить свой диструбутив - это боль. Изначально хотел писать статью про пользу развертывания со своей машины безопасного сервера, но не у всех есть белый IP-адрес, а ngrok я бы рекомендовал использовать людям на страх и риск :)
Мой сервис имеет базу данных, до которой тоже дошли злые руки ботов, которые пытаются подобрать пароли. Это видно по следующим логам:
С ужасом дочитал до конца статьи, а там подозрения подтвердились:
Извините за прямоту, но после такого все разговоры о безопасности надо заканчивать.
Зачем вы выставили базу данных голой ж открытым портом наружу?
Когда говорили про фаервол тоже не закрыли ее. Надеяться на pg_hosts не надо - никто не даст гарантий, что там нет бага. Рано или поздно он появится и вашу базу ломанут. Поэтому все внутрение сервисы должны слушать только на внутрненнем интерфейсе - чтобы даже ошибки конфигурации фаервола не открыли доступ. Наружу торчат только sshd и nginx.
Вы закрываете фаерволом ненужные порты (тот же 9090), а надо делать наоборот - закрыть все по умолчанию и открывать только нужные (22, 80, 443 и ничего больше).
Если хотите подключаться к базе с локального компьютера - пробрасывайте порт через ssh и работайте с ней.
Пример на скриншоте сделан ради примера. Сервер не реальный, а поднято в виртуальной среде. Как раз-таки для того, чтобы в образовательных целях показать, что есть определенные порты и необходимые нужно закрыть.
Вы закрываете фаерволом ненужные порты (тот же 9090), а надо делать наоборот - закрыть все по умолчанию и открывать только нужные (22, 80, 443 и ничего больше).
Вы точно читали текст после скриншота и точно ли понимаете грань между for example и реальными боевыми действиями?
Насколько понял, речь про то, что СУБД не должна торчать наружу в принципе. Вся работа с ней осуществляется только через ssh-туннель. И вот этого в статье не хватает как раз.
Вы точно читали текст после скриншота и точно ли понимаете грань между for example и реальными боевыми действиями?
Вы же понимаете, что запомнится именно большой абзац текста, картинка и команда, а не мелкая сноска в конце, что обычно делают наоборот.
Понимаете, слово "обычно" подразумевает, что можно и так и эдак. То есть фактически вы пишете: "Важно - можно делать по разному". Тем более нет пояснения почему это важно, в зависимости от чего надо выбирать? То есть на самом деле - это неважно.
В названии статьи стоило бы как-то упомянуть NGINX.
Супер! Добавил себе эту статью еще и на будущее
firewall-cmd --zone=public --add-service=http
firewall-cmd --zone=public --add-service=https
firewall-cmd --zone=public --add-service=http --permanent
firewall-cmd --zone=public --add-service=https --permanent
firewall-cmd --list-all
systemctl status nginx.service
systemctl enable --now nginx.service
cd /usr/share/nginx/html/
ls
mv /usr/share/nginx/html/index.html /usr/share/nginx/html/index1.html
Для шлюза:
setsebool -P httpd _can_network_connect 1
getsebool httpd _can_network_connect (проверить)
Заходим в /etc/nginx/nginx.conf
Находим строку, которая начинается с http и дописываем туда:
upstream backend {
least_conn;
server (ip адреса сервера);
server (ip адреса сервера);
}
Затем находим строку location / и пишем:
proxy_pass http://backend/;
Перезапускаем службу.
Создаем сертификат:
openssl genpkey -algorithm rsa -pkeyopt rsa_keygen_bits:2048 -out name.key
openssl req -new -key name.key -out name.key
Common Name name.key
openssl x509 -req -days 365 -in name.csr -signkey app.wsr -out name.crt
/etc/pki/tls/ (путь, где хранится сертификат)
cp name.key /etc/pki/tls/private/
cp name.crt /etc/pki/tls/certs/
Зайти в /etc/nginx/nginx.conf
Добавить:
listen 443 ssl http2 default_server;
server_name name.key www.name.key;
if (host$request_uri;
}
ssl_certificate "/etc/pki/tls/certs/name.crt";
ssl_certificate_key "/etc/pki/tls/private/name.key";
ss -tupln | grep nginx
Кибербезопасность для самых маленьких