On 05 May 2002 14:09:12 +0100 shef-lug-admin@list.sheflug.org.uk wrote: > 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. If you are using passive ftp you know from the start the local source and remote destination port and can allow in traffic on that basis (a stateful firewall does that automatically). With active ftp all you know is that the ftp server is attempting to send data from the ftp-data port to one of your unpriv ports - a malicious ftp server could wait for connections and then launch a probe against your unpriv ports from it's ftp-data port - looking for X11, for instance. A stateful firewall will not help, as it was you who initiated the connection. This can be blocked, but it's more hassle, so I choose to block all incoming SYN except on ports I explicitly allow (public http etc). > > 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. Without that bit it's kinda hard to have any meaningful conversation with any of the services, unless you can hijack an existing inbound connection (which you can't because there can be no inbound connections to hijack) No SYN == I'm not going to talk to you Of course this won't work against portscanners like nmap that don't set SYN, but a) I need to talk to the malicious host before the stateful firewall will let in any data anyway b) I don't have services bound to my external interface. Blocking all data bound for local ports < 1024 is good too. > > 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 An excellent way to #really# screw with an ISP would be to take down their DHCP server. This need not be done with the DCHP protocol, any weakness in the server's IP stack or any other services running would do. Making the DHCP server unroutable from outside the ISP and their customers prevents access from those who don't need it. > > 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). Should your ISP use RFC1918 address space for their mail/DHCP servers etc, then it becomes harder for the customer to block RFC1918 at their firewall. The ISP doesn't block this, so it's open to the 'net at large. Of course, maybe the customer deserves this for choosing the same RFC1918 subnet as their ISP uses... --Andrew -- sparc sun4c stuff: http://www.lostgeneration.freeserve.co.uk/sparc PGP key for list [at] lostgeneration.freeserve.co.uk: http://www.lostgeneration.freeserve.co.uk/list.freeserve.co.uk.asc
Attachment:
pgp00015.pgp
Description: PGP signature