Аспро: ЛайтШоп [тема: некоторые примеры жесткого ограничения для PVE на публичном IP]

некоторые примеры жесткого ограничения для PVE на публичном IP

Thu, 14 Sep 2017 16:33:00 +0300

некоторые примеры жесткого ограничения для PVE на публичном IP Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Лучше всего будет поставить отдельный маршрутизатор (можно использовать какие-нибудь недорогие устройства) перед вашим кластером/nodes Proxmox. На этом маршрутизаторе можно настроить всё необходимое для хорошего файрвола (включая чёрные списки, защиту от брутфорса и так далее). Возможно, IDS/HIDS тоже будет полезен. Всё это зависит от ценности ваших данных/услуг.
14.09.2017 16:33:00, guletz.

некоторые примеры жесткого ограничения для PVE на публичном IP

Thu, 14 Sep 2017 16:29:00 +0300

некоторые примеры жесткого ограничения для PVE на публичном IP Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Привет, лучшее решение — оставить ssh на порту 22. Но ты можешь создать правила iptables, которые будут перенаправлять любой входящий трафик с порта X (X > 1024) на порт 22/ssh (localhost). И, конечно, порт 22 должен быть закрыт от Интернета/WAN.
14.09.2017 16:29:00, guletz.

некоторые примеры жесткого ограничения для PVE на публичном IP

Wed, 13 Sep 2017 22:02:00 +0300

некоторые примеры жесткого ограничения для PVE на публичном IP Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Я только что предложил более безопасный подход. Проще фильтровать трафик через один сервер, чем делать это на каждом узле. По крайней мере, когда у вас есть инфраструктура из нескольких узлов. В основном я хотел подчеркнуть, почему запуск привилегированного процесса на неприемлемом порту — плохая идея. Но это не конец света. Просто мое мнение.
13.09.2017 22:02:00, furioussnail.

некоторые примеры жесткого ограничения для PVE на публичном IP

Wed, 13 Sep 2017 21:54:00 +0300

некоторые примеры жесткого ограничения для PVE на публичном IP Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Не всегда возможно избежать дополнительных точек отказа. Если ваш VPS падает по любым причинам, вы полностью теряете доступ в сеть. Как я уже писал, изменив порт ssh, я немедленно остановил любые атаки грубой силы. Да, есть и другие подходы, но это простое и эффективное решение.
13.09.2017 21:54:00, Alessandro 123.

некоторые примеры жесткого ограничения для PVE на публичном IP

Wed, 13 Sep 2017 21:48:00 +0300

некоторые примеры жесткого ограничения для PVE на публичном IP Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Вы можете использовать порт-нокинг. Но лучший подход — это использовать VPS в качестве точки доступа, и ещё лучше в сочетании с VPN. Доступ должен быть разрешен только с VPN или VPS. По крайней мере, это кажется более разумным в тот момент, когда вы начинаете развивать инфраструктуру.
13.09.2017 21:48:00, furioussnail.

некоторые примеры жесткого ограничения для PVE на публичном IP

Wed, 13 Sep 2017 21:46:00 +0300

некоторые примеры жесткого ограничения для PVE на публичном IP Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Потому что иногда нужно получить доступ к SSH с нескольких соединений.
13.09.2017 21:46:00, Alessandro 123.

некоторые примеры жесткого ограничения для PVE на публичном IP

Wed, 13 Sep 2017 21:41:00 +0300

некоторые примеры жесткого ограничения для PVE на публичном IP Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Я уверен, что скрипт-кидды различаются по уровню навыков. Кроме того, в сети есть не только скрипт-кидды. Почему бы не ограничить доступ к SSH через брандмауэр? Это было бы гораздо более грамотным подходом. Обычно лучший вариант — предоставить систему в максимально "чистом" виде, но также обеспечить хорошую документацию. Я постараюсь придумать что-то и размещу это, когда будет время. Но я не обещаю. fail2ban не всегда лучший вариант...
13.09.2017 21:41:00, furioussnail.

некоторые примеры жесткого ограничения для PVE на публичном IP

Wed, 13 Sep 2017 21:37:00 +0300

некоторые примеры жесткого ограничения для PVE на публичном IP Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Он написал "skipt-kiddies" не зря: скрипт-киды неспособны использовать nmap для обнаружения реального порта ssh. Они просто запускают первый скрипт, найденный в сети, и на этом всё. Я неоднократно страдал от bruteforce ssh, круглосуточно. После смены порта ssh с 22 на что-то другое, эта атака внезапно прекратилась. В любом случае, я считаю, что PVE должен автоматически устанавливать некоторые настройки безопасности при свежей установке, например, отключать сервер NFS, если он не нужен, использовать fail2ban с хотя бы парами стандартных правил и так далее. Безопасности никогда не бывает слишком много.
13.09.2017 21:37:00, Alessandro 123.

некоторые примеры жесткого ограничения для PVE на публичном IP

Wed, 13 Sep 2017 17:33:00 +0300

некоторые примеры жесткого ограничения для PVE на публичном IP Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Вот как защита через непрозрачность оказывается под угрозой: nmap -sV Кстати, запуск SSH на неприпевилегированном порту — это плохая идея. Если вы запускаете его на привилегированном порту, вы знаете, что это сделал root. В противном случае вы не уверены, кто это запустил.
13.09.2017 17:33:00, furioussnail.

некоторые примеры жесткого ограничения для PVE на публичном IP

Sat, 02 Nov 2013 12:47:00 +0400

некоторые примеры жесткого ограничения для PVE на публичном IP Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Привет, я настроил полупараноидальную (но легко реализуемую) конфигурацию для PVE на публичном IP. отключи NFS: Код: #vi "/etc/default/nfs-common" NEED_STATD=no Код: #update-rc.d rpcbind disable отключи IPv6: Код: #vi /etc/default/grub GRUB_CMDLINE_LINUX_DEFAULT="nomodeset ipv6.disable=1 quiet"

#vi /etc/postfix/main.cf inet_protocols = ipv4 fail2ban Код: #aptitude install fail2ban базовые правила файервола Код: #vi /etc/network/if-up.d/firewall

#!/bin/bash

# локально iptables -C INPUT -i lo -j ACCEPT 2> /dev/null || iptables -A INPUT -i lo -j ACCEPT

# установленный iptables -C INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT 2> /dev/null || iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# icmp iptables -C INPUT -p icmp --icmp-type echo-request -j ACCEPT 2> /dev/null || iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT

# ssh iptables -C INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT 2> /dev/null || iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT

# блокировка iptables -C INPUT -j DROP 2> /dev/null || iptables -A INPUT -j DROP доступ к серверу с логином root через ssh Код: cat .bash_profile |tail -n5 #############################################################################

# исключение из файервола iptables -C INPUT -s ${SSH_CLIENT%% *}/32 -j ACCEPT 2> /dev/null || iptables -I INPUT -s ${SSH_CLIENT%% *}/32 -j ACCEPT #############################################################################

cat .bash_logout ######################################################## # удаление исключения из файервола test $(netstat -an|grep ":22 " | grep ${SSH_CLIENT%% *} | wc -l) -le 1 && iptables -D INPUT -s ${SSH_CLIENT%% *}/32 -j ACCEPT ######################################################## вывод С этой конфигурацией у тебя будет работать только SSH с защитой от брутфорса (fail2ban) на публике. Чтобы управлять своим сервером, тебе нужно открыть сессию SSH под root. Не отключай NFS или IPv6, если они тебе нужны. советы для более параноидальной конфигурации: - отключи вход по паролю для SSH - используй VPN - используй порт-нокинг - измени порт SSH - расширь правила файервола
02.11.2013 12:47:00, escoreal.