Setting up iptables for SSL (port 443)

Arty Ziff · 07-23-2010, 11:10 PM

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)

smoker · 07-24-2010, 01:08 AM

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

Arty Ziff · 07-24-2010, 07:29 PM

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?

r3sistance · 07-24-2010, 07:40 PM

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.

Arty Ziff · 07-24-2010, 07:43 PM

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

r3sistance · 07-24-2010, 07:46 PM

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.

Arty Ziff · 07-24-2010, 08:12 PM

Quote:

Originally Posted by r3sistance

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

r3sistance · 07-24-2010, 09:46 PM

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.

Arty Ziff · 07-24-2010, 11:09 PM

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?

r3sistance · 07-25-2010, 12:20 AM

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.