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

Re: [Sheflug] Re: Iptables



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.

> > 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,

Hackers aren't necessarily after 'meaningful conversation' ;) For
example, if you had a private range 1-1 natted to a public range, even
though you've dropped syn, a hacker can still scan your network.
Masquerading protects against this, because it's a source nat and there
would be no entry in the routing table to do the public->private
conversion at will. Hence, you could only really scan the firewall (you
could attempt to take over an existing connection, but that would
involve guess sequence numbers, etc., which is classed as 'hard').

> 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. 

> An excellent way to #really# screw with an ISP would be to take down their
> DHCP server.

Or, worse, providing your own DHCP service :)

> 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.

Cheers,

Alex.

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