Весь день мучаюсь, нужно настроить nginx, чтобы обрабатывал запросы https. Много раз одно и то же устанавливал по разным блого-инструкциям и сносил, так что nginx.conf по идее правильный. Наверное, проблема в порте: если написать
sudo nc -lp 80
на сервере и локально
curl -I *ip*
, то на сервер пишет, что кто-то подключиться попробовал. А если
sudo nc -lp 443
то есть именно ssl порт, то
curl -I *ip*:443
напишет «curl: (7) Failed to connect to 109.120.155.210 port 443: Нет маршрута до узла»
Система centos 7, порт я такой командой открывал:
С моего компа результат тот-же. На 80 порт соединение устанавливается, при попытке открыть соединение на 443 приходит отлуп про «Нет маршрута до узла». Похоже проблема действительно где-то в районе сервера.
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
Что в переводе на русский означает — сначала отбросить всё, а потом из оставшегося (после отбрасывания всего) пропустить то что направлено на порт 443. Улавливаешь?
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [53:6748]
-A INPUT -p tcp -m tcp --dport 80 -m state --state NEW -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
вот эти правила у тебя обрабатываются, а далее вот этим правилом:
-A INPUT -j REJECT --reject-with icmp-host-prohibited
ты блокируешь все входящие пакеты с указанием ответить, что соединение запрещено. И ниже этого правила вот эти правила:
-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -m state --state NEW,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
уже не обрабатываются.
Сделай вот так:
# Generated by iptables-save v1.4.21 on Sun Sep 27 01:02:42 2015
*raw
:PREROUTING ACCEPT [8072:4156393]
:OUTPUT ACCEPT [3966:856479]
COMMIT
# Completed on Sun Sep 27 01:02:42 2015
# Generated by iptables-save v1.4.21 on Sun Sep 27 01:02:42 2015
*nat
:PREROUTING ACCEPT [1922:184974]
:POSTROUTING ACCEPT [169:10479]
:OUTPUT ACCEPT [169:10479]
COMMIT
# Completed on Sun Sep 27 01:02:42 2015
# Generated by iptables-save v1.4.21 on Sun Sep 27 01:02:42 2015
*mangle
:PREROUTING ACCEPT [8072:4156393]
:INPUT ACCEPT [6659:4020368]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [3966:856479]
:POSTROUTING ACCEPT [3966:856479]
COMMIT
# Completed on Sun Sep 27 01:02:42 2015
# Generated by iptables-save v1.4.21 on Sun Sep 27 01:02:42 2015
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [53:6748]
-A INPUT -p tcp -m tcp --dport 80 -m state --state NEW -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT
# Completed on Sun Sep 27 01:02:42 2015
Просто перенаправь вывод iptables-save в файл
iptables-save > /tmp/rules
, поправь содержимое файла и загрузи изменённые правила
iptables-restore /tmp/rules
после чего нужно средствами стартового сценария, который загружает правила iptables в твоём дистрибутиве сохранить изменённые правила, будет что-то такое:
/etc/init.d/iptables save
но всё зависит от твоего дистрибутива, тем более если там ещё и systemd, то может быть совсем по другому.
Красавчик, даже разжевать не поленился. Только зря за одно и --reject-with icmp-host-prohibited не выкинул, очевидно что это не обдуманный выбор топикстартера, а копипаст из какой-то дурацкой хаутушечки.
А смысл, если ты его удалишь, то что есть твои правила, что их нет, сейчас политика прохождения пакетов в цепочке input - ACCEPT, т.е. разрешены все входящие пакеты. Так что если ты удалишь указанную строку, то вообще не будет резона писать правила по разрешению чего-либо, только по запрещению.
Так, в iptables при написании правил обработки прохождения пакетов можно исходить из двух схема:
- политика, когда всё разрешено, а затем явно добавляются правила которые разрешают нужное и самым последним правило, которое всё закрывает или попросту только добавляется правило которое что-то закрывает;
- политика, когда всё запрещено, в этом случае добавляются правила, которые что-то разрешают.
Вот и строй исходя из этих двух направлений правила для пакетного фильтра.
значит ли это, что кто угодно туда вирусов нагонит?
Нагонит или не нагонит кто-то куда-то вирусни зависит от того есть ли в приложении, которое слушает какой-либо порт уязвимость, которую можно эксплуатировать для повышения своих привилегий в системе или попросту вывода системы из строя. Если ты уверен, что в твоей системе нет сервисов, которые потенциально имеют проблемы в безопасности, ошибки, которые могут позволить злоумышленнику получить контроль на твоей системой, то не закрывай ничего. Но мне думается, что систем, в которых нет проблем с безопасностью не существует, поэтому и закрывают по возможности всё, что не нужно для выполнения требуемого функционала.
Вирусы это немного не про linux. Блокировка входящих соединений по умолчанию (которая применяется в центосе) нужна что-бы по недосмотру не сделать доступным всему миру что-то что делать доступным всему миру не нужно. В общем дополнительная защита от выстрела в ногу. Ну и из общего соображения что всё что не разрешено должно быть запрещено. Потому-что нефиг тут.
Правда твой конфиг фаервола похоже писал с нуля какой-то странный человек.
Ну вообще-то сейчас у тебя разрешён не доступ к конкретному порту, а ко всем портам системы в принципе.
И тут есть пара нюансов:
1) Не всем сервисам стоит светить в сеть. Скажем, серверу БД скорее всего не стоит. Конечно, часто есть возможность настроить их так, чтобы они принимали подключения только с localhost, однако фаерволл является дополнительным рубежом защиты. Ты имеешь гарантии, что извне будет доступ только к тем службам, которые нужно вне зависимости от настроек конкретных сервисов.
2) Допустим, тебя таки поломали через уязвимость в каком-нибудь софте, но root-прав не получили, а только права уязвимой программы. И хотят они для удалённого доступа запустить сервер удалённого управления (если номер порта больше 1000, то для работы с ним root не нужен), запускают - правило фаервола не даёт приконнектится. Опять же рубеж защиты.
Что касается «вирусов нагонят». Через конкретно сам порт никто тебя не поломает. Однако порт слушает какое-то приложение (веб-сервер, например). И открытость порта означает, что кто-угодно может с этим приложением взаимодействовать (однако если порт открыт, но его никто не слушает, то к нему всё равно нельзя подключиться, однако мало ли - вдруг злоумышленник сможет что-то запустить, что начнёт слушать). А приложения, бывает, содержат ошибки и уязвимости. И кто-нибудь может передать какие-нибудь некорректные данные, чтобы этими ошибками воспользоваться в свою пользу. Ах да, веб-сервер часто отдаёт не только статику, но и, скажем, запускает PHP-скрипты или проксирует запрос к серверу, написанному на nodejs, python, ruby или чём-то ещё. Данные, полученные от пользователя, в какой-то степени передаются этим приложениям (иначе как понять, что хочет юзер). И опять же ошибки в них позволяют сделать что-то нехорошее.
Поэтому:
1) Все сетевые сервисы запускаются не от root, а от отдельных пользователей. Скажем, веб-сервер запускается от юзера http или www-data. Также иногда запрещают этому пользователю писать в каталог скриптов, только статичных файлов. Все эти способы минимизируют ущерб от взлома.
2) Сервисы, которые пользователю не нужны прямо (скажем, база данных, из которой сайт грузит странички), закрывают фаерволом, ибо ошибки везде есть и чем меньше сервисов открыто, тем меньше шанс нарваться на такое.
Вывод один: открывать только нужные порты и своевременно обновлять софт (с обновлением закрываются известные уязвимости). Причём не только системный, но и всякие CMS и т. п.
