Traceroute Fun

ben_lubar

I'm assuming the machine isn't physically accessible to an attacker, because if it is, they could just put a LiveCD in and plug in a keyboard and monitor and do whatever they want.

My regular user already has a secure password because I only need to type it for sudoing. I could set root to have that password, but that's extra work to achieve 0 added benefits. I could also run all my programs using a pen and paper, but it's not going to make anything better.

There is no "working locally" unless I majorly fuck up the OS and need to reinstall.

If you're saying that this:

SSH in as ben
su -c 'apt-get dist-upgrade'
Type password

is better than this:

SSH in as ben
sudo apt-get dist-upgrade
Type password

the only reason I can think of is if you have a broken o key.

dkf

@flabdablet said:

One of the nice things about sudo is the way it will suppress asking for a password until you've not used it for fifteen minutes within a given shell session; I get the same kind of convenience from su just by leaving my root terminal minimized but open until I've finished whatever I opened it for.

Having a terminal open is not as good; you're much more likely to type into the wrong terminal than to put sudo when not intending it.

Also, sudo has a finer-grained elevation and logging model than su.

JBert

@ben_lubar said:

There is no "working locally" unless I majorly fuck up the OS and need to reinstall.

Oh, you're exclusively using SSH. Yeah, that's different.

flabdablet

@dkf said:

you're much more likely to type into the wrong terminal than to put sudo when not intending it

Doesn't happen. My root terminal is a different colour.

flabdablet

@dkf said:

sudo has a finer-grained elevation and logging model

Which is useful and worthwhile and good, unless you're just using it for blanket privilege escalation for no better reason than that Canonical has deemed it to be the official synonym for "please".

@ben_lubar said:

If you're saying that this:

SSH in as ben

su -c 'apt-get dist-upgrade'

Type password

is better than this:

SSH in as ben

sudo apt-get dist-upgrade

Type password

I'm saying that

SSH in as root
apt-get dist-upgrade

is better than both of those.

I'll go even further than that and say that leaving password-based ssh login enabled for root is also perfectly sound, as long as you don't use a stupid password. A workflow based on storing a high-entropy root password in your KeePass is resistant to a wider class of attacks than one that requires storing an ecdsa private key in your ~/.ssh folder.

dkf

@flabdablet said:

I'll go even further than that and say that leaving password-based ssh login enabled for root is also perfectly sound, as long as you don't use a stupid password.

I disagree. Disable all password-based ssh login capability and require people to turn up with a key or not at all; it really does discourage unwanted scum. You might know that they can't get in, but they don't and they keep on trying. Better to get them to fuck off immediately.

flabdablet

@dkf said:

require people to turn up with a key or not at all; it really does discourage unwanted scum.

Scum who keep hitting my port 22 don't know whether I have password-based login turned off or whether I don't.

@dkf said:

You might know that they can't get in, but they don't and they keep on trying.

That's what fail2ban is for.

Putting your ssh server on an obscure high port also eliminates 99.99% of random probing. My home's network is configured that way.

hungrier

@ben_lubar said:

the only reason I can think of is if you have a broken o key.

You can tab-complete sudo

accalia

@flabdablet said:

I'll go even further than that and say that leaving password-based ssh login enabled for root is also perfectly sound

yes. that's why i run several servers that drop you into a honeypot when you attempt to log in as root, avatar, administrator or torvalds

they also run fake FTP sites with open uploads (they drop the upload to /dev/null, only recording the filename and length, then pipe /dev/urandom at you when you attempt to download the file, and it resets internal state every half hour too)

oh, you meant for day to day purposes, not for trolling scriptkiddies and bad hackers*

*bad as in terrible, not as a morality judgement.

flabdablet

@accalia said:

you meant for day to day purposes, not for trolling scriptkiddies and bad hackers

It's a floor wax and a dessert topping!

dkf

@flabdablet said:

That's what fail2ban is for.

http://i.imgur.com/vZyiaZw.gif
I wanted a different Krieger picture.

@flabdablet said:

Putting your ssh server on an obscure high port also eliminates 99.99% of random probing.

Until the info leaks. Plus you've got to pick something actually obscure and not just “obscure”.

dkf

@dkf said:

pick something actually obscure

Or failing that, put it on port 9¾ ;)

accalia

@dkf said:

Until the info leaks. Plus you've got to pick something actually obscure and not just “obscure”.

easy peasy!

make SSH listen to port 50000 + ((($CJD %7) * ($CJD %11)) % 1000) where $CJD is the current julian date for the year.

dkf

I really wouldn't recommend using ports over 32767; that's the space that is used by the OS for automatically-chosen client-side ports. While collisions don't happen very often, they look really strange when they occur (as “can't happen” problems suddenly decide to happen anyway).

flabdablet

@dkf said:

put it on port 9¾

https://www.youtube.com/watch?v=T2Y7oo3iB40

flabdablet

@dkf said:

I really wouldn't recommend using ports over 32767; that's the space that is used by the OS for automatically-chosen client-side ports.

I do it by creating a permanent NAT mapping from TCP port 35887 on my public IP address to port 22 of an ssh server in my LAN. I've never seen it fail; the NAT subsystem seems pretty competent at avoiding port allocation collisions.

accalia

@dkf said:

I really wouldn't recommend using ports over 32767

s/50000/20000/ then.

point is to have thhe port change "semirandomly" daily

bonus points for having the entire port range respond to ssh connections with a valid "authentication failed" response

dkf

@accalia said:

bonus points for having the entire port range respond to ssh connections with a valid "authentication failed" response

flabdablet

@accalia said:

point is to have thhe port change "semirandomly" daily

I've actually stuck with the same randomly chosen high-numbered port for the last five years, and there are still not enough probes in my syslog to warrant installing fail2ban.

accalia

@flabdablet said:

@accalia said:
point is to have thhe port change "semirandomly" daily

I've actually stuck with the same randomly chosen high-numbered port for the last five years, and there are still not enough probes in my syslog to warrant installing fail2ban.

depends on your level of paranoia i guess.

flabdablet

I think I have enough paranoia.

Every now and then I zgrep fail /var/log/auth* on my publicly accessible ssh server boxes, and I have actually never seen a failed ssh login due to anything other than my own accaliafingers.