On Wednesday 2005-November-09 05:31, Dave Strydom wrote:
> -A PREROUTING -d 209.212.xxx.xxx -p tcp -m tcp --dport 20 -j DNAT
> --to-destination 192.168.0.220:20
> -A PREROUTING -d 209.212.xxx.xxx -p tcp -m tcp --dport 21 -j DNAT
> --to-destination 192.168.0.220:21
If you're running an FTP server behind NAT, you would only DNAT 21.
Ftp-data (tcp/20) is used for outgoing connections to the client. I
doubt this is your problem, though. Nothing will match that rule unless
you're connecting an FTP client on the firewall to a remote site.
> -A POSTROUTING -s 192.168.0.0/255.255.255.0 -j MASQUERADE
In general if you have a static IP (as in "not changing ever", not "you
pay the ISP more and get custom rDNS") the SNAT target is better.
> *filter
>
> :INPUT ACCEPT [2:246]
> :FORWARD ACCEPT [6:1109]
ACCEPT policies can be fine, but you generally should have rules to
REJECT or DROP the traffic you don't want.
> :OUTPUT ACCEPT [44:16200]
> :bad_tcp_packets - [0:0]
> :icmp_packets - [0:0]
> :rbl_packets - [0:0]
> :tcp_allowed - [0:0]
> :tcp_filtered_packets - [0:0]
> :tcp_packets - [0:0]
> :udp_packets - [0:0]
>
> -A INPUT -s 127.0.0.1 -j ACCEPT
First rule? Maybe "-i lo", but not "-s 127.0.0.1". An attacker could
route packets to you which claim to have a source address of 127.0.0.1,
and you're accepting them.
It's a minor weakness, but perhaps it can help you understand the
difference between specifying an input interface ("lo" is always
secure, at least insofar as you trust your own users) or a source IP
address. Packet headers can be spoofed! But outsiders can only come in
on your external interface.
> -A INPUT -s 192.168.0.0/255.255.255.0 -j ACCEPT
Same issue here. Packets claiming to be from your LAN are accepted.
> -A INPUT -d 192.168.0.0/255.255.255.0 -m state --state
> NEW,RELATED,ESTABLISHED -j ACCEPT
Huh? This looks like it might belong in FORWARD. But "-d"? What did you
think this rule would do?
> -A INPUT -d 209.212.xxx.xxx -m state --state RELATED,ESTABLISHED -j
> ACCEPT
I will assume 209.212.xxx.xxx is this machine's external IP. Please be
explicit when you are munging information.
This rule means that your firewall machine gets replies to the
connections it initiates.
> -A INPUT -p tcp -j tcp_filtered_packets
> -A INPUT -p tcp -j rbl_packets
> -A INPUT -p tcp -j tcp_packets
> -A INPUT -p udp -j udp_packets
> -A INPUT -p icmp -j icmp_packets
> -A INPUT -p tcp -m tcp --dport 20 -j ACCEPT
Why? See above about ftp-data.
> -A INPUT -p tcp -m tcp --dport 21 -j ACCEPT
You have DNAT'ed port 21 above. This rule won't be matched.
> -A INPUT -p tcp -m tcp --dport 25 -j ACCEPT
> -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
> -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
This machine is running public SMTP, HTTP and HTTPS servers.
> -A INPUT -p tcp -j DROP
This overrides the default ACCEPT policy but only for TCP.
> -A FORWARD -p tcp -m tcp --dport 20 -j ACCEPT
> -A FORWARD -p tcp -m tcp --dport 21 -j ACCEPT
These should ensure the NAT'ed FTP server is accessible from outside.
> -A FORWARD -s 192.168.0.220 -p tcp -j ACCEPT
And any TCP connections from that machine are allowed.
> -A OUTPUT -s 192.168.0.0/255.255.255.0 -m state --state
> NEW,RELATED,ESTABLISHED -j ACCEPT
> -A OUTPUT -s 209.212.xxx.xxx -m state --state NEW,RELATED,ESTABLISHED
> -j ACCEPT
Explained yesterday why this is pointless.
> -A udp_packets -p udp -m udp --dport 53 -j ACCEPT
> -A udp_packets -s 196.36.10.xxx -p udp -j ACCEPT
> -A udp_packets -p udp -j ACCEPT
This is jumped to from INPUT, and all it does is ACCEPT, which is the
same as your default policy.
> COMMIT
The other chains you defined are not used!
> And here is the output of my tethereal:
snip
> What I do notice is this:
>
> FTP [TCP Out-Of-Order] Response: 150 Opening BINARY mode data
> connection for LANDING_16.jpg
> and
> FTP [TCP Previous segment lost] Response:
Yes, I would guess that is the problem, but I don't know what would
cause it. Again from yesterday, I doubt it's a netfilter issue.
--
mail to this address is discarded unless "/dev/rob0"
or "not-spam" is in Subject: header
