Antony
Thanks for the reply.
I added port 113 to the "allow" list and when I tried to reconnect to the
Squid box, those 113 port packets are still being dropped. Any idea why
the port 80 packets are being dropped as well? I think my rules are setup
correctly, so I'm not sure why they're not being allowed. I'm attaching
my rules if someone would like to take a look and see what's happening.
Thanks.
---------------------
Jim Matthews
ISS Systems Administrator
Duke University - Perkins Library
Box 90196
Durham, NC 27708
Email: jim.matthews@xxxxxxxx
Voice: 919-660-5963
Fax: 919-684-6990
Antony Stone <Antony@xxxxxxxxxxxxxxxxxxxx>
Sent by: netfilter-admin@xxxxxxxxxxxxxxxxxxx
07/19/2004 03:47 PM
Please respond to
netfilter@xxxxxxxxxxxxxxxxxxx
To
netfilter@xxxxxxxxxxxxxxxxxxx
cc
Subject
Re: Squid Accelerator configuration
On Monday 19 July 2004 8:25 pm, Jim Matthews wrote:
> Reposting with some more information. I've set iptables to drop-n-log
bad
> packets and here's what I'm getting when I try and connect to my squid
> server.
> I'm not sure why these packets are being dropped as my rules are setup
to
> allow and forward connections to port 80. I'm not sure why port 113 is
in
> the mix.
TCP port 113 is the ident service - servers connect back to port 113 at
the
client to get information about the client attempting to connect.
Some ident clients (running on the server being accessed) don't really
care
whether they get an answer or not; others require *some* sort of answer,
even
if it's essentially useless (however, a firewall which simply drops
packets
with no response whatever will upset such clients and possibly deny access
to
the service being requested).
> 192.168.1.1 - squidbox
> 192.168.1.5 - backend WWW server
> 192.168.1.205 - testing box/client
>
> Jul 19 15:18:19 squidbox kernel: drop-n-log:IN= OUT=eth0 SRC=192.168.1.1
> DST=192.168.1.205 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP
> SPT=43600 DPT=113 WINDOW=5840 RES=0x00 SYN URGP=0
Squid machine sends ident request to client.
> Jul 19 15:18:19 squidbox kernel: drop-n-log:IN= OUT=eth0 SRC=192.168.1.1
> DST=192.168.1.5 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=54027 DF PROTO=TCP
> SPT=43601 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0
Squid machine sends http request to web server.
> Jul 19 15:18:19 squidbox kernel: drop-n-log:IN= OUT=eth0 SRC=192.168.1.1
> DST=192.168.1.5 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=54028 DF PROTO=TCP
> SPT=43595 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0
Squid server sends another http request to the web server - same time
stamp
suggest this is a simultaneous request, rather than a repeat of the
previous
one.
> Jul 19 15:18:22 squidbox kernel: drop-n-log:IN= OUT=eth0 SRC=192.168.1.1
> DST=192.168.1.205 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP
> SPT=43600 DPT=113 WINDOW=5840 RES=0x00 SYN URGP=0
Squid server sends another ident request to the client machine. The fact
that the time stamp is 3 seconds after the last request, and the source
ports
are the same, indicate that this is a repeat of the last packet (which
must
therefore not have been replied to)
> Jul 19 15:18:22 squidbox kernel: drop-n-log:IN= OUT=eth0 SRC=192.168.1.1
> DST=192.168.1.5 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=54027 DF PROTO=TCP
> SPT=43601 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0
Squid server sends a repeat http request to the web server; again the 3
second
delay and the duplicated source port identifies this as a repeat packet
rather than a new one.
> Jul 19 15:18:24 squidbox kernel: drop-n-log:IN= OUT=eth0 SRC=192.168.1.1
> DST=192.168.1.205 LEN=1423 TOS=0x00 PREC=0x00 TTL=64 ID=33313 DF
PROTO=TCP
> SPT=80 DPT=42536 WINDOW=6432 RES=0x00 ACK PSH FIN URGP=0
Squid server decides to close the connection to the client which made the
initial request on port 80.
> Jul 19 15:18:28 squidbox kernel: drop-n-log:IN= OUT=eth0 SRC=192.168.1.1
> DST=192.168.1.205 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP
> SPT=43600 DPT=113 WINDOW=5840 RES=0x00 SYN URGP=0
Squid server retries once more to get an answer on ident from the client.
> Jul 19 15:18:28 squidbox kernel: drop-n-log:IN= OUT=eth0 SRC=192.168.1.1
> DST=192.168.1.5 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=54027 DF PROTO=TCP
> SPT=43601 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0
Squid server still tries to connect to the web server on port 80.
> Jul 19 15:18:41 squidbox kernel: drop-n-log:IN= OUT=eth0 SRC=192.168.1.1
> DST=192.168.1.5 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=54027 DF PROTO=TCP
> SPT=43601 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0
Repeat of the last packet above.
> Jul 19 15:18:45 squidbox kernel: drop-n-log:IN= OUT=eth0 SRC=192.168.1.1
> DST=192.168.1.205 LEN=1423 TOS=0x00 PREC=0x00 TTL=64 ID=33332 DF
PROTO=TCP
> SPT=80 DPT=42539 WINDOW=6432 RES=0x00 ACK PSH URGP=0
Finally a reply to the client from port 80.
> Jul 19 15:18:45 squidbox kernel: drop-n-log:IN= OUT=eth0 SRC=192.168.1.1
> DST=192.168.1.205 LEN=1423 TOS=0x00 PREC=0x00 TTL=64 ID=33332 DF
PROTO=TCP
> SPT=80 DPT=42539 WINDOW=6432 RES=0x00 ACK PSH FIN URGP=0
Squid server closes the connection to the client (presumably after having
said
"no luck").
Regards,
Antony.
--
"Black holes are where God divided by zero."
- Steven Wright
Please reply to the
list;
please don't CC
me.
# /etc/sysconfig/iptables
#
#
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
# LOGGING / DEBUGGING
-N accept-n-log
-A accept-n-log -j LOG --log-level 4 --log-prefix "accept-n-log:"
-A accept-n-log -j ACCEPT
-N drop-n-log
-A drop-n-log -j LOG --log-level 4 --log-prefix "drop-n-log:"
-A drop-n-log -j DROP
# internal interfaces
-A INPUT -i lo -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
# icmp
-A INPUT -p icmp -j ACCEPT
-A OUTPUT -p icmp -j ACCEPT
# ntp client
-A INPUT -s 192.1.2.1 -p udp -m udp --sport 123 -j ACCEPT
-A OUTPUT -d 192.1.2.1 -p udp -m udp --dport 123 -j ACCEPT
-A INPUT -s 192.1.2.2 -p udp -m udp --sport 123 -j ACCEPT
-A OUTPUT -d 192.1.2.2 -p udp -m udp --dport 123 -j ACCEPT
# dns client
-A OUTPUT -d 192.1.1.1 -p udp -m udp --dport 53 -m state --state NEW,ESTABLISH
ED -j ACCEPT
-A INPUT -s 192.1.1.1 -p udp -m udp --sport 53 -m state --state ESTABLISHED -j
ACCEPT
# ssh server
-A INPUT -s 192.168.0.0/16 -p tcp -m tcp --dport 22 -m state --state NEW,ESTABLISH
ED -j ACCEPT
-A OUTPUT -d 192.168.0.0/16 -p tcp -m tcp --sport 22 -m state --state ESTABLISHED
-j ACCEPT
# Squid
# These rules are to allow testing from the internal network - the first two rules
# are for the Squid port
# And for port 113/identd if needed
-A INPUT -s 192.168.1.0/24 -p tcp -m tcp --sport 1024: --dport squid -m state --
state NEW,ESTABLISHED -j ACCEPT
-A OUTPUT -s 192.168.1.0/24 -p tcp -m tcp --sport squid -m state --state ESTABLI
SHED -j ACCEPT
-A INPUT -s 192.168.1.0/24 -p tcp -m tcp --sport 1024: --dport 113 -m state --st
ate NEW,ESTABLISHED -j ACCEPT
-A OUTPUT -s 192.168.1.0/24 -p tcp -m tcp --sport 113 -m state --state ESTABLISH
ED -j ACCEPT
# These two rules are for the http port
-A INPUT -s 192.168.1.0/24 -p tcp -m tcp --sport 1024: --dport http -m state --s
tate NEW,ESTABLISHED -j ACCEPT
-A OUTPUT -s 192.168.1.0/24 -p tcp -m tcp --sport http -m state --state ESTABLIS
HED -j ACCEPT
# These two rules should cover the forwarding of connections for the backend WWW server
-A FORWARD -s 0/0 -d 192.168.1.5 -p TCP --sport 1024:65535 --dport 80 -j ACCEPT
-A FORWARD -d 0/0 -s 192.168.1.5 -p TCP -m state --state ESTABLISHED -j ACCEPT
# debug
-A OUTPUT -p tcp -j drop-n-log
# always necessary for iptables-restore
COMMIT
