Steve's questions

For reasons beyond my comprehension, GlassFish refuses to play ball with iptables. That is, with all the correct redirection rules in place, it won't receive any redirected traffic. So I'm at plan B which is to bind GlassFish to ports 80 and 443 rather than 8080 and 8181.

As I don't want to run GlassFish as root for security reasons, I need to grant the user account that is running it with sufficient privileges to bind to ports 80 and 443. From a security point of view, it's not risky because iptables is blocking all the other ports.

In Centos 6.4, what command(s) do I execute to allow a specified non-root user to directly listen to ports < 1024?

Please don't suggest drastic solutions that involve downloading (and compiling) stuff from random locations. I need something reproducible, so if any dependencies need to be brought in, they need to come from Centos's package repository.

I'm running a DigitalOcean Centos 6 VPS. Here's the script I used to set up iptables on Centos 6.4 64-bit:

#!/bin/sh
service iptables stop
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080
iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 443 -j REDIRECT --to-port 8181
iptables -I INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P INPUT DROP
iptables-save > /etc/sysconfig/iptables
service iptables restart

I opens ports 22, 80 and 443 only, redirecting 80 and 443 internally to 8080 and 8181 respectively.

Due to a bug/quirk in GlassFish, I had to add the machine's hostname to /etc/hosts:

127.0.0.1 localhost
127.0.0.1 example.com

Without the NAT rules in the iptables configuration, I am able to reach the GlassFish server via my browser at home when attempting to connect either via port 8080 or 8181. With the NAT rules added, I cannot reach the server at all, neither via 80 and 443 nor via 8080 and 8181.

Do I need to make a change to any of the iptables rules to factor in that extra line in /etc/hosts?

Update:

If I remove the last rule, iptables -P INPUT DROP, I can now access the server via a browser using ports 80/443 and 8080/8181. This indicate the forwarding is working.

On Centos 6.4, I want to block all incoming ports except 22, 80 and 443. 80 (external) should be redirected 8080 (internal). 443 (external) should be redirected to 8181 (internal). I used the following commands:

service iptables stop
iptables -A INPUT -i eth0 -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT
iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080
iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 443 -j REDIRECT --to-port 8181
service iptables save
service iptables restart

However, I can still access ports 8080 and 8181. Is there a way to block ports 8080 and 8181 externally and still have open internally for redirection from 80 and 443?

I'm integrating with a third-party product via its SQL Server 2008 R2 database. In a previous version, I was able to access the database via SQL Server Management Studio and SQLCMD as a Windows administrator using Windows authentication.

The third-party product controls the sa account and keeps the password a secret.

After applying the vendor's latest product update, I can no longer access the database using Windows authentication. I even tried single mode, but no luck.

Here's how I switched to single mode:

net stop MSSQL$FOOBAR
net start MSSQL$FOOBAR -mSQLCMD

That seems to start the database.

C:\>sqlcmd /S .\FOOBAR
Msg 18470, Level 14, State 1, Server WINMAC\FOOBAR, Line 1
Login failed for user 'WINMAC\steve'. Reason: The account is disabled.

Is there a way in? Or is it more likely the vendor has closed a hole and I can't get in?

Here's my iptables script:

#!/bin/sh
service iptables stop
iptables -F
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -p tcp -m multiport --dports 22,80,443 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p udp --sport 53 --dport 1024:65535 -j ACCEPT
service iptables save
service iptables restart

It works fine on Centos 6.3, but on Centos 6.0 I can't establish outbound HTTP connections. (I probably can't establish any outbound TCP/IP connections.) DNS lookup, however, works just fine, as does apparently anything else based on UDP.

I'm guessing this has something to do with TCP's three-way handshake, of which I know almost nothing. That being the case, there must be a difference in the versions of one of the modules where the earlier version requires explicit specification of INPUT rules to allow the handshake. So, what rule(s) would I need to create to allow the TCP handshake and therefore receive data?

This iptables script:

#!/bin/sh
service iptables stop
iptables -F
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -p tcp -m multiport --dports 22,80,443 -m state --state NEW,ESTABLISHED -j ACCEPT
service iptables save
service iptables restart

works as expected on a Centos 6.3 server (provided by VPSBlocks.com.au) but not a Centos 6.0 server (provided by VPSNine.com). By "works as expected", I mean that it at least allows incoming access to ports 22, 80 and 443. And by not working, I mean it doesn't allow access.

The one that works has the following /etc/sysconfig/iptables:

# Generated by iptables-save v1.4.7 on Wed Feb 27 19:10:38 2013
*filter
:INPUT DROP [3:453]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [1:52]
-A INPUT -i lo -j ACCEPT 
-A INPUT -p tcp -m multiport --dports 22,80,443 -m state --state NEW,ESTABLISHED -j ACCEPT 
COMMIT
# Completed on Wed Feb 27 19:10:38 2013

whereas the one that doesn't work has the following /etc/sysconfig/iptables:

# Generated by iptables-save v1.4.7 on Wed Feb 27 11:28:36 2013
*mangle
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
# Completed on Wed Feb 27 11:28:36 2013
# Generated by iptables-save v1.4.7 on Wed Feb 27 11:28:36 2013
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT 
-A INPUT -p tcp -m multiport --dports 22,80,443 -m state --state NEW,ESTABLISHED -j ACCEPT 
COMMIT
# Completed on Wed Feb 27 11:28:36 2013
# Generated by iptables-save v1.4.7 on Wed Feb 27 11:28:36 2013
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT
# Completed on Wed Feb 27 11:28:36 2013

If I replace the non-working /etc/sysconfig/iptables with the one that works in the other server, it allows me to keep the current ssh connection, but when I try to get back in, I'm locked out.

Why would the exact same iptables config work on one server but not the other? Could the difference in minor versions of Centos (6.3 vs. 6.0) account for the different behaviour?

Update: The Centos 6.3 server (one on which the iptables config works) uses iptables 1.4.7-5.1.el6_2. The other server uses iptables 1.4.7-3.el6.

Update: iptables --list returns the following on BOTH servers:

Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     tcp  --  anywhere             anywhere            multiport dports ssh,http,https state NEW,ESTABLISHED 

Chain FORWARD (policy DROP)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Update: When I login to the 6.0 server, I see this warning:

Warning: Unknown iptable module: nf_conntrack_ipv4, skipped

I'm not sure how to install this. Is it a kernel module? If so, it looks like I'm snookered.

In /var/lib/pgsql/9.1/data/pg_hba.conf, I have the following:

# TYPE  DATABASE        USER            ADDRESS                 METHOD
host    all             all             127.0.0.1/32            trust

But when I execute

su -c "psql -d postgres" - postgres

it asks me for a password. My expectation is that users should not be prompted for a password.

I'm trying to run GlassFish 3.1.1 on Centos 6 in the Joyent cloud. No matter what I set the admin port to in glassfish/domains/domain1/config/domain.xml, when attempting to start it says:

There is a process already using the admin port XXXXX -- it probably is another instance of a GlassFish server.

I've checked netstat and /etc/services and tried dozens of different ports, but to no avail. It just flat out says that every port I try is taken.

Ideas?