IPTables Halting

inescapeableus · 06-16-2006, 02:59 PM

I have accomplished this issue, yet for some reason I can't close my FTP (21) and SMTP (25) attached is my iptables rules.

#!/bin/bash
#
#
#Chain Policies
#
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
#
#
#Flusing Any Exisiting Rules
#
iptables -F INPUT
iptables -F FORWARD
iptables -F OUTPUT
#
#
#Allow Input From Loopback Device
#
iptables -A INPUT -i lo -s 0/0 -d 0/0 -j ACCEPT
#
#
#Allow INPUT & OUTPUT for DNS
#
iptables -A INPUT -p udp -s 0/0 -d 0/0 --sport 53 -j ACCEPT
iptables -A OUTPUT -p udp -s 0/0 -d 0/0 --destination-port 53 -j ACCEPT
#
#
#Allow Port 80 to be open TCP
#
iptables -A INPUT -p tcp -m tcp --sport 80 -j ACCEPT
iptables -A OUTPUT -p tcp -m tcp --dport 80 -j ACCEPT
#
#
#Allow PORT 80 to be open UDP
iptables -A INPUT -p udp -m udp --sport 80 -j ACCEPT
iptables -A OUTPUT -p udp -m udp --dport 80 -j ACCEPT
#
#
#Allow HTTPS To Connect
#
iptables -A INPUT -p tcp -m tcp --sport 443 -j ACCEPT
iptables -A OUTPUT -p tcp -m tcp --dport 443 -j ACCEPT
#
#
#FTP Port 21 Close
iptables -A INPUT -p tcp -i eth0 --dport 21 -j DROP
iptables -A INPUT -p udp -i eth0 --dport 21 -j DROP
#
#
#Block any other connections except the ports listed above
#
iptables -A INPUT -j REJECT
iptables -A OUTPUT -j REJECT
#
#

Capt_Caveman · 06-16-2006, 11:16 PM

Could you post the exact nmap command you are using to scan the box?

Israfel2000 · 06-17-2006, 04:46 PM

You can try other communication devices like eth0, eth1, eth2, etc. Or if you have a dial up modem try modem0, modem1, modem2, etc. This could be your problem.

haertig · 06-17-2006, 07:54 PM

Are you by chance trying to FTP to yourself (i.e., using loopback)? If so, then your loopback rule is allowing that.

Also, I always set policies AFTER flushing. I don't know if this really makes a difference. But a question that begs testing is "Does the flush flush polices too?" Never tested it personally to prove one way or the other. I've always just done policies after flushing, and I know that works.

win32sux · 06-17-2006, 11:21 PM

Quote:

Originally Posted by haertig

I always set policies AFTER flushing. I don't know if this really makes a difference. But a question that begs testing is "Does the flush flush polices too?" Never tested it personally to prove one way or the other. I've always just done policies after flushing, and I know that works.

no, flushing will not change your policies...

win32sux · 06-17-2006, 11:51 PM

Quote:

Originally Posted by inescapeableus

I have accomplished this issue, yet for some reason I can't close my FTP (21) and SMTP (25) attached is my iptables rules.

#!/bin/bash
#
#
#Chain Policies
#
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
#
#
#Flusing Any Exisiting Rules
#
iptables -F INPUT
iptables -F FORWARD
iptables -F OUTPUT
#
#
#Allow Input From Loopback Device
#
iptables -A INPUT -i lo -s 0/0 -d 0/0 -j ACCEPT
#
#
#Allow INPUT & OUTPUT for DNS
#
iptables -A INPUT -p udp -s 0/0 -d 0/0 --sport 53 -j ACCEPT
iptables -A OUTPUT -p udp -s 0/0 -d 0/0 --destination-port 53 -j ACCEPT
#
#
#Allow Port 80 to be open TCP
#
iptables -A INPUT -p tcp -m tcp --sport 80 -j ACCEPT
iptables -A OUTPUT -p tcp -m tcp --dport 80 -j ACCEPT
#
#
#Allow PORT 80 to be open UDP
iptables -A INPUT -p udp -m udp --sport 80 -j ACCEPT
iptables -A OUTPUT -p udp -m udp --dport 80 -j ACCEPT
#
#
#Allow HTTPS To Connect
#
iptables -A INPUT -p tcp -m tcp --sport 443 -j ACCEPT
iptables -A OUTPUT -p tcp -m tcp --dport 443 -j ACCEPT
#
#
#FTP Port 21 Close
iptables -A INPUT -p tcp -i eth0 --dport 21 -j DROP
iptables -A INPUT -p udp -i eth0 --dport 21 -j DROP
#
#
#Block any other connections except the ports listed above
#
iptables -A INPUT -j REJECT
iptables -A OUTPUT -j REJECT
#
#

i don't really see anything that would explain why your ports 21 and 25 are still appearing as opened (make sure you are scanning your box *remotely*), but there are indeed some awkward and redundant rules in your script... for example, there is no need to DROP port 21 if your policy is already set to DROP and you haven't ACCEPTed anything on 21... also, is there some particular reason why you are REJECTing at the end of the chains??

either way, here's a cleaned-up donation for you:

Code:

#!/bin/bash

### IPtables location...
IPT="/usr/sbin/iptables"

### WAN interface name...
WAN_IFACE="eth0"

### Make sure forwarding is disabled...
echo "0" > /proc/sys/net/ipv4/ip_forward

### Flush chains...
$IPT -F
$IPT -F -t nat
$IPT -F -t mangle

### Delete user chains...
$IPT -X
$IPT -X -t nat
$IPT -X -t mangle

### Set policies...
$IPT -P INPUT DROP
$IPT -P OUTPUT DROP
$IPT -P FORWARD DROP

### It doesn't hurt to be thorough...
$IPT -t nat -P PREROUTING ACCEPT
$IPT -t nat -P POSTROUTING ACCEPT
$IPT -t nat -P OUTPUT ACCEPT
$IPT -t mangle -P PREROUTING ACCEPT
$IPT -t mangle -P OUTPUT ACCEPT

### Allow packets belonging to established connections, and/or
### connections related to established ones...
$IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

### Allow loopback interface...
$IPT -A INPUT -i lo -j ACCEPT

### Allow DNS daemon...
$IPT -A INPUT -p UDP -i $WAN_IFACE --dport 53 \
-m state --state NEW -j ACCEPT

### Allow HTTP daemon...
$IPT -A INPUT -p TCP -i $WAN_IFACE --dport 80 \
-m state --state NEW -j ACCEPT

### Allow UDP port 80 (not sure what for)...
$IPT -A INPUT -p UDP -i $WAN_IFACE --dport 80 \
-m state --state NEW -j ACCEPT

### Allow HTTPS daemon...
$IPT -A INPUT -p TCP -i $WAN_IFACE --dport 443 \
-m state --state NEW -j ACCEPT

### Log everything else before sending it to DROP...
$IPT -A INPUT -j LOG --log-prefix "INPUT DROP: "

### Allow packets belonging to established connections, and/or
### connections related to established ones...
$IPT -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

### Allow loopback interface...
$IPT -A OUTPUT -o lo -j ACCEPT

### Log everything else before sending it to DROP...
$IPT -A OUTPUT -j LOG --log-prefix "OUTPUT DROP: "

if you still have ports 21 and 25 open after this, then something funny is going-on... like Capt_Caveman said, you should post the method you are using to determine the ports are indeed still open...

just my

... good luck...

inescapeableus · 06-18-2006, 01:10 PM

haha thanks for the help, I know of the dual attempts to close 21 and 25 I was just fishing for ideas.

win32sux · 06-18-2006, 03:04 PM

so it's working fine now??

Capt_Caveman · 06-18-2006, 06:59 PM

@inescapeableus: Could you answer some of the questions asked in this thread? If you are nmaping localhost, then that's likely why you are seeing open ports.

As a side note, filtering incoming traffic based on source ports is a *REALLY* bad idea. As an example, if a remote attacker sets his nmap scan to use a source port of 53, then he can scan every single port on your box as if there was no firewall at all. In fact, if you read the nmap man page subsection on source ports it describes this exact hole and recommends setting the source to port 53 for your scans because it's a common misconfiguration. Unless you are running a DNS, HTTP, or HTTPS server then you should only allow traffic that is in the ESTABLISHED or RELATED states. If you are running those services and need them to be publically accessible, then use something like the script win32sux posted.

win32sux · 06-18-2006, 09:19 PM

yeah, the script i posted assumes this is a dedicated server... it won't let the server *initiate* a connection at all (only respond to connections initiated by clients)...

if this was actually a client (instead of a server), then most of the INPUT rules i posted would need to be translated into OUTPUT rules... let us know exactly what it is you are doing here, because it's hard to tell by looking at your rules...

win32sux · 06-18-2006, 09:24 PM

here's the script again, but modified for a (stealth) client:

Code:

#!/bin/bash

### IPtables location...
IPT="/usr/sbin/iptables"

### WAN interface name...
WAN_IFACE="eth0"

### Make sure forwarding is disabled...
echo "0" > /proc/sys/net/ipv4/ip_forward

### Flush chains...
$IPT -F
$IPT -F -t nat
$IPT -F -t mangle

### Delete user chains...
$IPT -X
$IPT -X -t nat
$IPT -X -t mangle

### Set policies...
$IPT -P INPUT DROP
$IPT -P OUTPUT DROP
$IPT -P FORWARD DROP

### It doesn't hurt to be thorough...
$IPT -t nat -P PREROUTING ACCEPT
$IPT -t nat -P POSTROUTING ACCEPT
$IPT -t nat -P OUTPUT ACCEPT
$IPT -t mangle -P PREROUTING ACCEPT
$IPT -t mangle -P OUTPUT ACCEPT

### Allow packets belonging to established connections, and/or
### connections related to established ones...
$IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

### Allow loopback interface...
$IPT -A INPUT -i lo -j ACCEPT

### Log everything before sending it to DROP...
$IPT -A INPUT -j LOG --log-prefix "INPUT DROP: "

### Allow packets belonging to established connections, and/or
### connections related to established ones...
$IPT -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

### Allow loopback interface...
$IPT -A OUTPUT -o lo -j ACCEPT

### Allow DNS...
$IPT -A OUTPUT -p UDP -o $WAN_IFACE --dport 53 \
-m state --state NEW -j ACCEPT

### Allow HTTP...
$IPT -A OUTPUT -p TCP -o $WAN_IFACE --dport 80 \
-m state --state NEW -j ACCEPT

### Allow UDP port 80 (not sure what for)...
$IPT -A OUTPUT -p UDP -o $WAN_IFACE --dport 80 \
-m state --state NEW -j ACCEPT

### Allow HTTPS...
$IPT -A OUTPUT -p TCP -o $WAN_IFACE --dport 443 \
-m state --state NEW -j ACCEPT

### Log everything else before sending it to DROP...
$IPT -A OUTPUT -j LOG --log-prefix "OUTPUT DROP: "

Israfel2000 · 06-19-2006, 07:28 AM

Quote:

haha thanks for the help, I know of the dual attempts to close 21 and 25 I was just fishing for ideas

Hhm. I knew something was fishy.

Quote:

@inescapeableus: Could you answer some of the questions asked in this thread? If you are nmaping localhost, then that's likely why you are seeing open ports.

As a side note, filtering incoming traffic based on source ports is a *REALLY* bad idea. As an example, if a remote attacker sets his nmap scan to use a source port of 53, then he can scan every single port on your box as if there was no firewall at all. In fact, if you read the nmap man page subsection on source ports it describes this exact hole and recommends setting the source to port 53 for your scans because it's a common misconfiguration. Unless you are running a DNS, HTTP, or HTTPS server then you should only allow traffic that is in the ESTABLISHED or RELATED states. If you are running those services and need them to be publically accessible, then use something like the script win32sux posted.

Now that the tables have turned, can you answer the questions?

Capt_Caveman · 06-19-2006, 08:53 AM

Let's try to keep the replies related to *helping* the OP. My last reply was a bit on the harsh side, but that was because he's been using a badly misconfigured firewall that is a security risk, so it's important to get down to details and resolved as soon as possible.

Israfel2000 · 06-20-2006, 02:07 AM

Ok then. No problem. As for inescapeableus, you should use the firewall script that win32sux posted. As I too recomend it.