LinuxQuestions.org - Setting up iptables for SSL (port 443)

- Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)

- - Setting up iptables for SSL (port 443) (https://www.linuxquestions.org/questions/linux-newbie-8/setting-up-iptables-for-ssl-port-443-a-821808/)

Setting up iptables for SSL (port 443)

I hear that it's a bad idea to edit iptables by hand.

I want to open 443.

Quote:

iptables -A INPUT -p tcp -m tcp --sport 443 -j ACCEPT
iptables -A OUTPUT -p tcp -m tcp --dport 443 -j ACCEPT

BUT***

It has been suggested to me that I don't need the second line (OUTPUT), and the first line shoud be --dport NOT --sport. In other words,

Quote:

iptables -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT

I got my original (two line) quote from here:

http://www.redhat.com/docs/manuals/e...ipt-basic.html

Background: I have an SSL cert and want to set up Apache to accept SSL conx...

Since I'm not at the box, I can't use the nifty GUI.

How might one do this via terminal?

OS: CentOSv5 (RHELv5)

The page you got your data from is describing the setup on a firewall device or gateway. This is why it has to allow 443 in both directions. On the server machine itself, you only need to open the port for input.

Code:

iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT

service iptables save

service iptables restart

Excellent.

NMap now tells me 443 is open.

However, an on-line port scan such as:

http://www.yougetsignal.com/tools/open-ports/

tells be 443 is closed.

Navigation to https://mydomain.com in a browser returns an error:

(Chrome) Error 118 (net::ERR_CONNECTION_TIMED_OUT): The operation timed out.
(Opera) Could not connect to remote server

...And so forth.

Does this mean a router block? Or maybe SSL is misconfigured in Apache?

I would suggest what is called a TCP Traceroute on port 443, this will tell you where the problem is occurring. Most hosting companies will not block 443 (since people use it quite a lot), but if you are hosting this at home, then your own router might be blocking this, another suggestion would be to start with the server itself and move further away. If the server is unable to trace itself on a "tcptraceroute -p 443 127.0.0.1" then you know the issue remains with the server. If you need to do it further away, cross compare it with a normal traceroute or a traceroute on port 80 should give you an indication of where the traffic is being blocked or rejected.

We are on a Comcast Business account, so I assume it's not blocked at the ISP.

Quote:

[@localhost ~]# tcptraceroute -p 443 127.0.0.1
traceroute to 127.0.0.1 (127.0.0.1), 30 hops max, 40 byte packets
1 localhost.localdomain (127.0.0.1) 0.093 ms 0.057 ms 0.049 ms

Did you update your apache configuration itself with the details for the HTTPS site yet? and restart apache, warning this might cause some downtime as you maybe requested to supply a pass phrase.

Quote:

Originally Posted by r3sistance (Post 4044367)

Did you update your apache configuration itself with the details for the HTTPS site yet? and restart apache, warning this might cause some downtime as you maybe requested to supply a pass phrase.

Yes. Did that. My server key doesn't require a pass phrase...

The /var/logs/ssl_error_log reveals no error (since I fixed some cert issues)

The /var/logs/ssl_access_log has no entries at all.

Also...

Quote:

[@localhost ~]# apachectl configtest
Syntax OK

Looking up I have noticed you have used iptables -A, I believe I know what has occurred, could you do an "iptables -nvL" and copy and paste the results here, because the results can get rather lengthy can you also place the results within code tags.

Here it is:

Code:

[localhost ~]# iptables -nvL

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)

 pkts bytes target    prot opt in    out    source              destination        

27508 3172K RH-Firewall-1-INPUT  all  --  *      *      0.0.0.0/0            0.0.0.0/0          

    0    0 ACCEPT    tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          state NEW tcp dpt:443 



Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)

 pkts bytes target    prot opt in    out    source              destination        

    0    0 RH-Firewall-1-INPUT  all  --  *      *      0.0.0.0/0            0.0.0.0/0          



Chain OUTPUT (policy ACCEPT 28872 packets, 20M bytes)

 pkts bytes target    prot opt in    out    source              destination        



Chain RH-Firewall-1-INPUT (2 references)

 pkts bytes target    prot opt in    out    source              destination        

 7989 1499K ACCEPT    all  --  lo    *      0.0.0.0/0            0.0.0.0/0          

    0    0 ACCEPT    icmp --  *      *      0.0.0.0/0            0.0.0.0/0          icmp type 255 

    0    0 ACCEPT    esp  --  *      *      0.0.0.0/0            0.0.0.0/0          

    0    0 ACCEPT    ah  --  *      *      0.0.0.0/0            0.0.0.0/0          

  16  3124 ACCEPT    udp  --  *      *      0.0.0.0/0            224.0.0.251        udp dpt:5353 

    0    0 ACCEPT    udp  --  *      *      0.0.0.0/0            0.0.0.0/0          udp dpt:631 

    0    0 ACCEPT    tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          tcp dpt:631 

18157 1593K ACCEPT    all  --  *      *      0.0.0.0/0            0.0.0.0/0          state RELATED,ESTABLISHED 

    1    60 ACCEPT    tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          state NEW tcp dpt:21 

    0    0 ACCEPT    tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          state NEW tcp dpt:25 

    0    0 ACCEPT    tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          state NEW tcp dpt:2049 

    0    0 ACCEPT    tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          state NEW tcp dpt:22 

    0    0 ACCEPT    udp  --  *      *      0.0.0.0/0            0.0.0.0/0          state NEW udp dpt:137 

    0    0 ACCEPT    udp  --  *      *      0.0.0.0/0            0.0.0.0/0          state NEW udp dpt:138 

    0    0 ACCEPT    tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          state NEW tcp dpt:139 

    0    0 ACCEPT    tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          state NEW tcp dpt:445 

    0    0 ACCEPT    tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          state NEW tcp dpt:443 

    0    0 ACCEPT    tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          state NEW tcp dpt:23 

 1332 76432 ACCEPT    tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          state NEW tcp dpt:80 

  12  600 ACCEPT    tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          state NEW tcp dpt:4022 

    0    0 ACCEPT    udp  --  *      *      0.0.0.0/0            0.0.0.0/0          state NEW udp dpt:4022 

    0    0 ACCEPT    tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          state NEW tcp dpt:990 

    0    0 ACCEPT    udp  --  *      *      0.0.0.0/0            0.0.0.0/0          state NEW udp dpt:991 

    1  339 REJECT    all  --  *      *      0.0.0.0/0            0.0.0.0/0          reject-with icmp-host-prohibited

And the rules from /etc/sysconfig/iptables ...

Code:

 Generated by iptables-save v1.3.5 on Sat Jul 24 13:11:30 2010

*filter

:INPUT ACCEPT [0:0]

:FORWARD ACCEPT [0:0]

:OUTPUT ACCEPT [425823:352087888]

:RH-Firewall-1-INPUT - [0:0]

-A INPUT -j RH-Firewall-1-INPUT

-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT

-A FORWARD -j RH-Firewall-1-INPUT

-A RH-Firewall-1-INPUT -i lo -j ACCEPT

-A RH-Firewall-1-INPUT -p icmp -m icmp --icmp-type any -j ACCEPT

-A RH-Firewall-1-INPUT -p esp -j ACCEPT

-A RH-Firewall-1-INPUT -p ah -j ACCEPT

-A RH-Firewall-1-INPUT -d 224.0.0.251 -p udp -m udp --dport 5353 -j ACCEPT

-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT

-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT

-A RH-Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 21 -j ACCEPT

-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 25 -j ACCEPT

-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 2049 -j ACCEPT

-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT

-A RH-Firewall-1-INPUT -p udp -m state --state NEW -m udp --dport 137 -j ACCEPT

-A RH-Firewall-1-INPUT -p udp -m state --state NEW -m udp --dport 138 -j ACCEPT

-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 139 -j ACCEPT

-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 445 -j ACCEPT

-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT

-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 23 -j ACCEPT

-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT

-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 4022 -j ACCEPT

-A RH-Firewall-1-INPUT -p udp -m state --state NEW -m udp --dport 4022 -j ACCEPT

-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 990 -j ACCEPT

-A RH-Firewall-1-INPUT -p udp -m state --state NEW -m udp --dport 991 -j ACCEPT

-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited

COMMIT

# Completed on Sat Jul 24 13:11:30 2010

Note the row...

-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT

and...

-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT

The second one was me today thinking that it didn't already exist. Should I delete it?

Hi,

-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT

Won't be doing anything (it appears after the reject all rule) but I tend to get rid of unused rules just to keep things manageable. As far as I can see, the firewall is configured correctly. So it's either a service (apache) Issue, or it's being blocked by something else.