> > There is a notion that source ports above 1023 are 'safer' than those
> > up to there. This is due to the fact that in UNIX only root may use
> > those ports.
>
> You got it just the wrong way around; ports _below_ 1024 are root-only.
> The rest are free-for-all. Or did I misunderstand you?
>
No, I mucked that up. You are right, only root may use port 1-1023. However,
that seems to be the notion behind trusting source ports above 1023 more
than those that are accessible only to root. The only place I can see that
making any sense is in a LAN of UNIX machines with a single root password,
but maybe I'm not imaginative enough. Anyhow, thanks for correcting what I
said, that was a slip-up.
> > Now on to your ipchains question. Actually, '-y' means 'SYN bit set'
> > and '! -y' means 'SYN bit cleared', but that is wrong, otherwise the
> > TCP three-way handshake would never complete.
>
> That's the whole point - to only match packets that are trying to
> initiate a connection and then either accept or reject/deny them based
> on IP-address/netmask or traffic direction. Practically, this gives you
> more control over your open ports (plus, gives you an easy tool to get
> rid of all those annoying doubleclick.net and similar webads, saving a
> little bit of your bandwidth in the process :P).
>
I don't see where control of the SYN bit helps in getting rid of
doubleclick, but I will try to be more clear in what I said, since you seem
not to have understood completely -- I was fearing that would happen as I'd
been so brief.
When a TCP connection is set up, the sender sends a TCP segment with the SYN
bit set, the ACK and FIN bits cleared and a more or less random sequence
number to the recipient. The recipient responds with a TCP segment that has
the SYN and the ACK bit set (I s'pose the FIN bit shouldn't be set), an
acknowledgement number of one more than the sender's sequence number and a
more or less random sequence number of it's own. The sender completes the
three-way handshake with a 'standard' TCP segment, meaning one that you'll
see many like in this connection until it is torn down, with the ACK bit set
and sequence and acknowledgement numbers incremented as they should be.
Now, the second segment in this sequence, i.e. the first one travelling from
connection recipient to original sender *has the SYN bit set*. So, if '-y'
only meant 'SYN bit set' and '! -y' meant 'SYN bit not set', then you'd
effectively block this second segment of the three-way handshake with an
ipchains rule like:
'ipchains -A input/forward/output -s outside -d inside -p tcp !-y -j DENY'
That's what I was trying to say.
> > You are not safe if you've got a firewall. You're safer than you'd be
> > without one, though. How much depends on its configuration.
>
> Also, depends on the firewall itself. There could be buffer overflows or
> some other nasty bugs in the code that could lead to root compromise.
> There were some security issues with linux IPchains, for instance that,
> in some cases, allowed an attacker to entirely bypass the firewall. Read
> more at:
>
> http://www.securityfocus.com/archive/1/19810
>
Oh, ipchains is far from flawless, I'm sure. I wasn't aware of that specific
problem, but I've always set my Linux 2.2 kernel machines to always
defragment packets. The boxes may also be susceptible to resource
consumption attacks from lots of fragments, I don't know. IP Masquerading
also had an issue that led to it accepting UDP connections from arbitrary
sources and rewrote its NAT table when expecting a 'response'. iptables also
recently suffered a bug in the FTP connection tracking module, similar,
IIRC, to what happened to Check Point and the PIX last year.
Still, I'd rather sit behind an ipchains or iptables box, which (BTW) I
still prefer to call packet filters if that's all there is on the box, than
have a direct connection to the Internet.
Cheers,
Tobias
_______________________________________________
Firewalls mailing list
[EMAIL PROTECTED]
http://lists.gnac.net/mailman/listinfo/firewalls
