On 05 May 2002 15:59:37 +0100 shef-lug-admin@list.sheflug.org.uk wrote: > On Sun, 2002-05-05 at 15:27, shef-lug-admin [at] list.sheflug.org.uk wrote: > > 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 > > No, you actually know what port would be contacted and whether or not > the client had requested it. If there was no means of the client and > server agreeing the connection, the server wouldn't be able to connect > to the client - the ftp receiver can't listen on all ports > simultaneously. The ftp client knows what port to expect ftp-data on, but the firewall doesn't. How do you get the ftp client to tell the firewall what port to open for ftp-data? You can't, so you need all unprivileged ports open. Bad. > > > 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, > > No SYN == I'm not going to talk to you > > Not quite. No syn == this isn't a packet intended to establish a > connection. What operating systems do in response to packets without a > syn bit set and no established connection is one of the things nmap uses > for fingerprinting. But close enough. You can block packets with the combinations of fin, urg & push flags nmap uses with other firewall rules. > > An excellent way to #really# screw with an ISP would be to take down > > their DHCP server. > > Or, worse, providing your own DHCP service :) That would be the next step :) > > 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. > > You shouldn't be using the same network numbers in any case, though. > Private/public ranges isn't what is at issue here: it's routing, and > packet leakage. Private/public is an arbitrary distinction used to make > people's lives easier; there's technically no real difference between > the two. Granted. --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:
pgp00018.pgp
Description: PGP signature