iptables seem to only sort of work...

MrSako · 08-25-2006, 08:45 PM

this is my iptables script

Code:

#!/bin/bash

IPT="/sbin/iptables"

$IPT -P INPUT DROP
$IPT -P OUTPUT ACCEPT
$IPT -P FORWARD DROP
$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

$IPT -F
$IPT -F -t nat
$IPT -F -t mangle

$IPT -X
$IPT -X -t nat
$IPT -X -t mangle

$IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A INPUT -i lo -j ACCEPT

$IPT -A INPUT -p TCP -m multiport --dports ' 21,22,25,80,110,3784,10000,14534,51234' -m state --state NEW -j ACCEPT
$IPT -A INPUT -p UDP -m multiport --dports ' 3785,8767' -m state --state NEW -j ACCEPT

i execute it and get no errors so i continue to do....

/sbin/service iptables save

then..

iptables -L -v -n

# /sbin/service iptables save
Saving firewall rules to /etc/sysconfig/iptables: [ OK ]
# iptables -L -v -n
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
23 1440 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 21,22,25,80,110,3784,10000,14534,51234 state NEW
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 3785,8767 state NEW

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 16 packets, 1824 bytes)
pkts bytes target prot opt in out source destination

so the output looks like it SHOULD be working. but it only kinda does. after saving it everything is accessable fine. then i notice after a few moinutes my port 80 and port 10000 arent accessable. but my port 22 (ssh server thank god) still is accessable. as well as my ventrilo server is still accessable (port 3784). i dont understand the logic behind why after a few minutes only some of them would be closed and others not.....

win32sux · 08-26-2006, 12:18 AM

that script looks familiar...

here's a souped-up version of it:

Code:

#!/bin/bash

IPT="/sbin/iptables"

$IPT -P INPUT DROP
$IPT -P OUTPUT ACCEPT
$IPT -P FORWARD DROP

$IPT -t mangle -P PREROUTING ACCEPT
$IPT -t mangle -P INPUT ACCEPT
$IPT -t mangle -P FORWARD ACCEPT
$IPT -t mangle -P OUTPUT ACCEPT
$IPT -t mangle -P POSTROUTING ACCEPT

$IPT -t nat -P PREROUTING ACCEPT
$IPT -t nat -P POSTROUTING ACCEPT
$IPT -t nat -P OUTPUT ACCEPT

$IPT -F
$IPT -F -t nat
$IPT -F -t mangle

$IPT -X
$IPT -X -t nat
$IPT -X -t mangle

$IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A INPUT -i lo -j ACCEPT

$IPT -A INPUT -p TCP -m multiport --dports \
21,22,25,80,110,3784,10000,14534,51234 \
-m state --state NEW -j ACCEPT

$IPT -A INPUT -p UDP -m multiport --dports \
3785,8767 -m state --state NEW -j ACCEPT

$IPT -A INPUT -j LOG --log-prefix "INPUT DROP: "

notice the LOG rule at the end, this should help you with the troubleshooting... tail your syslog at the time of the problem to see if you spot anything funky with INPUT DROPs...

having said that, it doesn't really sound like an iptables issue (so far)... does the iptables configuration look the same at the time of the problem?? are those daemons running and listening properly at the time of the problem (check with netstat, and post if possible)??

Code:

netstat -an | grep "LISTEN "

MrSako · 08-26-2006, 05:25 PM

doing the netstat (im assuming the output is everything that is currently listening on what port right?)

there are a couple ports listening that im not sure what they are.. which include.. 995, 953, and 53

which it now just hit me why 'some' ports were being blocked off and some werent. perhaps the issue is that im not opening the port for my bind dns server! it completely slipped my mind. which explains why i could for example connect to my ventrilo server but not my web server. i think its not that my web server is being closed off its that the bind isnt (and the ttl for my bind server dies out and its information isnt cached and its just not found)

this totally explains everything. except im not sure what i should be doing now. this is my output of the netstat command.

netstat -an | grep "LISTEN "
tcp 0 0 0.0.0.0:995 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:3784 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:110 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:10000 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN
tcp 0 0 72.232.208.45:53 0.0.0.0:* LISTEN
tcp 0 0 72.232.208.44:53 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN

this is a vps which has 2 ip address 72.232.208.44 and 72.232.208.45.

should i open 953, 955 and 53? (im abuot to try and figure out which one of those is the BIND server port)EDIT: according to google the default BIND DNS port is 53, i cant figure out what 953 and 955 are though. i just opened port 53 TCP and the same behavoir is happening. i bet opening 953 and 955 would fix it but i would like to know what they go with just to know whats going on on my server

win32sux · 08-26-2006, 07:44 PM

i have no idea what is running on your ports 953 and/or 955, sorry...

this might give you a clue (do it as root):

Code:

netstat -pantu | grep "LISTEN "

the last column should display the PID and name of the listening program...

MrSako · 08-26-2006, 08:40 PM

according to netstat -pantu | grep "LISTEN "

953 is something called "named" i have no idea what this is though, maybe someone else does?
955 is xinetd. i know this is some sort of program used for launching daemons or something. i don't think i have to configured with anything (i did try to set it up before but i coudlnt figure it out).

i have one question though... i applied the log line to my script but where does it go to? whats my syslog? also could i tell it to write to a specific file (so it wont mix my iptables log info with other stuff about my system just to keep orgination)

win32sux · 08-26-2006, 09:09 PM

Quote:

Originally Posted by MrSako

according to netstat -pantu | grep "LISTEN "

953 is something called "named" i have no idea what this is though, maybe someone else does?

yeah, i googled it and it seems it's the rndc, which is used for controlling BIND... notice how it's only listening on your loopback interface...

http://www.google.com/linux?&q=bind+rndc

Quote:

955 is xinetd. i know this is some sort of program used for launching daemons or something. i don't think i have to configured with anything (i did try to set it up before but i coudlnt figure it out).

it's a super-daemon...

http://en.wikipedia.org/wiki/Xinetd

http://www.xinetd.org/

Quote:

i have one question though... i applied the log line to my script but where does it go to? whats my syslog?

it's the /var/log/syslog file... you can monitor it in "real-time" like so:

Code:

tail -f /var/log/syslog

Quote:

also could i tell it to write to a specific file (so it wont mix my iptables log info with other stuff about my system just to keep orgination)

i'm sure it can be done, but i don't know how to (never had any need for it)... you can easily grep the syslog for "INPUT DROP" or whatever --log-prefix you used and you'll get only the iptables messages... example:

Code:

grep "INPUT DROP" /var/log/syslog | less

fotoguy · 08-26-2006, 09:35 PM

One thing I have noticecd is the flush rules are around the wrong way, your are setting default policy then flushing them, this will reset the defualt policy, try something like this:

Code:

IPT="/sbin/iptables"

$IPT -F
$IPT -F -t nat
$IPT -F -t mangle

$IPT -X
$IPT -X -t nat
$IPT -X -t mangle

$IPT -P INPUT DROP
$IPT -P OUTPUT ACCEPT
$IPT -P FORWARD DROP

$IPT -t mangle -P PREROUTING ACCEPT
$IPT -t mangle -P INPUT ACCEPT
$IPT -t mangle -P FORWARD ACCEPT
$IPT -t mangle -P OUTPUT ACCEPT
$IPT -t mangle -P POSTROUTING ACCEPT

$IPT -t nat -P PREROUTING ACCEPT
$IPT -t nat -P POSTROUTING ACCEPT
$IPT -t nat -P OUTPUT ACCEPT

$IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A INPUT -i lo -j ACCEPT

$IPT -A INPUT -p TCP -m multiport --dports \
21,22,25,80,110,3784,10000,14534,51234 \
-m state --state NEW -j ACCEPT

$IPT -A INPUT -p UDP -m multiport --dports \
3785,8767 -m state --state NEW -j ACCEPT

win32sux · 08-26-2006, 09:43 PM

Quote:

Originally Posted by fotoguy

One thing I have noticecd is the flush rules are around the wrong way, your are setting default policy then flushing them, this will reset the defualt policy

flushing does NOT affect policies in any way... try it and you'll see... making sure all your policies are set properly *before* you flush and delete chains is a very good idea...

MrSako · 08-27-2006, 12:46 AM

i cant figure out where iptables is writing the log info to in the first place.

i used find / syslog i cant find anything called syslog and also theres no syslog.conf this is a VPS they probally gave me a funky setup like they have with other things. but how do i figure out where its currently trying to write the log to?

win32sux · 08-27-2006, 12:49 AM

make sure you have the sysklogd package installed...

billymayday · 08-27-2006, 01:17 AM

Syslog on CentOS writes to /var/log/messages, but iptables will write a lot of messages to console - depending on how you've set it up.

win32sux · 08-27-2006, 01:20 AM

Quote:

Originally Posted by billymayday

Syslog on CentOS writes to /var/log/messages

thanks for clearing that up!

MrSako · 08-27-2006, 02:00 AM

/var/log/messages doesnt have any iptables log stuff. only pop3 stuff

is there not a location anywhere that says "iptables log by default saves to here"

fotoguy · 08-27-2006, 02:33 AM

Quote:

Originally Posted by win32sux

flushing does NOT affect policies in any way... try it and you'll see... making sure all your policies are set properly *before* you flush and delete chains is a very good idea...

You are correct, there you learn something new everyday. I was always under the impression that flushing not only deleted chains but would also reset the default policies as well, thanks for that.

MrSako · 08-27-2006, 04:55 AM

unfourtnately today the new thing i didnt learn was where my iptables is writing its log too