- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

В 2023 году Одноклассники пресекли более 9 млн подозрительных входов в учетные записи
И выявили более 7 млн подозрительных пользователей
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Есть сервер, на котором находится критически важная информация. Необходимо полностью закрыть все входящие соединения на все порты, кроме SSH соединений c нескольких доверенных IP.
Сервер на убунте. После недолгого гугления было найдено примерно такое решение
ufw disable
ufw default deny
ufw allow proto tcp from 192.168.0.1 to any port 22
ufw allow proto tcp from 192.168.0.2 to any port 22
ufw allow proto tcp from 192.168.0.3 to any port 22
ufw enable
По идее закроет все, кроме SSH для трех IP.
Буду рад конструктивной критике\советам.
ЗЫ - сухое "да, так можно" тоже пойдет - неохота эксперементировать и заблокировать сервер.
Не забивайте себе голову убогими ufw и csf
Используйте правильный фаервол iptables.
На iptables это делается в 2 строчки
iptables –I INPUT –s вашIP –j ACCEPT
iptables –A INPUT –j DROP
Поддерживаю сказанное zexis, чем вас не устраивает iptables?
iptables –I INPUT -p tcp --dport 22 –s 192.168.0.1 –j ACCEPT
iptables –I INPUT -p tcp --dport 22 –s 192.168.0.2 –j ACCEPT
iptables –I INPUT -p tcp --dport 22 –s 192.168.0.3 –j ACCEPT
iptables -P INPUT DROP
Не забивайте себе голову убогими ufw и csf
Используйте правильный фаервол iptables
Поддерживаю сказанное zexis, чем вас не устраивает iptables?
Не то, чтобы iptables меня не устраивал, я просто "не админ", гугл подсказал массу вариантов, ufw был самым простым навскидку.
Ок, спасибо, попробую юзать iptables :)
Если сервер удалённый, а доступ из разных мест - есть риск, что провайдер клиента сменит IP (или клиент сменит провайдера) и будет большой облом.
Сходу приходит в голову сделать SSH доступ не по паролю (пароли запретить), а по ключам и перевесить SSH на другой порт, только который и будет открыт, но для всех IP. Имхо, так будет ни чуть не менее секурно (если не больше), но без риска остаться без доступа.
мудрость веков. перед выполнением iptables -P INPUT DROP убедитесь, что имеете альтернативный доступ к серверу (KVM-over-IP, etc.) :D
мудрость веков. перед выполнением iptables -P INPUT DROP убедитесь, что имеете альтернативный доступ к серверу (KVM-over-IP, etc.) :D
iptables-apply
Если сервер удалённый, а доступ из разных мест - есть риск, что провайдер клиента сменит IP (или клиент сменит провайдера) и будет большой облом.
IP офисного инета и домашнего не менялись уже года два точно, хотя конечно завтра это все таки может произойти.
На этот случай (и на случай, если срочно нужно будет зайти на сервер с левого IP) есть несколько VPS, которые юзаются под разные мелкие проекты и имеют свои фиксированные IP.
Ну, а если уж на всех моих VPS, офисном и домашнем инете мне внезапно поменяют IP - то тогда уже очевидно KVM :)
мудрость веков. перед выполнением iptables -P INPUT DROP убедитесь, что имеете альтернативный доступ к серверу (KVM-over-IP, etc.)
iptables-apply
Вначале попрактикуюсь на "кошках" - на локальном сервере :)
После практики на кошках выяснился неожиданный нюанс - блокирование работает не совсем так, как я предполагал - оно обрубает вообще весь трафик вне зависимости от того, кто инициировал соединение.
В целом - логично, круто и правильно - но для меня это уже перебор и только добавляет проблем.
Мне нужно, чтобы
- никто кроме разрешенных IP не мог открыть соединение с сервером
- софт на сервере мог соединятся с любым IP и после установки соединения обмениваться любыми пакетами.
Грубо говоря, на сервере будет находиться сервис для работы со сторонними API, хочется сделать из сервера что-то вроде защищенного "черного ящика" - чтобы никто не взломал его, но и чтобы не обновлять для каждого нового API список доступных IP.
Получиться ли это сделать с помощью iptables?
АПДЕЙТ - я имею в виду, что когда я делаю ping 8.8.8.8 то не могу пропинговать его, пока не добавлю в IPtables, а я хочу открыть исходящие куда угодно, а входящие только для себя.
пробовал добавить
iptables -P OUTPUT ACCEPT
не помогло.
текущая схема
iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- google-public-dns-a.google.com anywhere
ACCEPT all -- IP1 anywhere
ACCEPT all -- ip2 anywhere
ACCEPT all -- ip3 anywhere
ISPMGR all -- anywhere anywhere
DROP all -- anywhere anywhere
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ISPMGR all -- anywhere anywhere
Chain ISPMGR (2 references)
target prot opt source destination
---------- Добавлено 10.04.2013 в 19:49 ----------
Попробовал поиграться с ufw - действительно глючная зараза :)
вроде все просто, но так и не настроил как надо.
В конечном итоге нашел в ISP Manager FireWall то что надо - включил закрытый режим + разрешил со своих IP трафик на все порты. :)