Hi,

I am having an issue with a Website I adminster.

The issue:

We run a site where are sales team can download and view sales quotes using PDF files.

Recently I have implemented IPTables on the server and lock down access.

However the issue is that with IPTables enabled the users cannot access the PDF files although they can access everything else fine.

If I stop the IPtables they can view the PDF's.

I have tried running a TCPdump and used TCPview to see the ports that are being opened to the server and the only port looking to be used is HTTP.

I have also tried opening the firewall up to allow any UDP ports requested by the client this has made no difference, I then opened the firewall to allow all ports from the source computer again no difference.

The only conclusion I can come to is that IPTables is preventing the PDF from being downloaded.

Has anyone come across this before?

Below is the output from the failed attempt to load the PDF while the IPTables is enabled:

ERROR: No HTML files!
HTMLDOC Version 1.8.23 Copyright 1997-2002 Easy Software Products, All Rights Reserved.
This software is governed by the GNU General Public License, Version 2, and
is based in part on the work of the Independent JPEG Group.

Usage:
htmldoc [options] filename1.html [ ... filenameN.html ]

Regards
Dave

Hmm, haven't seen that before. Could you post your iptables script (make sure to remove /mask any public IP addresses).

# Generated by iptables-save v1.2.8 on Mon Jun 28 11:51:50 2004
*nat
:PREROUTING ACCEPT [71:8207]
:POSTROUTING ACCEPT [2:331]
:OUTPUT ACCEPT [2:331]
COMMIT
# Completed on Mon Jun 28 11:51:50 2004
# Generated by iptables-save v1.2.8 on Mon Jun 28 11:51:50 2004
*mangle
:PREROUTING ACCEPT [2326:280904]
:INPUT ACCEPT [2326:280904]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1335:139386]
:POSTROUTING ACCEPT [1335:139386]
COMMIT
# Completed on Mon Jun 28 11:51:50 2004
# Generated by iptables-save v1.2.8 on Mon Jun 28 11:51:50 2004

*filter
:FORWARD ACCEPT [0:0]
:INPUT DROP [0:0]
:OUTPUT ACCEPT [0:0]
# Allow local loopback connections
-A INPUT -s 127.0.0.1 -j ACCEPT
# This is required for connections initiated from this system
-A INPUT -p tcp -m tcp -m state --state ESTABLISHED -j ACCEPT
# Name Lookups
-A INPUT -p udp -m udp --sport 53 -j ACCEPT
# ICMP access from all servers
-A INPUT -p icmp -s xxx.xxx.xxx.xxx/24 -j ACCEPT
# SSH Access
-A INPUT -p tcp -m tcp -s xxx.xxx.xxx.xxx --dport 22 -j ACCEPT
# SSH Access via VPN
-A INPUT -p tcp -m tcp -s xxx.xxx.xxx.xxx/26 --dport 22 -j ACCEPT
# HTTP Access from Foreshore
-A INPUT -p tcp -m tcp -m multiport -s xxx.xxx.xxx.xxx/24 -j ACCEPT --dports 80,443
# ????????? Access
-A INPUT -p tcp -m tcp -s xxx.xxx.xxx.xxx --dport 10000 -j ACCEPT
# ????????? access via VPN
-A INPUT -p tcp -m tcp -s xxx.xxx.xxx.xxx/26 --dport 10000 -j ACCEPT
# MySQL access from ?????????
-A INPUT -p tcp -m tcp -s xxx.xxx.xxx.xxx --dport 3306 -j ACCEPT
# MySQL access from ?????????
-A INPUT -p tcp -m tcp -s xxx.xxx.xxx.xxx --dport 3306 -j ACCEPT
# ????????? Access
-A INPUT -p tcp -m tcp -s xxx.xxx.xxx.xxx --dport 808 -j ACCEPT
# Allow Monitoring access from ?????????
-A INPUT -p tcp -m tcp -s xxx.xxx.xxx.xxx --dport 22 -j ACCEPT
# Allow ????????? to moniotr web pages
-A INPUT -p tcp -m tcp -s xxx.xxx.xxx.xxx --dport 80 -j ACCEPT
# Allow Authentication to RADIUS server
-A INPUT -p udp -m udp -s xxx.xxx.xxx.xxx --sport 1812:1813 -j ACCEPT
# HTTPS Access
-A INPUT -p tcp -m tcp -m multiport -d xxx.xxx.xxx.xxx -j ACCEPT --dports 443,80
# Allow Internal range access to ?????????
-A INPUT -s xxx.xxx.xxx.xxx -j ACCEPT
# Netflow Info from ?????????
-A INPUT -s xxx.xxx.xxx.xxx -j ACCEPT
# Netflow Info from ?????????
-A INPUT -s xxx.xxx.xxx.xxx -j ACCEPT
# Deny access from external customers to ?????????
-A INPUT -p tcp -m tcp -d xxx.xxx.xxx.xxx --dport 80 -j DROP
# HTTP & HTTPS Access from anywhere
-A INPUT -p tcp -m tcp -m multiport -j ACCEPT --dports 80,443
# SNMP rule for ?????????
-A INPUT -p udp -m udp --sport 161 -j ACCEPT
COMMIT

# Completed on Mon Jun 28 11:51:50 2004

Instinctively, I'd say that you might want to try alowing the RELATED state as well as the ESTABLISHED state. But after watching a PDF download with tcpdump, it looks like one continuous tcp stream, so I don't think that will help, but it's still worth a shot.

Second, try putting some logging rules before and after your --dport 80 drop rules (make sure to give each one a distinct log prefix so that you can distinguish them) and also add one at the end of the script to catch any packets that hit the default drop policy. Then try a download and see if you can trace the packet until it's dropped. If that doesn't work, put them around all the drop rules.

Hi,

I have fixed the issue,

Although I had allow loopback connections to the system from 127.0.0.1, the Htmldoc command seemed to be using it's internet address but over the lo inetrface after I allowed this address access the PDF's were downloaded with out a problem.

Interesting. Could you post the rule or even better, post the relevent portion of your ruleset so that we can see it in context.

This is usually the case for most ethernet drivers: If you try to establish a connection from the IP assigned to your NIC, back to that same IP, it won't actually go "on the wire" but rather to the lo0 device (loopback, i.e. pseudo adaptor). You wouldn't see this traffic with a tcpdump of the session because tcpdump looks at "the wire" for the adaptor it's monitoring (e.g. eth0). You would have needed to run two simultaneous tcpdumps (one on eth0, one on lo0) to see the complete behavior.

It seems you were quite resourceful and managed to discover that on your own, because that's what I was going to suggest before I scrolled down and read your last post

Yeah thanks for all your help guys,

I found the issue by running the tcpdump on the lo interface and saw the packets hitting this once the IPTables was stopped so all I did was add a rule:

-A INPUT -s <eth0 IP Address on system> -j ACCEPT

And that sorted the issue, should have thought of that earlier really

I'd recommend against using that rule, as it'll allow incoming packets that are spoofed with your own IP on the external interface. Maybe one of these might be better:

iptables -A INPUT -i lo -s <eth0 IP Address on system> -j ACCEPT
or
iptables -A INPUT -i ! external_interface -s <eth0 IP Address on system> -j ACCEPT

Yes, you defnitely want to specify the device because these packets don't use the physical interface. Write a rule to just allow in all sourced (supposedly) from your external IP would open you up to serious spoofing attacks, as Capt pointed out.