[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sheflug] Re: Iptables



On Sun, 2002-05-05 at 13:52, shef-lug-admin [at] list.sheflug.org.uk wrote:
> You need to block all incoming connections unless you're specifically
> running internet-accessible services. Active ftp deserves to die a quiet
> and long overdue death, all ftp clients should be configured to use
> passive ftp.

To be honest, if you're using a stateful firewall, it makes no
difference. The real problem with ftp is the way it encodes network
information into the data layer; nothing to do with it's use of sockets
perse.

> Any services that need to open ports on the client are a big
> security hole, and their usefulness should be reviewed.

That's quite a general statement, given that you're talking about
allowing certain network packets to pass or not on the basis of one
single bit. 

> It means they don't have to use a public IP address for their server that
> they can sell to a paying customer... I would say using an RFC1918 address
> would keep their DHCP servers 'destination unreachable' and hence private
> from the rest of the internet, but see below.

Given DHCP works on network broadcast, it's highly likely that it would
be unroutable even if they had public ips :P

> That's disgraceful. I tried it myself (after changing my firewall to let
> the packets out) and got the same result. It's not the outgoing packets
> that are the problem, it's the fact that theoretically someone between the
> ISP and Telehouse could spoof as an RFC1918 address and maybe pretend they
> were inside your private network if you had a poor (nonexistent) firewall
> that lets in RFC1918 from the external interface. This should be blocked
> by the ISP, as well as the customer.

Well, it's the customer's problem really. RFC1918 does not say that the
private ranges must be dropped - in fact, IIRC, it only says they should
be dropped at interlinks. Home networks, etc., didn't exist when this
was written. As usual, section 6 is probably going to be very
enlightening (as with most rfcs).

Cheers,

Alex.

Attachment: signature.asc
Description: This is a digitally signed message part