On 5/6/06, Matthew R. Dempsky <[EMAIL PROTECTED]> wrote:
I have looked into authpf(8) before and understand how it works, but the
following excerpt from the BUGS section of the man page puzzles me
somewhat:
The authenticating ssh(1) connection may be secured, but if the
network is not secured the user may expose insecure protocols to
attackers on the same network, or enable other attackers on the
network to pretend to be the user by spoofing their IP address.
If IP spoofing is still a concern with authpf(8), what makes it an
improvement over IP filtering? I can believe it *is* an improvement,
I am just curious *how* in light of the above warning.
Authpf is a general mechanism for altering packet filter rules based
on a user login. There are obviously some more/less trustworthy
protocols. In the case of tcp sessions, you might have a better chance
of knowing who's on the other end. In some cases the only safe thing
to allow would be various SSL-ized protocols.
For example, a spoofer would have to fake the IP address of a current
legitimate user, and I expect this makes certain attacks more difficult,
but they could still easily send UDP datagrams (e.g. to poison a DNS
cache), right?
Well, one could certainly cook up properly forged UDP, but when
hijacking TCP there is a very real probability that the SSH session
will be torn down either because the spoofer's kernel isn't expecting
that session, or because the spoofer will be unable to generate the
proper ssh keepalive messages.
As Nick said you can't really trust the IP or the MAC. If you need to
be able to trust them, look at some kind of VPN.
A quick googling and mailing list search gave plenty of hits for
configuring authpf, but I did not find anything specifically related to
the above.
In sshd_config, investigate the ClientAlive{Interval,CountMax}
options. At the cost of a bit of network traffic and a bit of CPU, you
can make it difficult to hijack someone's address for any length of
time.
CK
--
GDB has a 'break' feature; why doesn't it have 'fix' too?
