LinuxQuestions.org
Visit the LQ Articles and Editorials section
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices

Reply
 
Search this Thread
Old 08-08-2006, 10:40 AM   #31
blackhole54
Senior Member
 
Registered: Mar 2006
Posts: 1,896

Rep: Reputation: 61

I fear I led you astray in post #25. Following my example, the rule you used for accepting LAN connections only accepts TCP packets, blocking ICMP (used for pings) and UDP (used for DNS resolution). Below is your script with the changed rule in red.

I am not sure this accounts for everything I saw in your log, but it is at least a good start. Let me know if there are still problems, and I apologize for my mistake.

Code:
#!/bin/sh

#  Firewall script

#  Define interfaces and IP addresses for Internet and LAN

EXTIF="eth0"
EXTIF_IP="200.17.xxx.xxx"

INTIF="eth1"
INTIF_NET="192.168.30.0/24"

#  Define the TCP ports the should be accessible from Internet and LAN
#  These should be space separated, quoted strings.

#  Internet Access:
#      TCP UDP protocol
#      80      http
#     443      https
#      25      smtp  (mail)
#      53  53  DNS 

EXT_TCP="80 443 25 53"
EXT_UDP="53"

#  Internal LAN Access: all ports open


#  Command definitions:

IPTABLES="/sbin/iptables"
MODPROBE="/sbin/modprobe"

#  Set policies for each chain

$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -P FORWARD DROP
$IPTABLES -t nat -P PREROUTING ACCEPT
$IPTABLES -t nat -P POSTROUTING ACCEPT
$IPTABLES -t nat -P OUTPUT ACCEPT
$IPTABLES -t mangle -P PREROUTING ACCEPT
$IPTABLES -t mangle -P OUTPUT ACCEPT

#  Flush all standard chains and delete all user chains

$IPTABLES -F
$IPTABLES -F -t nat
$IPTABLES -F -t mangle

$IPTABLES -X
$IPTABLES -X -t nat
$IPTABLES -X -t mangle

#  Load modules for iptables

$MODPROBE ip_conntrack_ftp
$MODPROBE ip_nat_ftp
$MODPROBE ip_conntrack_irc
$MODPROBE ip_nat_irc

#  --------------  INPUT Chain Firewall Rules ---------------
#
#  Accept all established connections and all loopback packets

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

#  Rules which allow new Internet connections

for port in $EXT_TCP; do
   $IPTABLES -A INPUT -p TCP -i $EXTIF --dport $port \
      -m state --state NEW -j ACCEPT
done


for port in $EXT_UDP; do
   $IPTABLES -A INPUT -p UDP -i $EXTIF --dport $port \
      -m state --state NEW -j ACCEPT
done

#  Rules which allow new LAN connections

 $IPTABLES -A INPUT -s $INTIF_NET \
       -m state --state NEW -j ACCEPT

#  Policy drops everything else.  But first log them.

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

#  --------------  FORWARD Chain Firewall Rules ---------------
#
#  Accept establish connections.
#  Accept new connections from $LAN that are destined for the Internet
#  Log any packets that will be dropped

$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A FORWARD -o $EXTIF -s $INTIF_NET \
   -m state --state NEW -j ACCEPT
$IPTABLES -A FORWARD -j LOG --log-prefix "FORWARD DROP: "


#  --------------  POSTROUTING Chain Firewall Rules ---------------
#
#  SNAT all LAN originated packets destined for the Internet.


$IPTABLES -t nat -A POSTROUTING -o $EXTIF -s $INTIF_NET \
   -j SNAT --to $EXTIF_IP

Last edited by blackhole54; 08-08-2006 at 10:41 AM.
 
Old 08-08-2006, 12:45 PM   #32
heberrdacruz
LQ Newbie
 
Registered: Jun 2006
Location: Brazil
Distribution: Fedora 11
Posts: 23

Original Poster
Rep: Reputation: 15
Quote:
Originally Posted by blackhole54
... and I apologize for my mistake.
I beg to differ, I should apologize for not seen this.
Thank you very much for your prompt reply.
It seems to be working fine now. However, I am seen some forward drops, which I was not expecting. I am sorry for the length of the log I included, but I wanted to give the complete information.
Code:
Aug  8 14:22:53 newton kernel: INPUT DROP: IN=eth0 OUT= MAC=00:50:2c:06:94:a3:00:xx:xx:xx:xx:xx:xx:xx SRC=64.72.124.159 DST=200.17.xxx.xxx LEN=1500 TOS=0x00 PREC=0x00 TTL=49 ID=44860 DF PROTO=TCP SPT=80 DPT=1241 WINDOW=1728 RES=0x00 ACK URGP=0 
Aug  8 14:23:09 newton kernel: INPUT DROP: IN=eth0 OUT= MAC=00:50:2c:06:94:a3:00:xx:xx:xx:xx:xx:xx:xx SRC=64.72.124.159 DST=200.17.xxx.xxx LEN=1500 TOS=0x00 PREC=0x00 TTL=49 ID=52813 DF PROTO=TCP SPT=80 DPT=1248 WINDOW=1728 RES=0x00 ACK URGP=0 
Aug  8 14:23:16 newton kernel: INPUT DROP: IN=eth0 OUT= MAC=00:50:2c:06:94:a3:00:xx:xx:xx:xx:xx:xx:xx SRC=207.68.178.61 DST=200.17.xxx.xxx LEN=40 TOS=0x00 PREC=0x00 TTL=240 ID=59450 PROTO=TCP SPT=80 DPT=4955 WINDOW=9300 RES=0x00 RST URGP=0 
Aug  8 14:23:27 newton kernel: FORWARD DROP: IN=eth1 OUT=eth0 SRC=192.168.30.137 DST=64.72.124.159 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=23048 DF PROTO=TCP SPT=1248 DPT=80 WINDOW=64240 RES=0x00 ACK FIN URGP=0 
Aug  8 14:23:27 newton kernel: FORWARD DROP: IN=eth1 OUT=eth0 SRC=192.168.30.137 DST=64.72.124.159 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=23058 DF PROTO=TCP SPT=1241 DPT=80 WINDOW=64240 RES=0x00 ACK FIN URGP=0 
Aug  8 14:23:30 newton kernel: FORWARD DROP: IN=eth1 OUT=eth0 SRC=192.168.30.137 DST=64.72.124.159 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=23235 DF PROTO=TCP SPT=1241 DPT=80 WINDOW=64240 RES=0x00 ACK FIN URGP=0 
Aug  8 14:23:30 newton kernel: FORWARD DROP: IN=eth1 OUT=eth0 SRC=192.168.30.137 DST=64.72.124.159 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=23236 DF PROTO=TCP SPT=1248 DPT=80 WINDOW=64240 RES=0x00 ACK FIN URGP=0 
Aug  8 14:23:36 newton kernel: FORWARD DROP: IN=eth1 OUT=eth0 SRC=192.168.30.137 DST=64.72.124.159 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=23803 DF PROTO=TCP SPT=1241 DPT=80 WINDOW=64240 RES=0x00 ACK FIN URGP=0 
Aug  8 14:23:36 newton kernel: FORWARD DROP: IN=eth1 OUT=eth0 SRC=192.168.30.137 DST=64.72.124.159 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=23804 DF PROTO=TCP SPT=1248 DPT=80 WINDOW=64240 RES=0x00 ACK FIN URGP=0 
Aug  8 14:23:47 newton kernel: FORWARD DROP: IN=eth1 OUT=eth0 SRC=192.168.30.137 DST=64.72.124.159 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=24933 DF PROTO=TCP SPT=1241 DPT=80 WINDOW=64240 RES=0x00 ACK FIN URGP=0 
Aug  8 14:23:47 newton kernel: FORWARD DROP: IN=eth1 OUT=eth0 SRC=192.168.30.137 DST=64.72.124.159 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=24934 DF PROTO=TCP SPT=1248 DPT=80 WINDOW=64240 RES=0x00 ACK FIN URGP=0 
Aug  8 14:24:02 newton kernel: INPUT DROP: IN=eth0 OUT= MAC=00:50:2c:06:94:a3:00:xx:xx:xx:xx:xx:xx:xx SRC=64.92.212.235 DST=200.17.xxx.xxx LEN=1500 TOS=0x00 PREC=0x00 TTL=49 ID=3070 DF PROTO=TCP SPT=80 DPT=6235 WINDOW=5840 RES=0x00 ACK URGP=0 
Aug  8 14:24:10 newton kernel: FORWARD DROP: IN=eth1 OUT=eth0 SRC=192.168.30.137 DST=64.72.124.159 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=26068 DF PROTO=TCP SPT=1241 DPT=80 WINDOW=64240 RES=0x00 ACK FIN URGP=0 
Aug  8 14:24:10 newton kernel: FORWARD DROP: IN=eth1 OUT=eth0 SRC=192.168.30.137 DST=64.72.124.159 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=26069 DF PROTO=TCP SPT=1248 DPT=80 WINDOW=64240 RES=0x00 ACK FIN URGP=0 
Aug  8 14:24:13 newton kernel: INPUT DROP: IN=eth0 OUT= MAC=00:50:2c:06:94:a3:00:xx:xx:xx:xx:xx:xx:xx SRC=64.92.212.235 DST=200.17.xxx.xxx LEN=1500 TOS=0x00 PREC=0x00 TTL=49 ID=3072 DF PROTO=TCP SPT=80 DPT=6235 WINDOW=5840 RES=0x00 ACK URGP=0 
Aug  8 14:24:41 newton kernel: FORWARD DROP: IN=eth1 OUT=eth0 SRC=192.168.30.137 DST=64.14.123.140 LEN=449 TOS=0x00 PREC=0x00 TTL=63 ID=26248 DF PROTO=TCP SPT=1164 DPT=80 WINDOW=64240 RES=0x00 ACK PSH FIN URGP=0 
Aug  8 14:24:47 newton kernel: INPUT DROP: IN=eth0 OUT= MAC=00:50:2c:06:94:a3:00:xx:xx:xx:xx:xx:xx:xx SRC=217.146.185.136 DST=200.17.xxx.xxx LEN=64 TOS=0x00 PREC=0x00 TTL=49 ID=30573 PROTO=ICMP TYPE=8 CODE=0 ID=10678 SEQ=0 
Aug  8 14:24:47 newton kernel: INPUT DROP: IN=eth0 OUT= MAC=00:50:2c:06:94:a3:00:xx:xx:xx:xx:xx:xx:xx SRC=217.146.185.136 DST=200.17.xxx.xxx LEN=64 TOS=0x00 PREC=0x00 TTL=49 ID=31256 PROTO=ICMP TYPE=8 CODE=0 ID=10678 SEQ=256 
Aug  8 14:24:48 newton kernel: INPUT DROP: IN=eth0 OUT= MAC=00:50:2c:06:94:a3:00:xx:xx:xx:xx:xx:xx:xx SRC=217.146.185.136 DST=200.17.xxx.xxx LEN=64 TOS=0x00 PREC=0x00 TTL=49 ID=31855 PROTO=ICMP TYPE=8 CODE=0 ID=10678 SEQ=512 
Aug  8 14:24:48 newton kernel: INPUT DROP: IN=eth0 OUT= MAC=00:50:2c:06:94:a3:00:xx:xx:xx:xx:xx:xx:xx SRC=217.146.185.136 DST=200.17.xxx.xxx LEN=64 TOS=0x00 PREC=0x00 TTL=49 ID=32604 PROTO=ICMP TYPE=8 CODE=0 ID=10678 SEQ=768 
Aug  8 14:24:57 newton kernel: FORWARD DROP: IN=eth1 OUT=eth0 SRC=192.168.30.137 DST=64.72.124.159 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=26329 DF PROTO=TCP SPT=1241 DPT=80 WINDOW=64240 RES=0x00 ACK FIN URGP=0 
Aug  8 14:24:57 newton kernel: FORWARD DROP: IN=eth1 OUT=eth0 SRC=192.168.30.137 DST=64.72.124.159 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=26330 DF PROTO=TCP SPT=1248 DPT=80 WINDOW=64240 RES=0x00 ACK FIN URGP=0 
Aug  8 14:25:18 newton kernel: FORWARD DROP: IN=eth1 OUT=eth0 SRC=192.168.30.137 DST=64.233.185.83 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=26496 DF PROTO=TCP SPT=1614 DPT=80 WINDOW=65073 RES=0x00 ACK FIN URGP=0 
Aug  8 14:25:22 newton kernel: INPUT DROP: IN=eth0 OUT= MAC=00:50:2c:06:94:a3:00:xx:xx:xx:xx:xx:xx:xx SRC=64.92.212.235 DST=200.17.xxx.xxx LEN=1500 TOS=0x00 PREC=0x00 TTL=49 ID=3076 DF PROTO=TCP SPT=80 DPT=6235 WINDOW=5840 RES=0x00 ACK URGP=0 
Aug  8 14:25:41 newton kernel: FORWARD DROP: IN=eth1 OUT=eth0 SRC=192.168.30.137 DST=64.86.91.82 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=27434 DF PROTO=TCP SPT=1574 DPT=80 WINDOW=64240 RES=0x00 ACK FIN URGP=0 
Aug  8 14:25:43 newton kernel: FORWARD DROP: IN=eth1 OUT=eth0 SRC=192.168.30.137 DST=64.233.185.83 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=27514 DF PROTO=TCP SPT=1614 DPT=80 WINDOW=65073 RES=0x00 ACK FIN URGP=0 
Aug  8 14:26:16 newton kernel: INPUT DROP: IN=eth0 OUT= MAC=00:50:2c:06:94:a3:00:xx:xx:xx:xx:xx:xx:xx SRC=64.86.91.82 DST=200.17.xxx.xxx LEN=1500 TOS=0x00 PREC=0x00 TTL=50 ID=26199 DF PROTO=TCP SPT=80 DPT=1639 WINDOW=32850 RES=0x00 ACK URGP=0 
Aug  8 14:26:34 newton kernel: FORWARD DROP: IN=eth1 OUT=eth0 SRC=192.168.30.137 DST=64.233.185.83 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=31365 DF PROTO=TCP SPT=1614 DPT=80 WINDOW=65073 RES=0x00 ACK FIN URGP=0 
Aug  8 14:26:50 newton kernel: INPUT DROP: IN=eth0 OUT= MAC=00:50:2c:06:94:a3:00:xx:xx:xx:xx:xx:xx:xx SRC=64.86.91.82 DST=200.17.xxx.xxx LEN=1500 TOS=0x00 PREC=0x00 TTL=50 ID=51575 DF PROTO=TCP SPT=80 DPT=1639 WINDOW=32850 RES=0x00 ACK URGP=0 
Aug  8 14:26:54 newton kernel: INPUT DROP: IN=eth0 OUT= MAC=00:50:2c:06:94:a3:00:xx:xx:xx:xx:xx:xx:xx SRC=64.92.212.235 DST=200.17.xxx.xxx LEN=1500 TOS=0x00 PREC=0x00 TTL=49 ID=3078 DF PROTO=TCP SPT=80 DPT=6235 WINDOW=5840 RES=0x00 ACK URGP=0 
Aug  8 14:27:35 newton kernel: INPUT DROP: IN=eth0 OUT= MAC=00:50:2c:06:94:a3:00:xx:xx:xx:xx:xx:xx:xx SRC=64.86.91.82 DST=200.17.xxx.xxx LEN=1500 TOS=0x00 PREC=0x00 TTL=50 ID=59680 DF PROTO=TCP SPT=80 DPT=1639 WINDOW=32850 RES=0x00 ACK URGP=0 
Aug  8 14:27:57 newton kernel: FORWARD DROP: IN=eth1 OUT=eth0 SRC=192.168.30.137 DST=64.14.123.138 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=39933 DF PROTO=TCP SPT=1147 DPT=80 WINDOW=64240 RES=0x00 ACK FIN URGP=0
Any ideas?
 
Old 08-08-2006, 01:12 PM   #33
heberrdacruz
LQ Newbie
 
Registered: Jun 2006
Location: Brazil
Distribution: Fedora 11
Posts: 23

Original Poster
Rep: Reputation: 15
Further analysis showed that all but two of the forward drops were to DPT=80. The exceptions were
Code:
Aug  8 10:15:07 newton kernel: FORWARD DROP: IN=eth1 OUT=eth0 SRC=192.168.30.92 DST=207.46.27.77 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=60794 DF PROTO=TCP SPT=39430 DPT=1863 WINDOW=16022 RES=0x00 ACK FIN URGP=0
Aug  8 14:44:54 newton kernel: FORWARD DROP: IN=eth1 OUT=eth1 SRC=192.168.30.148 DST=169.254.242.28 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=23198 DF PROTO=TCP SPT=1465 DPT=1135 WINDOW=65535 RES=0x00 SYN URGP=0
 
Old 08-08-2006, 01:45 PM   #34
win32sux
Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 371Reputation: 371Reputation: 371Reputation: 371
hi heberrdacruz... i've tweaked the latest version of the script (post #31)... they are minor tweaks, but they should be worthwhile...

it is my understanding that you've in fact normalized the physical connections to your NICs, right?? if that's the case, then this should work fine:
Code:
#!/bin/sh

EXTIF="eth0"
EXTIF_IP="200.17.xxx.xxx"

INTIF="eth1"
INTIF_NET="192.168.30.0/24"

EXT_TCP_PORTS="80 443 25 53"
EXT_UDP_PORTS="53"

IPTABLES="/sbin/iptables"
MODPROBE="/sbin/modprobe"

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

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

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

$IPTABLES -F
$IPTABLES -F -t nat
$IPTABLES -F -t mangle

$IPTABLES -X
$IPTABLES -X -t nat
$IPTABLES -X -t mangle

$MODPROBE ip_conntrack_ftp
$MODPROBE ip_nat_ftp
$MODPROBE ip_conntrack_irc
$MODPROBE ip_nat_irc

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

for port in $EXT_TCP_PORTS; do
   $IPTABLES -A INPUT -p TCP -i $EXTIF --dport $port \
   -m state --state NEW -j ACCEPT
done

for port in $EXT_UDP_PORTS; do
   $IPTABLES -A INPUT -p UDP -i $EXTIF --dport $port \
   -m state --state NEW -j ACCEPT
done

$IPTABLES -A INPUT -i $INTIF -s $INTIF_NET \
-m state --state NEW -j ACCEPT

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

$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

$IPTABLES -A FORWARD -i $INTIF -o $EXTIF -s $INTIF_NET \
-m state --state NEW -j ACCEPT

$IPTABLES -A FORWARD -j LOG --log-prefix "FORWARD DROP: "

$IPTABLES -t nat -A POSTROUTING -o $EXTIF -j SNAT \
--to-source $EXTIF_IP
not sure what to tell you about those FORWARD DROPs you are seeing... perhaps blackhole54 does... they might just be old connections which weren't in the state table anymore... had you just rebooted?? have you experienced weird behavior from clients on the LAN during these DROPs??

Last edited by win32sux; 08-08-2006 at 03:08 PM.
 
Old 08-08-2006, 03:47 PM   #35
heberrdacruz
LQ Newbie
 
Registered: Jun 2006
Location: Brazil
Distribution: Fedora 11
Posts: 23

Original Poster
Rep: Reputation: 15
Thank you very much, win32sux, for your help.
Quote:
Originally Posted by win32sux
it is my understanding that you've in fact normalized the physical connections to your NICs, right??
You understand correctly. We know have a switch which has only connections to our external network and the external interfaces from the servers.

Quote:
had you just rebooted??
No. As I am at a trail phase I just run the script.
After running your script, I got input drops in the internal interface, when I was expecting none.
Code:
Aug  8 16:54:07 newton kernel: INPUT DROP: IN=eth1 OUT= MAC=00:01:01:c7:28:68:00:gg:gg:gg:gg:gg:gg:gg SRC=192.168.30.136 DST=192.168.30.15 LEN=40 TOS=0x00 PREC=0x00 TTL=128 ID=50961 DF PROTO=TCP SPT=2439 DPT=8080 WINDOW=17053 RES=0x00 ACK FIN URGP=0 
Aug  8 16:54:30 newton kernel: INPUT DROP: IN=eth1 OUT= MAC=00:01:01:c7:28:68:00:hh:hh:hh:hh:hh:hh:hh SRC=192.168.30.188 DST=192.168.30.15 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=121 DF PROTO=TCP SPT=41226 DPT=443 WINDOW=0 RES=0x00 RST URGP=0 
Aug  8 16:54:30 newton kernel: INPUT DROP: IN=eth1 OUT= MAC=00:01:01:c7:28:68:00:hh:hh:hh:hh:hh:hh:hh SRC=192.168.30.188 DST=192.168.30.15 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=122 DF PROTO=TCP SPT=41226 DPT=443 WINDOW=0 RES=0x00 RST URGP=0 
Aug  8 16:54:30 newton kernel: INPUT DROP: IN=eth1 OUT= MAC=00:01:01:c7:28:68:00:hh:hh:hh:hh:hh:hh:hh SRC=192.168.30.188 DST=192.168.30.15 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=124 DF PROTO=TCP SPT=41224 DPT=443 WINDOW=0 RES=0x00 RST URGP=0 
Aug  8 16:54:30 newton kernel: INPUT DROP: IN=eth1 OUT= MAC=00:01:01:c7:28:68:00:hh:hh:hh:hh:hh:hh:hh SRC=192.168.30.188 DST=192.168.30.15 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=125 DF PROTO=TCP SPT=41224 DPT=443 WINDOW=0 RES=0x00 RST URGP=0 
Aug  8 16:54:32 newton kernel: INPUT DROP: IN=eth1 OUT= MAC=00:01:01:c7:28:68:00:ii:ii:ii:ii:ii:ii:ii SRC=192.168.30.153 DST=192.168.30.15 LEN=40 TOS=0x00 PREC=0x00 TTL=128 ID=16439 DF PROTO=TCP SPT=1599 DPT=8080 WINDOW=16231 RES=0x00 ACK FIN URGP=0 
Aug  8 16:54:32 newton kernel: INPUT DROP: IN=eth1 OUT= MAC=00:01:01:c7:28:68:00:jj:jj:jj:jj:jj:jj:jjSRC=192.168.30.170 DST=192.168.30.15 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=11120 DF PROTO=TCP SPT=33357 DPT=8080 WINDOW=9730 RES=0x00 ACK FIN URGP=0 
Aug  8 16:54:34 newton kernel: INPUT DROP: IN=eth1 OUT= MAC=00:01:01:c7:28:68:00:ii:ii:ii:ii:ii:ii:ii SRC=192.168.30.153 DST=192.168.30.15 LEN=40 TOS=0x00 PREC=0x00 TTL=128 ID=16626 DF PROTO=TCP SPT=1599 DPT=8080 WINDOW=16231 RES=0x00 ACK FIN URGP=0 
Aug  8 16:54:38 newton kernel: INPUT DROP: IN=eth1 OUT= MAC=00:01:01:c7:28:68:00:ii:ii:ii:ii:ii:ii:ii SRC=192.168.30.153 DST=192.168.30.15 LEN=40 TOS=0x00 PREC=0x00 TTL=128 ID=16670 DF PROTO=TCP SPT=1599 DPT=8080 WINDOW=16231 RES=0x00 ACK FIN URGP=0 
Aug  8 16:54:39 newton kernel: INPUT DROP: IN=eth1 OUT= MAC=00:01:01:c7:28:68:00:jj:jj:jj:jj:jj:jj:jjSRC=192.168.30.170 DST=192.168.30.15 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=65004 DF PROTO=TCP SPT=33356 DPT=8080 WINDOW=33304 RES=0x00 ACK FIN URGP=0 
Aug  8 16:54:39 newton kernel: INPUT DROP: IN=eth1 OUT= MAC=00:01:01:c7:28:68:00:ii:ii:ii:ii:ii:ii:ii SRC=192.168.30.153 DST=192.168.30.15 LEN=40 TOS=0x00 PREC=0x00 TTL=128 ID=16679 DF PROTO=TCP SPT=1598 DPT=8080 WINDOW=0 RES=0x00 ACK RST URGP=0 
Aug  8 16:54:45 newton kernel: INPUT DROP: IN=eth1 OUT= MAC=00:01:01:c7:28:68:00:ii:ii:ii:ii:ii:ii:ii SRC=192.168.30.153 DST=192.168.30.15 LEN=40 TOS=0x00 PREC=0x00 TTL=128 ID=16691 DF PROTO=TCP SPT=1599 DPT=8080 WINDOW=16231 RES=0x00 ACK FIN URGP=0 
Aug  8 16:54:58 newton kernel: INPUT DROP: IN=eth1 OUT= MAC=00:01:01:c7:28:68:00:kk:kk:kk:kk:kk:kk:kk SRC=192.168.30.150 DST=192.168.30.15 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=15555 DF PROTO=TCP SPT=18518 DPT=8080 WINDOW=3546 RES=0x00 ACK FIN URGP=0 
Aug  8 16:54:59 newton kernel: INPUT DROP: IN=eth1 OUT= MAC=00:01:01:c7:28:68:00:kk:kk:kk:kk:kk:kk:kk SRC=192.168.30.150 DST=192.168.30.15 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=15557 DF PROTO=TCP SPT=18518 DPT=8080 WINDOW=3546 RES=0x00 ACK FIN URGP=0 
Aug  8 16:54:59 newton kernel: INPUT DROP: IN=eth1 OUT= MAC=00:01:01:c7:28:68:00:kk:kk:kk:kk:kk:kk:kk SRC=192.168.30.150 DST=192.168.30.15 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=15559 DF PROTO=TCP SPT=18518 DPT=8080 WINDOW=3546 RES=0x00 ACK FIN URGP=0 
Aug  8 16:55:00 newton kernel: INPUT DROP: IN=eth1 OUT= MAC=00:01:01:c7:28:68:00:kk:kk:kk:kk:kk:kk:kk SRC=192.168.30.150 DST=192.168.30.15 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=15561 DF PROTO=TCP SPT=18518 DPT=8080 WINDOW=3546 RES=0x00 ACK FIN URGP=0 
Aug  8 16:55:00 newton kernel: INPUT DROP: IN=eth1 OUT= MAC=00:01:01:c7:28:68:00:ii:ii:ii:ii:ii:ii:ii SRC=192.168.30.153 DST=192.168.30.15 LEN=40 TOS=0x00 PREC=0x00 TTL=128 ID=16692 DF PROTO=TCP SPT=1599 DPT=8080 WINDOW=16231 RES=0x00 ACK FIN URGP=0 
Aug  8 16:55:01 newton kernel: INPUT DROP: IN=eth1 OUT= MAC=00:01:01:c7:28:68:00:kk:kk:kk:kk:kk:kk:kk SRC=192.168.30.150 DST=192.168.30.15 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=15563 DF PROTO=TCP SPT=18518 DPT=8080 WINDOW=3546 RES=0x00 ACK FIN URGP=0 
Aug  8 16:55:05 newton kernel: INPUT DROP: IN=eth1 OUT= MAC=00:01:01:c7:28:68:00:kk:kk:kk:kk:kk:kk:kk SRC=192.168.30.150 DST=192.168.30.15 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=15565 DF PROTO=TCP SPT=18518 DPT=8080 WINDOW=3546 RES=0x00 ACK FIN URGP=0 
Aug  8 16:55:11 newton kernel: INPUT DROP: IN=eth1 OUT= MAC=00:01:01:c7:28:68:00:kk:kk:kk:kk:kk:kk:kk SRC=192.168.30.150 DST=192.168.30.15 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=15567 DF PROTO=TCP SPT=18518 DPT=8080 WINDOW=3546 RES=0x00 ACK FIN URGP=0 
Aug  8 16:55:24 newton kernel: INPUT DROP: IN=eth1 OUT= MAC=00:01:01:c7:28:68:00:ll:ll:ll:ll:ll:ll:ll SRC=192.168.30.109 DST=192.168.30.15 LEN=40 TOS=0x00 PREC=0x00 TTL=128 ID=13634 DF PROTO=TCP SPT=1500 DPT=8080 WINDOW=0 RES=0x00 ACK RST URGP=0 
Aug  8 16:55:24 newton kernel: INPUT DROP: IN=eth1 OUT= MAC=00:01:01:c7:28:68:00:kk:kk:kk:kk:kk:kk:kk SRC=192.168.30.150 DST=192.168.30.15 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=15569 DF PROTO=TCP SPT=18518 DPT=8080 WINDOW=3546 RES=0x00 ACK FIN URGP=0 
Aug  8 16:55:31 newton kernel: INPUT DROP: IN=eth1 OUT= MAC=00:01:01:c7:28:68:00:ii:ii:ii:ii:ii:ii:ii SRC=192.168.30.153 DST=192.168.30.15 LEN=40 TOS=0x00 PREC=0x00 TTL=128 ID=16805 DF PROTO=TCP SPT=1599 DPT=8080 WINDOW=16231 RES=0x00 ACK FIN URGP=0 
Aug  8 16:55:50 newton kernel: INPUT DROP: IN=eth1 OUT= MAC=00:01:01:c7:28:68:00:kk:kk:kk:kk:kk:kk:kk SRC=192.168.30.150 DST=192.168.30.15 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=15571 DF PROTO=TCP SPT=18518 DPT=8080 WINDOW=3546 RES=0x00 ACK FIN URGP=0 
Aug  8 17:03:56 newton kernel: INPUT DROP: IN=eth1 OUT= MAC=00:01:01:c7:28:68:00:ll:ll:ll:ll:ll:ll:ll SRC=192.168.30.109 DST=192.168.30.15 LEN=40 TOS=0x00 PREC=0x00 TTL=128 ID=14487 DF PROTO=TCP SPT=1515 DPT=8080 WINDOW=17520 RES=0x00 ACK FIN URGP=0
 
Old 08-08-2006, 08:57 PM   #36
win32sux
Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 371Reputation: 371Reputation: 371Reputation: 371
interesting... i've gone over the script line by line and can't find anything out of the ordinary... hmmm... it should be pointed-out that most of those are ACK/FIN packets, which are part of the connection termination phase...

which distro and kernel versions you are running??
Code:
uname -a
i ask cuz if you're running something extremely old and unmaintained, for example, then that *might* have something to do with it... i'm just spitballing, of course... for now, i can't really think of any other explanation of why you'd get so many DROPs from within... anyody??

Last edited by win32sux; 08-08-2006 at 11:54 PM.
 
Old 08-09-2006, 12:10 AM   #37
blackhole54
Senior Member
 
Registered: Mar 2006
Posts: 1,896

Rep: Reputation: 61
Quote:
Originally Posted by heberrdacruz
Further analysis showed that all but two of the forward drops were to DPT=80. The exceptions were
Code:
Aug  8 10:15:07 newton kernel: FORWARD DROP: IN=eth1 OUT=eth0 SRC=192.168.30.92 DST=207.46.27.77 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=60794 DF PROTO=TCP SPT=39430 DPT=1863 WINDOW=16022 RES=0x00 ACK FIN URGP=0
Aug  8 14:44:54 newton kernel: FORWARD DROP: IN=eth1 OUT=eth1 SRC=192.168.30.148 DST=169.254.242.28 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=23198 DF PROTO=TCP SPT=1465 DPT=1135 WINDOW=65535 RES=0x00 SYN URGP=0
I am not sure why the first packet got dropped. Along with win32sux I'lll note that it is ACK-FIN (I'm not totally sure of the shutdown handshake) and wonder if the kernel no longer considers the connection active. Maybe this is a repeat packet from an impatient client and the first one shut down the connection? Win32sux, is that plausable?

The second packet has to do with that (weird?) entry in your routing table:

Code:
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth1
which routes this packet out eth1.

The rule in the FORWARD chain for NEW packets only accepts them if the are going out eth0. You could let packets like this out by removing "-o $EXTIF" from that rule. Since I don't understand why your routing table contains that entry, I can't comment whether you should do this. If you do wan't to let this packet through, I would wonder whether it should also be SNATed.

I am also wondering about all of those packets the INPUT chain is blocking The echo requests (pings) being blocked is probably a good thing (at least I like to block those). But what are all of those SPT=80's. Is that just somebody's mischief, or are you trying to do web access from newton? (EDIT: I should clarify -- I mean are you using a browser on newton trying to access some other website.)

@win32sux

Quote:
Originally Posted by win32sux
... cuz if you're running something _extremely_ old, for example, then that *might* have something to do with it...
heberrdacruz can of course answer this for you, but since he probably won't be posting till morning, I thought I would let you know he is running FC5 on newton and RH9 on another box he has sometimes mentioned.

Last edited by blackhole54; 08-09-2006 at 12:24 AM.
 
Old 08-09-2006, 12:44 AM   #38
win32sux
Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 371Reputation: 371Reputation: 371Reputation: 371
Quote:
Originally Posted by blackhole54
I am not sure why the first packet got dropped. Along with win32sux I'lll note that it is ACK-FIN (I'm not totally sure of the shutdown handshake) and wonder if the kernel no longer considers the connection active. Maybe this is a repeat packet from an impatient client and the first one shut down the connection? Win32sux, is that plausable?
sounds plausible to me, although i would then wonder why the ACK wasn't received (making the FIN/ACK get re-sent)...

Quote:
The second packet has to do with that (weird?) entry in your routing table:

Code:
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth1
which routes this packet out eth1.

The rule in the FORWARD chain for NEW packets only accepts them if the are going out eth0. You could let packets like this out by removing "-o $EXTIF" from that rule. Since I don't understand why your routing table contains that entry, I can't comment whether you should do this. If you do wan't to let this packet through, I would wonder whether it should also be SNATed.
yeah, i really think that said entry should be removed from the table, since it seems it might be bogus, from what one could interpret from this post:
Quote:
Originally Posted by heberrdacruz
I don’t know where the 169 ... comes from.
IMHO the outgoing interface specifier should be left there, for maximum security and control... if special routing is needed for the "weird" packets, a rule should be added specially for them, while leaving the main rule intact... this is just my opinion, of course...

Quote:
@win32sux


heberrdacruz can of course answer this for you, but since he probably won't be posting till morning, I thought I would let you know he is running FC5 on newton and RH9 on another box he has sometimes mentioned.
oh, okay... FC5 is super new so no way it's an aged kernel issue... thanks for clarifying!!!

Last edited by win32sux; 08-09-2006 at 03:08 AM.
 
Old 08-09-2006, 04:24 AM   #39
blackhole54
Senior Member
 
Registered: Mar 2006
Posts: 1,896

Rep: Reputation: 61
Quote:
Originally Posted by win32sux
sounds plausible to me, although i would then wonder why the ACK wasn't received (making the FIN/ACK get re-sent)...
I was thinking it might be a timing issue. I.e. the ACK was coming back through newton just about the time the client decided to resend. I.e. I'm trying to blame this on Internet latency (or weird MS programing! -- at least some clients are MS). The other idea that occured to me about this (as well as an entry in the log entries posted in #30) was wondering if it could be considered an "invalid" packet. But I've never researched what that really means.
 
Old 08-09-2006, 08:05 AM   #40
heberrdacruz
LQ Newbie
 
Registered: Jun 2006
Location: Brazil
Distribution: Fedora 11
Posts: 23

Original Poster
Rep: Reputation: 15
Thank you very much for all the comments. A lot has happened since my last entry.
Thank you, win32sux, for the enlightment on TCP protocol. I have much to learn.
Quote:
Originally Posted by win32sux
which distro and kernel versions you are running??
Code:
Linux xxx.xxx.xxx.xxx 2.6.17-1.2157_FC5 #1 Tue Jul 11 22:55:46 EDT 2006 i686
athlon i386 GNU/Linux
Quote:
Originally Posted by blackhole54
Code:
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth1
This entry is a mystery to me. I didnít create it and I canít figure how to remove, or even if I should remove it.
Quote:
Originally Posted by blackhole54
are you using a browser on newton trying to access some other website.)
Not to my knowledge. This machine does not run GUI (it start on runlevel 3). It runs squid, however.
Quote:
Originally Posted by win32sux
yeah, I really think that said entry should be removed from the table, since it seems it might be bogus,
Do you mean the 169.254.0.0 entry from the network?
Quote:
Originally Posted by win32sux
IMHO the outgoing interface specifier should be left there,
Do you mean the iptable rule?
Quote:
Originally Posted by blackhole54
I was thinking it might be a timing issue.
Is there anything I can do about that?
Would it make any difference if I saved the rules specified by the script as standard for iptables and rebooted the computer?
 
Old 08-09-2006, 01:09 PM   #41
win32sux
Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 371Reputation: 371Reputation: 371Reputation: 371
Quote:
Originally Posted by heberrdacruz
This entry is a mystery to me. I didn’t create it and I can’t figure how to remove, or even if I should remove it.
i don't have a red hat box to try this on... but i did a quick google and it seems this 169.254.0.0 thing might be due to zerconf... according to what i read, to disable it you would put a line like:
Code:
NOZEROCONF=yes
inside your /etc/sysconfig/network file... i'm pretty sure you would then need to restart the network, or reboot...

Quote:
Do you mean the 169.254.0.0 entry from the network?
yeah, as described above...

Quote:
Do you mean the iptable rule?
yeah, i was referring to this rule in particular:
Code:
$IPTABLES -A FORWARD -i $INTIF -o $EXTIF -s $INTIF_NET \
-m state --state NEW -j ACCEPT
in other words, my opinion was/is that you should leave it like that...

Last edited by win32sux; 08-09-2006 at 01:14 PM.
 
Old 08-09-2006, 01:19 PM   #42
win32sux
Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 371Reputation: 371Reputation: 371Reputation: 371
Quote:
Originally Posted by blackhole54
wondering if it could be considered an "invalid" packet. But I've never researched what that really means.
basically, a packet of state INVALID is one which isn't associated with any known connection...
 
Old 08-09-2006, 03:09 PM   #43
blackhole54
Senior Member
 
Registered: Mar 2006
Posts: 1,896

Rep: Reputation: 61
Quote:
Originally Posted by heberrdacruz
It runs squid, however.
That might account for the SPT=80 packets, but I don't know why they would be dropped. (Unless they really are malicious packets unrelated to your machine.) Does sqid seem to be operating normally?
 
Old 08-09-2006, 08:08 PM   #44
blackhole54
Senior Member
 
Registered: Mar 2006
Posts: 1,896

Rep: Reputation: 61
Quote:
Originally Posted by heberrdacruz
This entry [169.254.0.0] is a mystery to me. I didnít create it and I canít figure how to remove, or even if I should remove it.
If win32sux's suggestion about zerconf doesn't work I have something else for you to try if you can take eth1 offline momentarily (no more than 2 minutes I would imagine).

This is based on the way the old RedHat distros used to do things, so it is possible things are different with FC. But it might be worth checking out. I want you to look at the way the routing table changes as you take eth1 down and bring it back up. You should log in as root. If you use su, use the dash option so that you actually use root's PATH variable. (To minimize eth1 downtime you might want to check that the commands used below actually can be found using the which command before taking eth1 offline.) So as root do the following:

Code:
route -n
ifdown eth1
route -n
ifup eth1
route -n
I would expect to see all routes involving eth1 to vanish when you take eth1 down. The question is whether that 169.254 line reappears when you bring it back up. If it doesn't reappear we need to look elsewhere. If it does reappear, do the following.

See if you have a file called /sbin/ifup-local, and if so,see whether this script creates this route. (It is probably a small file if it exists.) Also check the file /etc/sysconfig/network-scripts/ifup-post using the search function in you favorite editor or pager to search for 169. Also look at a file called /etc/sysconfig/network-scripts/ifcfg-eth1 to see if there is any reference to this subnet. The ifup-local file is an optional file (it may not exist.). If the last two files don't exist, then FC works differently from the old RH distros.
 
Old 08-10-2006, 10:39 AM   #45
heberrdacruz
LQ Newbie
 
Registered: Jun 2006
Location: Brazil
Distribution: Fedora 11
Posts: 23

Original Poster
Rep: Reputation: 15
Quote:
Originally Posted by win32sux
Code:
NOZEROCONF=yes
inside your /etc/sysconfig/network file...
This worked fine, thank you. The 169.254.0.0 entry has disappeared now. It is odd this business. I had never heard about it. It exists on RH 9, too.

Quote:
Originally Posted by win32sux
yeah, i was referring to this rule in particular:
Code:
$IPTABLES -A FORWARD -i $INTIF -o $EXTIF -s $INTIF_NET \
-m state --state NEW -j ACCEPT
in other words, my opinion was/is that you should leave it like that..
Sure. It is still there.
Thank you blackhole54 for your suggestion. As win32sux's suggestion regarding about zeroconf worked I didnít think it was necessary to try yours.
I run the firewall script and using iptables-save saved the rules on a file and copied to /etc/sysconfig/iptables, so that it became the standard iptables rule. Did I do right?
In the process I noticed there is another file /etc/sysconfig/iptables-config. Removing the comments and blank lines its contents are below.
Code:
IPTABLES_MODULES="ip_tables ip_conntrack ip_conntrack_ftp ip_conntrack_irc iptab le_nat ip_nat_ftp ip_conntrack_netbios_ns"
IPTABLES_MODULES_UNLOAD="yes"
IPTABLES_SAVE_ON_STOP="no"
IPTABLES_SAVE_ON_RESTART="no"
IPTABLES_SAVE_COUNTER="no"
IPTABLES_STATUS_NUMERIC="yes"
IPTABLES_STATUS_VERBOSE="no"
IPTABLES_STATUS_LINENUMBERS="yes"
Should I change anything here?
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
NAT and Port Forwarding aq_mishu Linux - Networking 2 09-16-2005 07:58 AM
SSH port forwarding thru a NAT Firewall whoever Linux - Networking 3 07-29-2005 03:24 AM
Port Forwarding without NAT on an old Kernel linuxpyro Linux - Networking 0 06-02-2004 12:31 PM
iptables + NAT + Port forwarding problem SirGertrude Linux - Networking 9 05-14-2004 04:02 AM
NAT Port forwarding problems! nidputerguy Linux - Networking 4 01-31-2004 10:29 AM


All times are GMT -5. The time now is 07:25 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration