I've got a VPS, now what M's should I RTF?

[keith smith]

If you want to secure SSH you can us IPTables to limit access to the IP's of your choosing.  As long as your IP does not change you will be good to go.  

------------------------

Keith Smith

--- On Mon, 8/8/11, R P Herrold <herrold at owlriver.com> wrote:

From: R P Herrold <herrold at owlriver.com>
Subject: Re: I've got a VPS, now what M's should I RTF?
To: "Main PLUG discussion list" <plug-discuss at lists.plug.phoenix.az.us>
Date: Monday, August 8, 2011, 12:52 AM

On Sun, 7 Aug 2011, Ed wrote:

> what Russ said +1

> transition sshd to listening on a high/non-standard port +1

I disagree here, but this is a matter of taste as there are valid arguments on each side -- the utility of a mere port change alone, without a barrier of 'port knocking', is trivially defeated by nmap and friends

and at that point, we are better back in the realm of wrappers and iptables, per my outline.  But this is just IMHO


+1 The suggestion in the thread of fail2ban on ssh, as such is in my personal automated scripted hardening for every instance I deploy at pmman

http://orcorc.blogspot.com/2010_12_01_archive.html


> AIDE (or tripwire or samhain) done from a remote system +1
>    http://www.deer-run.com/~hal/sysadmin/FIA-via-SSH.html

tripwire does not cope with modern library pre-linking well; aide for RH derived family systems;  remote verification through ssh, sadly, cannot be trusted, because there is a working exploit out there that replaces the sshd with a poisoned variant that hides such damage, and sniffs passwords (as with sudo)

To be certain, one has to be mounting an image to check RO, and non-hot, and checking from a checker not inside the running system; PMMan permits this natively for post-exploit forensics, and we've used it in post-compromise analysis. The topic of the _possible_ strneghts of systems, and their vulnerability to attacks from 'outside' the system, are well-covered in 'Godel, Escher, and Bach' -- If you have NOT taken a month to read it slowly, you ** need to **


... As such, I hold, and need to do a more careful treatment of the thesis that when one has to set up a second end account on a box, GAINING rights is not viable any more, b/c such sniffers, and the possibility of chaned 'leap-frog' attacks, and on account of the human tendancy to re-use passwords or predictable variants [the separete Fedora and Red Hat compromises were probably of this class of chained compromise type: http://www.owlriver.com/projects/packaging/#compromises , #11 and 12]

So: no more 'sudo up'; and only '/bin/su -', or keyed 'ssh -l lesser_account localhost' when one needs X forwarding, down in rights


I run a different, complex, machine generated, and sadly, non-memorizable password for every new site, and have a well-protected master store

http://orcorc.blogspot.com/2010/07/line-noise-and-random-numbers.html

The generation script has grown a bit since I wrote that post, to handle all the site variations as to what the remote site accept (the 'password complexity checking' algorithms out there of course conflict in mutually incompatible ways, and so I extend the generator to handle new prejudices of a given site when I hit them)

[herrold at bronson ~]$ gen-pw.sh -h
Usage: gen-pw.sh [-a] [-h] (length)
       -a limits to alphanumerics (default)
       -l limits to letters
       -m is mixed alphanumerics and specials
       -n is only numerals
       -x is only hexadecimal digits

       (length) is the optional maximum length
          ... length defaults to 14

 ... last option dominates
[herrold at bronson ~]$ for i in `seq 1 5 ` ; do gen-pw.sh -a ; gen-pw.sh -l ; gen- pw.sh -m ; gen-pw.sh -n; gen-pw.sh -x ; done
c4128084NHilP6W5
BBeBoPkicmfLokJP
g!U60g51gEjG][]J
5624307050226052
aa5851ae41eb59e0b
kTR062L5188iL63E
FgFcLiggHNdPiBgg
N!#W{NN852pO*@*L
3025344532055200
b85dc0a13df0d1f80
JYT1T1W4WEYgI86W
aHiJaLcgeHmCemHc
J!c498*iE9mP)[)g
3831315851260112
82f882866eef1deef
LR81P520RPooH4Y2
LFeFDLeLHeoGPeDJ
k!ia9T6R6TdP#~#i
  ...

... looks like I have a logic error in the 'truncation to size' algorithm for hex passwords.  As long as I am in there reworking that part of the code, I'll add alternation between upper and lower hex digits in the output to get a 'bigger' pool of entropy going, for the (probably rare) case of a remote algo that does not force all hex to one case before hashing it.  BRB

This works:

[ "x${HEX}" = "xy" ] && {
        [ "x${DEBUG}" = "xy" ] && echo -n "HEX: "
        echo -n "${SNIPX23}${SNIPX24}${DECK}${HEX3}${HEX4}${SNIPX25}${SNIPX26}$
                cut -c 1-4 | tr 'abcdef' 'ABCDEF' | tr -d '\r\n'
        echo "${SNIPX23}${SNIPX24}${DECK}${HEX3}${HEX4}${SNIPX25}${SNIPX26}${SN
                cut -c 5-
        }

$ for i in `seq 1 5 `; do gen-pw.sh -a ; gen-pw.sh -x ; done
J73D8k65UBYkG7TY
ACC7051b7ffe38f7
oW4k6F8L2U8kH7W6
0E49fbcb73eb17e3
aE97c46654YlC4E7
CEF7646cdea633ab
J47745c75T7iA050
A988276799a867ab
o819Y805iD1cK237
A7BA944770167b18

[herrold at centos-5 bin]$ ci gen-pw.sh
RCS/gen-pw.sh,v  <--  gen-pw.sh
new revision: 1.5; previous revision: 1.4
enter log message, terminated with single '.' or end of file:
>> fix hex bug as to length, add UC and lc digits
>> 
done
[herrold at centos-5 bin]$ co -l gen-pw.sh
RCS/gen-pw.sh,v  -->  gen-pw.sh
revision 1.5 (locked)
done
[herrold at centos-5 bin]$


-- Russ herrold

I'll prolly work this up into a couple of blog posts, so I'll hang an explicit notice as to Copyright here

--
end
==================================
 .-- -... ---.. ... -.- -.--
Copyright (C) 2011 R P Herrold
      herrold at owlriver.com
   My words are not deathless prose,
      but they are mine.
---------------------------------------------------
PLUG-discuss mailing list - PLUG-discuss at lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.PLUG.phoenix.az.us/pipermail/plug-discuss/attachments/20110808/4a643d26/attachment.html>