LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)
-   -   [iptables]Box closed very well (https://www.linuxquestions.org/questions/linux-security-4/%5Biptables%5Dbox-closed-very-well-500008/)

Wim Sturkenboom 11-09-2006 05:09 AM
[iptables]Box closed very well
 
I'm running a little intranet server (LAMP). Based on some examples that I found floating around on the net, I created the below firewall configuration to seal it. This does not mean that I fully understand how iptables work. Unfortunately the configuration works too well.

My web application needs to act as an smtp-client to a MS exchange server (172.31.212.12 on port 25) so it can send emails.

As far as I understand the below config, port 25 is open for outgoing traffic. So I assume that my problem is in the incoming traffic (replies from the MS exchange server).

Which rule(s) do I need to add so my application can receive the replies; the bold line below was the one that made sense to me, but does not work.


Code:
# initial block
iptables -P INPUT DROP
iptables -P FORWARD DROP

# accept anything on localhost
iptables -A INPUT -s 127.0.0.1 -d 127.0.0.1 -j ACCEPT

# allow HTTPS from any machine on 172.*.*.*
iptables -A INPUT -s 172.0.0.0/8 -p tcp --dport 443 -j ACCEPT

# allow SSH from trusted machines
iptables -A INPUT -s 172.31.212.19 -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -s 172.31.212.53 -p tcp --dport 22 -j ACCEPT

# allow FTP from trusted machines
iptables -A INPUT -s 172.31.212.19 -p tcp --dport 21 -j ACCEPT
iptables -A INPUT -s 172.31.212.19 -p tcp --dport 20 -j ACCEPT
# passive ftp
iptables -A INPUT -s 172.31.212.19 -p tcp --sport 1024:65535 -j ACCEPT

iptables -A INPUT -s 172.31.212.12 -p tcp --dport 25 -j ACCEPT

unSpawn 11-09-2006 05:46 AM
If you add "-j LOG" rules before chain decisions are made you get a better view of what fails and why.
Easiest way to start TS with Iptables.

chort 11-09-2006 10:27 AM
I'm not very good with iptables, but your FTP rules appear to be backwards, by the way. The data channel (20) is a connection from the FTP server to the FTP client. It goes in the opposite direction as the command channel (21) and passive FTP data channel. Incidentally, you seem to have opened up traffic to any port with your passive FTP rule (if it's coming from 172.31.212.19). This is probably not what you meant to do. You should modify your FTP server configuration to restrict what port it uses for passive FTP (say, 8000-9000), then only open the firewall for those ports, not everything between 1024 & 65535 (that's effectively pretty much every ephemeral port).

If the other rules work (particularly the HTTPS rule) then you shouldn't need anything to allow return replies that are part of an existing TCP connection. I think your SMTP rule is backwards. My guess is -s = source and what you really want is -d = destination?

By the way, what machine is that firewall on? Is it on your webserver, or on a different machine? Could you do a brief diagram to show us what your network looks like?

Wim Sturkenboom 11-10-2006 03:37 AM
Main problem was that the IP address and dport/sport were incorrect. An additional problem came in as dns lookups were also blocked so the hostname in the application could not be resolved.

new rule(s):
Code:
iptables -A INPUT -p udp --sport 53 -j ACCEPT
iptables -A INPUT -s 10.17.131.12 -p tcp --sport 25 -j ACCEPT
The first one is not perfect yet, I must figure out the IP addresses.

@unSpawn
Thanks, it helped once I figured out how to get to the log results.

Outstanding question with regards to logging:
I used dmesg to check the log results. Is there another way? I could not straight away find a relevant logfile although I tried to find files that were modified less than x minutes ago.

@chort
I will look into the ftp issue. Those rules were determined by trial and error and (unfortunately) one stops once it's working (and there might be obsolete stuff in there).

Wim Sturkenboom 04-23-2008 01:31 AM
I've finally found time to work on the FTP part. Here's just an update; if someone still sees a mistake, feedback is appreciated.

This box is currently in WimS' local network, but the rules are prepared for the office network as well.

Code:

#!/bin/sh

# initial block
################################################################
iptables -P INPUT DROP
iptables -P FORWARD DROP

# accept anything on localhost
iptables -A INPUT -s 127.0.0.1 -d 127.0.0.1 -j ACCEPT

# allow HTTP and HTTPS
# we allow any http(s) request as client addresses occasionally change
#  and users can get in
################################################################
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -p tcp --dport 80  -j ACCEPT

# allow SSH from trusted machines; each machine needs to be specified
################################################################
# office network
iptables -A INPUT -s 172.31.212.19 -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -s 172.31.212.53 -p tcp --dport 22 -j ACCEPT

# WimS' local network
iptables -A INPUT -s 172.18.32.0/8 -p tcp --dport 22 -j ACCEPT

# allow FTP from trusted machines
################################################################
# office network
iptables -A INPUT -s 172.31.212.19 -p tcp --dport 21 -j ACCEPT
iptables -A INPUT -s 172.31.212.19 -p tcp --dport 65000:65535 -j ACCEPT

# WimS' local network
iptables -A INPUT -s 172.18.32.3 -p tcp --dport 21 -j ACCEPT
iptables -A INPUT -s 172.18.32.3 -p tcp --dport 65000:65535 -j ACCEPT

# miscellaneous
################################################################
# need to resolve hostname
iptables -A INPUT -p udp --sport 53 -j ACCEPT
# need to receive stuff from rnbm-msg09
iptables -A INPUT -s 10.17.131.12 -p tcp --sport 25 -j ACCEPT

# log anything else
################################################################
iptables -A INPUT -j LOG


All times are GMT -5. The time now is 01:18 AM.