Securing root?

Captain Dondo wrote:
> I've been subjected to a fairly crude dictionary attack:
>
> Apr 8 05:58:38 tooth sshd(pam_unix)[20285]: authentication failure;
> logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=202.140.169.246 user=root
> Apr 8 05:58:44 tooth sshd(pam_unix)[20289]: authentication failure;
> logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=202.140.169.246 user=root
> Apr 8 05:58:48 tooth sshd(pam_unix)[20293]: authentication failure;
> logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=202.140.169.246 user=root
> Apr 8 05:58:52 tooth sshd(pam_unix)[20296]: authentication failure;
> logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=202.140.169.246 user=root
>
> But that got me thinking:
>
> Is it possible to set up pam/ssh to require a secondary password when an
> attempt is made to log in as root from an unknown location? I don't want
> to carry around my 'secret' for ssh; I want to be asked for a second,
> different password if pam/ssh sees a login request coming in from an
> unvalidated IP... That way, even if the primary password is cracked,
> there is a secondary password that would have be cracked as well.
> Hopefully, by then, other warnings will kick in.
>

Wouldn't it just be better to change sshd_config to disallow root logins
altogether? Then, even if they guess the correct password they still can't get in.

Hope this helps,

Alunduil

I've been subjected to a fairly crude dictionary attack:

Apr 8 05:58:38 tooth sshd(pam_unix)[20285]: authentication failure;
logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=202.140.169.246 user=root
Apr 8 05:58:44 tooth sshd(pam_unix)[20289]: authentication failure;
logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=202.140.169.246 user=root
Apr 8 05:58:48 tooth sshd(pam_unix)[20293]: authentication failure;
logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=202.140.169.246 user=root
Apr 8 05:58:52 tooth sshd(pam_unix)[20296]: authentication failure;
logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=202.140.169.246 user=root

But that got me thinking:

Is it possible to set up pam/ssh to require a secondary password when an
attempt is made to log in as root from an unknown location? I don't want
to carry around my 'secret' for ssh; I want to be asked for a second,
different password if pam/ssh sees a login request coming in from an
unvalidated IP... That way, even if the primary password is cracked,
there is a secondary password that would have be cracked as well.
Hopefully, by then, other warnings will kick in.

--

use munged address above to email me
SpamTrap (E-Mail Removed)

In comp.os.linux.networking Captain Dondo <(E-Mail Removed)>:
> I've been subjected to a fairly crude dictionary attack:

> Apr 8 05:58:38 tooth sshd(pam_unix)[20285]: authentication failure;
> logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=202.140.169.246 user=root
[..]

> But that got me thinking:

> Is it possible to set up pam/ssh to require a secondary password when an
> attempt is made to log in as root from an unknown location? I don't want

What about the most obvious? Disabling remote root logins
completely? ('man sshd_config')

--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo (E-Mail Removed) | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 200: The monitor needs another box of pixels.

"Michael Heiming" <michael+(E-Mail Removed)> quoted and wrote in
message
news:n4iii2-(E-Mail Removed)

>> Is it possible to set up pam/ssh to require a secondary password
>> when an attempt is made to log in as root from an unknown location?
>> I don't want
>
> What about the most obvious? Disabling remote root logins
> completely? ('man sshd_config')

And the second most-obvious - utilizing tcpwrappers support (man
hosts.allow) to limit the connections to "known locations"?

"ynotssor" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "Michael Heiming" <michael+(E-Mail Removed)> quoted and wrote in
> message
> news:n4iii2-(E-Mail Removed)
>
>>> Is it possible to set up pam/ssh to require a secondary password
>>> when an attempt is made to log in as root from an unknown location?
>>> I don't want
>>
>> What about the most obvious? Disabling remote root logins
>> completely? ('man sshd_config')
>
> And the second most-obvious - utilizing tcpwrappers support (man
> hosts.allow) to limit the connections to "known locations"?
>

Perhaps a simpler solution is to configure your sshd better:

1. Dis-allow any plain text passwords at all.
sshd_config:
PasswordAuthentication no

2. Use a digital key exchange for authentication.
( ssh-keygen .... with -t dsa )

3. Dis-allow any empty passwords.
sshd_config:
PermitEmptyPasswords no

Once you have this in place, who cares how many
times some fool tries a dictionary crack. It will never, ever
succeed.

If you want to really get hard-nosed... Then you might
nail down the permitted inbound IP address that is
ever permitted to even try accessing TCP port 22.
iptables:

#
# Let only $SSH_GUY be permitted to even try accessing sshd.
#
/sbin/iptables -A INPUT -i $EXTINT -p TCP -s $SSH_GUY\
--dport 22 -j ACCEPT
/sbin/iptables -t nat -A PREROUTING -i $EXTINT -p tcp -s $SSH_GUY\
--dport 22 -j ACCEPT

/sbin/iptables -A OUTPUT -o $EXTINT -p TCP -d $SSH_GUY\
--sport 22 -j ACCEPT
/sbin/iptables -t nat -A OUTPUT -o $EXTINT -p TCP -d $SSH_GUY\
--sport 22 -j ACCEPT
/sbin/iptables -t nat -A POSTROUTING -o $EXTINT -p TCP -d $SSH_GUY\
--sport 22 -j ACCEPT

#
# Default rule if not accepted above. ( You should not need this, as your
# default POLICY should be DROP, or REJECT)
#
/sbin/iptables -A INPUT -i $EXTINT -p TCP --dport 22 -j DROP
/sbin/iptables -t nat -A PREROUTING -i $EXTINT -p tcp --dport 22 -j DROP



Enjoy,
Postmaster

Michael Heiming wrote:

> In comp.os.linux.networking Captain Dondo <(E-Mail Removed)>:
>> I've been subjected to a fairly crude dictionary attack:
>
>> Apr 8 05:58:38 tooth sshd(pam_unix)[20285]: authentication failure;
>> logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=202.140.169.246
>> user=root
> [..]
>
>> But that got me thinking:
>
>> Is it possible to set up pam/ssh to require a secondary password when an
>> attempt is made to log in as root from an unknown location? I don't want
>
> What about the most obvious? Disabling remote root logins
> completely? ('man sshd_config')
>

.... and that would achieve a similar effect, since you'd now need to supply
two passwords to become root.

I can't really see any advantage to requiring two passwords - better just to
make the password longer and stronger (not based on dictionary words, mixed
case, etc etc). Remember, that since this is an attack over the network,
it's going to be thousands of time slower than cracking (say) /etc/shadow
locally; and it will take the attacker long enough just to try every word
in a modest-sized dictionary.

Of course, you could also block hosts after a failed number of login
attempts. I can't remember if PAM can do this.

Cheers,

Pete

--
"Linux Network Security", the ultimate book on protecting your network from
intruders. http://www.charlesriver.com/Books
BookDetail.aspx?productID=99214

In comp.os.linux.networking peter smith <(E-Mail Removed)>:
> Michael Heiming wrote:

>> In comp.os.linux.networking Captain Dondo <(E-Mail Removed)>:
>>> I've been subjected to a fairly crude dictionary attack:
>>
>>> Apr 8 05:58:38 tooth sshd(pam_unix)[20285]: authentication failure;
>>> logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=202.140.169.246
>>> user=root
>> [..]
>>
>>> But that got me thinking:
>>
>>> Is it possible to set up pam/ssh to require a secondary password when an
>>> attempt is made to log in as root from an unknown location? I don't want
>>
>> What about the most obvious? Disabling remote root logins
>> completely? ('man sshd_config')
>>

> ... and that would achieve a similar effect, since you'd now need to supply
> two passwords to become root.

> I can't really see any advantage to requiring two passwords - better just to
> make the password longer and stronger (not based on dictionary words, mixed
> case, etc etc). Remember, that since this is an attack over the network,
> it's going to be thousands of time slower than cracking (say) /etc/shadow
> locally; and it will take the attacker long enough just to try every word
> in a modest-sized dictionary.

On a multi-user system we are talking about, it has IMHO many
advantages, you can find out who became root, UID 0 isn't a
personalized account. If you are more curious, some prefer to use
sudo for anything, which has good logging capabilities. The
unlimited power of the root account is a good reason to keep it
away from network remote login. If you think you have to open
port 22 from the internet, I'd disable password login and use
key-login only with an user account.

--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo (E-Mail Removed) | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 92: Stale file handle (next time use
Tupperware(tm)!)

Michael Heiming wrote:

> In comp.os.linux.networking peter smith <(E-Mail Removed)>:
>> Michael Heiming wrote:
>
>>> In comp.os.linux.networking Captain Dondo <(E-Mail Removed)>:
>>>> I've been subjected to a fairly crude dictionary attack:
>>>
>>>> Is it possible to set up pam/ssh to require a secondary password when
>>>> an
>>>> attempt is made to log in as root from an unknown location? I don't
>>>> want
>>>
>>> What about the most obvious? Disabling remote root logins
>>> completely? ('man sshd_config')
>>>
>
>> ... and that would achieve a similar effect, since you'd now need to
>> supply two passwords to become root.
>
>> I can't really see any advantage to requiring two passwords

> On a multi-user system we are talking about, it has IMHO many
> advantages, you can find out who became root, UID 0 isn't a
> personalized account.

Sorry, yes - I wasn't suggesting that having to login as a user, then su to
root wasn't advantageous; rather than configuring PAM to require two
passwords for remot root login had no advantage over the method you
suggested.

Cheers,

Pete

--
"Linux Network Security", the ultimate book on protecting your network from
intruders. http://www.charlesriver.com/Books
BookDetail.aspx?productID=99214

"Captain Dondo" <(E-Mail Removed)> wrote in message
news(E-Mail Removed) om...
> I've been subjected to a fairly crude dictionary attack:
>
> Apr 8 05:58:38 tooth sshd(pam_unix)[20285]: authentication failure;
> logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=202.140.169.246 user=root
> Apr 8 05:58:44 tooth sshd(pam_unix)[20289]: authentication failure;
> logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=202.140.169.246 user=root
> Apr 8 05:58:48 tooth sshd(pam_unix)[20293]: authentication failure;
> logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=202.140.169.246 user=root
> Apr 8 05:58:52 tooth sshd(pam_unix)[20296]: authentication failure;
> logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=202.140.169.246 user=root
>
> But that got me thinking:
>
> Is it possible to set up pam/ssh to require a secondary password when an
> attempt is made to log in as root from an unknown location? I don't want
> to carry around my 'secret' for ssh; I want to be asked for a second,
> different password if pam/ssh sees a login request coming in from an
> unvalidated IP... That way, even if the primary password is cracked,
> there is a secondary password that would have be cracked as well.
> Hopefully, by then, other warnings will kick in.
>
> --
>
> use munged address above to email me
> SpamTrap (E-Mail Removed)
>

> #
> # Let only $SSH_GUY be permitted to even try accessing sshd.
> #
> /sbin/iptables -A INPUT -i $EXTINT -p TCP -s $SSH_GUY\
> --dport 22 -j ACCEPT
> /sbin/iptables -t nat -A PREROUTING -i $EXTINT -p tcp -s $SSH_GUY\
> --dport 22 -j ACCEPT
>
> /sbin/iptables -A OUTPUT -o $EXTINT -p TCP -d $SSH_GUY\
> --sport 22 -j ACCEPT
> /sbin/iptables -t nat -A OUTPUT -o $EXTINT -p TCP -d $SSH_GUY\
> --sport 22 -j ACCEPT
> /sbin/iptables -t nat -A POSTROUTING -o $EXTINT -p TCP -d $SSH_GUY\
> --sport 22 -j ACCEPT
>
> #
> # Default rule if not accepted above. ( You should not need this, as your
> # default POLICY should be DROP, or REJECT)
> #
> /sbin/iptables -A INPUT -i $EXTINT -p TCP --dport 22 -j DROP
> /sbin/iptables -t nat -A PREROUTING -i $EXTINT -p tcp --dport 22 -j DROP
>

Dropping or accepting packets in the nat table is strange.
Your packets have already been fitered in the filter table.

This is enough if our default output policy is to ACCEPT packets:
/sbin/iptables -A INPUT -i $EXTINT -p tcp -s $SSH_GUY
--dport 22 -j ACCEPT
/sbin/iptables nat -A INPUT -i $EXTINT -p tcp --dport 22 -j DROP

For maximum security, default policy should be DROP (at least for input):
/sbin/iptables -P INPUT DROP

And you should use the countrack module to provide statefull firewalling:
/sbin/iptables -A INPUT -i $EXTINT -m state --state NEW,ESTABLISHED

-p tcp -s $SSH_GUY --dport 22 -j ACCEPT

Regards