Tightening SSH access

Hi,

Is there a way to configure SSH + iptables such that it only accepts
logins coming from our machines? Ideally, the access should require
password (i.e., a Unix login password) + public-key verification (only
our keys would be accepted by SSH) + verification (via MAC) that it
comes from our machines (our IP is not static, so using the source
IP to validate would be risky). Is it possible?

In the iptables tutorial I have, they mention that the MAC-based
match support is not quite solid. I'm not sure if that still holds.

I'm thinking of a rule like:

iptables -P INPUT DROP
.... (other rules)
iptables -A INPUT \
-p tcp --syn --dport 22 -m mac --mac-source <MAC> -j ACCEPT


Also from the sshd_config man pages, it looks to me like authentication
can be made based on public-key OR password-based, but not both; I'd
like SSH to verify that the connection comes from the owner of the
authorized key-pair but ALSO require the client to type in a login
name and password to allow access. Is it possible?

Thanks,

Carlos
--

On 2005-07-08, Carlos Moreno <moreno_at_mochima_dot_com@xx.xxx> wrote:
>
> Is there a way to configure SSH + iptables such that it only accepts
> logins coming from our machines? Ideally, the access should require
> password (i.e., a Unix login password) + public-key verification (only
> our keys would be accepted by SSH) + verification (via MAC) that it
> comes from our machines (our IP is not static, so using the source
> IP to validate would be risky). Is it possible?

I can't speak to all of your concerns, but MACs are spoofable, and in
theory anyone on the local network should be able to sniff your MAC.
That being said,

> In the iptables tutorial I have, they mention that the MAC-based
> match support is not quite solid. I'm not sure if that still holds.

I think MAC-based matching is reasonably good in recent kernels. I've
been using it for some of my boxes, and it seems to work fine.

--keith

--
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://wombat.san-francisco.ca.us/cgi-bin/fom
see X- headers for PGP signature information

Carlos Moreno wrote:
> In the iptables tutorial I have, they mention that the MAC-based
> match support is not quite solid. I'm not sure if that still holds.
>
> I'm thinking of a rule like:
>
> iptables -P INPUT DROP
> .... (other rules)
> iptables -A INPUT \
> -p tcp --syn --dport 22 -m mac --mac-source <MAC> -j ACCEPT

Yes, you can leave open the port 22 (ssh) rejecting all incoming traffic
except those MAC addresses that you know.

> Also from the sshd_config man pages, it looks to me like authentication
> can be made based on public-key OR password-based, but not both; I'd
> like SSH to verify that the connection comes from the owner of the
> authorized key-pair but ALSO require the client to type in a login
> name and password to allow access. Is it possible?

Use ssh/iptables, and you can do whatever you want, but be warned...
even MAC addresses are not 100% safe. Use the keys and use a non-blank
passphrase if you want user interaction.

Sensei wrote:

> Use ssh/iptables, and you can do whatever you want, but be warned...
> even MAC addresses are not 100% safe.

Thanks, Sensei and Keith for your messages.

Yes, I actually was aware that MACs are spoofable; but it still can
work for us (I think), as I suspect that the attacks I'm seeing in
the logs come from completely unrelated/remote sites.

The attacks I'm referring to are several hundred attempts to log in
(several hundreds each day -- today, for instance, I see 967 failed
attempts to log in through SSH -- most of them with user accounts
that do not exist on our servers; that makes me think that it is
a dictionary-like attack, as opposed to someone that may have
sniffed our network, in which case they might be able to do a more
precise attack)

Thanks!

Carlos
--

On Fri, 08 Jul 2005 17:28:30 -0400, Carlos Moreno
<moreno_at_mochima_dot_com@xx.xxx> wrote:
>
>
> Also from the sshd_config man pages, it looks to me like authentication
> can be made based on public-key OR password-based, but not both; I'd
> like SSH to verify that the connection comes from the owner of the
> authorized key-pair but ALSO require the client to type in a login
> name and password to allow access. Is it possible?
>
Why not use public key with a passphrase?


--
Tonight you will pay the wages of sin; Don't forget to leave a tip.

Bill Marcum wrote:
> On Fri, 08 Jul 2005 17:28:30 -0400, Carlos Moreno
> <moreno_at_mochima_dot_com@xx.xxx> wrote:
>
>>
>>Also from the sshd_config man pages, it looks to me like authentication
>>can be made based on public-key OR password-based, but not both; I'd
>>like SSH to verify that the connection comes from the owner of the
>>authorized key-pair but ALSO require the client to type in a login
>>name and password to allow access. Is it possible?
>>
>
> Why not use public key with a passphrase?
>
>

Exactly. See http://aplawrence.com/Security/sshpassphrases.html for a
short guide to setting it up.

--
Tony Lawrence
Unix/Linux/Mac OS X resources: http://aplawrence.com

I just tried configuring one of the servers to disallow root login.

One problem/weakness I noticed is that even though the login is
ultimately refused, typing the correct password and typing an
incorrect password produce different behaviours.

This is indeed a weakness, I believe, as it discloses the fact that
you got the correct password (I know that guessing the root password
should be extremely unlikely, but these are the odds that they're
playing when brute-forcely attempting to login as root, right?)

IMHO, if the server must wait until the time to refuse login, then
it should refuse it in the exact same way. A better solution, of
course, would be that as soon as root is entered as user name, it
should immediately close the connection (without even saying
goodbye). This could be done for the special case of root (but
perhaps not for the other users, as that would allow attackers to
know when they got a correct username).

Comments? (time to write to the OpenSSH guys with this feature
request? Or has this been addressed in the past?)

Thanks! And thanks to all that have replied so far!

Carlos
--

Carlos Moreno wrote:
>
> I just tried configuring one of the servers to disallow root login.
>
> One problem/weakness I noticed is that even though the login is
> ultimately refused, typing the correct password and typing an
> incorrect password produce different behaviours.
>

What version of ssh are you running? I have openssh v4.0p1 running on a
Fedora core 4 box and I get the same behaviour whether I use the correct
password or an incorrect password for root:

"Permission denied, please try again."

Regards,
Steve Webster

On Sat, 09 Jul 2005 11:50:19 -0400, Carlos Moreno <moreno_at_mochima_dot_com@xx.xxx> wrote:
>
> Comments? (time to write to the OpenSSH guys with this feature
> request? Or has this been addressed in the past?)

1. Disable root ssh logins, login as user then 'su -' to root account,
this creates two hurdles for an attacker, likely to move on as soon
as they discover no root login permitted.

2. Restrict (if possible) ssh logins to known IP addresses.

Attackers look for easy targets, I don't see any ssh login attempts
logged from remotes as I use the second option. Casual ssh probes
are dropped at the firewall.

--Grant.

Stephen Webster wrote:
> Carlos Moreno wrote:
>
>>
>> I just tried configuring one of the servers to disallow root login.
>>
>> One problem/weakness I noticed is that even though the login is
>> ultimately refused, typing the correct password and typing an
>> incorrect password produce different behaviours.
>>
>
> What version of ssh are you running? I have openssh v4.0p1 running on a
> Fedora core 4 box and I get the same behaviour whether I use the correct
> password or an incorrect password for root:
>
> "Permission denied, please try again."

D'oh!! I think it's 3.5 -- it's the one that comes with RH9, with the
latest updates applied, but still an old version.

Glad to hear that this detail has been fixed!

Thanks,

Carlos
--