Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Оплата
Новости
Доставка
Загрузки
Форум
Настройка
    info@proxmox.su
    +7 (495) 320-70-49
    Заказать звонок
    Аспро: ЛайтШоп
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Аспро: ЛайтШоп
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Аспро: ЛайтШоп
    Телефоны
    +7 (495) 320-70-49
    Заказать звонок
    0
    0
    0
    Аспро: ЛайтШоп
    • +7 (495) 320-70-49
      • Назад
      • Телефоны
      • +7 (495) 320-70-49
      • Заказать звонок
    • info@proxmox.su
    • Москва, Бакунинская улица, 69с1
    • Пн-Пт: 09-00 до 18-00
      Сб-Вс: выходной
    • 0 Сравнение
    • 0 Избранное
    • 0 Корзина
    Главная
    Форум
    Proxmox Виртуальная Среда
    некоторые примеры жесткого ограничения для PVE на публичном IP

    Форумы: Proxmox Виртуальная Среда, Proxmox Backup Server, Proxmox Mail Gateway, Proxmox Datacenter Manager
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    некоторые примеры жесткого ограничения для PVE на публичном IP, Proxmox Виртуальная Среда
     
    escoreal
    Guest
    #1
    0
    02.11.2013 12:47:00
    Привет, я настроил полупараноидальную (но легко реализуемую) конфигурацию для 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 - расширь правила файервола
     
     
     
    furioussnail
    Guest
    #2
    0
    13.09.2017 17:33:00
    Вот как защита через непрозрачность оказывается под угрозой: nmap -sV <hostname/ip> Кстати, запуск SSH на неприпевилегированном порту — это плохая идея. Если вы запускаете его на привилегированном порту, вы знаете, что это сделал root. В противном случае вы не уверены, кто это запустил.
     
     
     
    Alessandro 123
    Guest
    #3
    0
    13.09.2017 21:37:00
    Он написал "skipt-kiddies" не зря: скрипт-киды неспособны использовать nmap для обнаружения реального порта ssh. Они просто запускают первый скрипт, найденный в сети, и на этом всё. Я неоднократно страдал от bruteforce ssh, круглосуточно. После смены порта ssh с 22 на что-то другое, эта атака внезапно прекратилась. В любом случае, я считаю, что PVE должен автоматически устанавливать некоторые настройки безопасности при свежей установке, например, отключать сервер NFS, если он не нужен, использовать fail2ban с хотя бы парами стандартных правил и так далее. Безопасности никогда не бывает слишком много.
     
     
     
    furioussnail
    Guest
    #4
    0
    13.09.2017 21:41:00
    Я уверен, что скрипт-кидды различаются по уровню навыков. Кроме того, в сети есть не только скрипт-кидды. Почему бы не ограничить доступ к SSH через брандмауэр? Это было бы гораздо более грамотным подходом. Обычно лучший вариант — предоставить систему в максимально "чистом" виде, но также обеспечить хорошую документацию. Я постараюсь придумать что-то и размещу это, когда будет время. Но я не обещаю. fail2ban не всегда лучший вариант...
     
     
     
    Alessandro 123
    Guest
    #5
    0
    13.09.2017 21:46:00
    Потому что иногда нужно получить доступ к SSH с нескольких соединений.
     
     
     
    furioussnail
    Guest
    #6
    0
    13.09.2017 21:48:00
    Вы можете использовать порт-нокинг. Но лучший подход — это использовать VPS в качестве точки доступа, и ещё лучше в сочетании с VPN. Доступ должен быть разрешен только с VPN или VPS. По крайней мере, это кажется более разумным в тот момент, когда вы начинаете развивать инфраструктуру.
     
     
     
    Alessandro 123
    Guest
    #7
    0
    13.09.2017 21:54:00
    Не всегда возможно избежать дополнительных точек отказа. Если ваш VPS падает по любым причинам, вы полностью теряете доступ в сеть. Как я уже писал, изменив порт ssh, я немедленно остановил любые атаки грубой силы. Да, есть и другие подходы, но это простое и эффективное решение.
     
     
     
    furioussnail
    Guest
    #8
    0
    13.09.2017 22:02:00
    Я только что предложил более безопасный подход. Проще фильтровать трафик через один сервер, чем делать это на каждом узле. По крайней мере, когда у вас есть инфраструктура из нескольких узлов. В основном я хотел подчеркнуть, почему запуск привилегированного процесса на неприемлемом порту — плохая идея. Но это не конец света. Просто мое мнение.
     
     
     
    guletz
    Guest
    #9
    0
    14.09.2017 16:29:00
    Привет, лучшее решение — оставить ssh на порту 22. Но ты можешь создать правила iptables, которые будут перенаправлять любой входящий трафик с порта X (X > 1024) на порт 22/ssh (localhost). И, конечно, порт 22 должен быть закрыт от Интернета/WAN.
     
     
     
    guletz
    Guest
    #10
    0
    14.09.2017 16:33:00
    Лучше всего будет поставить отдельный маршрутизатор (можно использовать какие-нибудь недорогие устройства) перед вашим кластером/nodes Proxmox. На этом маршрутизаторе можно настроить всё необходимое для хорошего файрвола (включая чёрные списки, защиту от брутфорса и так далее). Возможно, IDS/HIDS тоже будет полезен. Всё это зависит от ценности ваших данных/услуг.
     
     
     
    Страницы: 1
    Читают тему
    +7 (495) 320-70-49
    info@proxmox.su

    Конфиденциальность Оферта
    © 2026 Proxmox.su
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры