Помогите ssl порт открыть

Нужно больше данных. И, «иди ты в Job с такой формулировкой» © :)

Покажи iptables-save с сервера. Похоже что либо там какая-то ересь. Либо в каком-нибудь другом фаерволе стоящем перет твоим сервером.

BTW, _откуда_ ты проверяешь «открытость» порта 443 на нужном сервере?

С моего компа результат тот-же. На 80 порт соединение устанавливается, при попытке открыть соединение на 443 приходит отлуп про «Нет маршрута до узла».
Похоже проблема действительно где-то в районе сервера.

Проблема где-то в районе ТС. Который и конфиги привёл, и логи, и трассировки...

Какие данные могут пригодиться? iptables-save если ввести, то ничего не ответит

iptables-save если ввести, то ничего не ответит

Выполняй от имени root.

И правда!

# 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 -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
COMMIT
# Completed on Sun Sep 27 01:02:42 2015

Тут можно заметить, что я не один раз проклятый порт открыть пытался

Сервер подключен напрямую к интернету или через роутер? Может быть, что порт надо открыть также на роутере.

посмотрите трассировку по порту

traceroute -T serverip -p 443

Сервер vps, думаю открывать глубже не надо, или стоит может вправду в поддержку написать

-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT

Что в переводе на русский означает — сначала отбросить всё, а потом из оставшегося (после отбрасывания всего) пропустить то что направлено на порт 443.
Улавливаешь?

Попробуй временно отключить фаервол.

iptables --policy INPUT   ACCEPT
iptables --policy OUTPUT  ACCEPT
iptables --policy FORWARD ACCEPT
iptables -Z
iptables -F
iptables -X

Если не поможет - однозначно к хостеру. Иначе можно разбираться дальше.

Есть запись:

traceroute to 109.120.155.210 (109.120.155.210), 30 hops max, 60 byte packets
 1  zaimtut (109.120.155.210)  0.037 ms  0.011 ms  0.010 ms

Что ты запустил комманду не на том хосте.

В iptables важна очерёдность правил

*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

/etc/init.d/iptables save

Спасибо тебе, счастья и здоровья, благослови г-подь. Зачем этот фаервол нужен вообще, так работает и можно дальнейшие ошибки фиксить.

Красавчик, даже разжевать не поленился.
Только зря за одно и --reject-with icmp-host-prohibited не выкинул, очевидно что это не обдуманный выбор топикстартера, а копипаст из какой-то дурацкой хаутушечки.

Спс, ясненько, значит -A INPUT -j REJECT --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 и т. п.

*filter :INPUT ACCEPT [0:0]

Очень интересный конфиг iptables :)

Система centos 7

тред

Слон в посудной лавке