[mythtv-users] ssh attack

[Bill]

Yet another solution...  Well, 4.

 0. Run sshd on a different port.

 1. Turn off sshd from the outside world

 2. If you need to ssh in from outside, limit it to the specific IP's
you are coming from.  If those places are DHCP'd, limit it to the
network ranges they are on.  While it allows a few others, it still
knocks off 99.999999% of the internet (I am guessing at 99.999999%)

 3. Run an OpenBSD PF firewall and tinker with limiting ssh connections
from source addresses...  Limit it to one per source ip at a time...
this will slow things down a bit for whatever is probing.

I've never been fond of automatically blocking Ip's unless you are
simply blacklisting and then de-listing them after an interval.  

I'd like to see a tarpit for sshd... like OpenBSD's spamd... now that
makes for fun log reading.





On Thu, 29 Dec 2005 21:22:06 -0800 (PST)
<zoiks2004-ivtv at yahoo.com> spake:

> Since we're talking about solutions, I'll describe
> mine.  I have two basic servers on the home network,
> and various client machines.  The main firewall blocks
> all incoming ports except 22 and 80 (and of course
> those used in normal NAT operations).
> 
> One server is the main one, and all port 22 and 80
> traffic is directed to it (the other server is a myth
> BE/FE).  This server has iptables set up to accept all
> port 80 traffic (it is running apache2, with a
> configuration that enhances security somewhat).  It
> drops without error, using iptables, any port 22
> traffic except that which was sent from a whitelisted
> ip address.
> 
> Addresses can be added to the whitelist by accessing a
> special cgi script.  If the url/request is formed
> well, it will add the address that the http request
> apparently came from to the whitelist (not directly,
> since it has only www privileges).  That way I can
> connect from a random place.  Since iptables is
> silently dropping (and logging) non-whitelisted ip's,
> scripts at least don't get the benefit of confirming
> there's a running sshd at that address.
> 
> All connections to any machine on the network have to
> be port-forwarded through the ssh connection, even non
> port 22 connections to the server itself.  So I can
> mount drives, load up mythweb, etc, once I've tunneled
> in.
> 
> I've been operating this way for well over a year and
> it's been working great.  The ssh attempts still occur
> though, a few times a day, especially from apparently
> compromised machines in Korea lately.
> 
> Naturally, I don't use mythtv:mythtv as user:pw.  And
> of course, root logins are disallowed on all machines
> running sshd.  I'm sure my network could be "hacked",
> but it certainly ain't gonna be the easiest one on the
> block to break into!  And as you might guess, wireless
> is WPA with a strong key.
> 
> 
> --- Robert Kulagowski <bob at smalltime.com> wrote:
> 
> > >>This of course won't happen behind a properly
> > configured firewall, correct?
> > >>
> > >>Darren Hart wrote:
> > >>
> > >>
> > >>>I'm sure nobody here is dumb enough to do this,
> > but since I was,
> > >>>thought I'd pass the word.
> > >>>
> > >>>There is an ssh attack going around with a brute
> > force login using
> > >>>2187 different username/password pairs, one such
> > pair happens to be:
> > >>>
> > >>>mythtv:mythtv
> > 
> > If you need to use ssh from outside your firewall,
> > you could do what
> > I've done; get rid of a password-based logon
> > alltogether and use public
> > / private keys.
> > 
> > Since I use putty at work, it's what I'm familiar
> > with.  In a Windows
> > environment:
> > 
> > 1) Download putty, puttygen and pageant from
> > http://www.chiark.greenend.org.uk/~sgtatham/putty/
> > 
> > 2) Run puttygen to generate a public / private
> > keypair.
> > 3) Take the public key portion (it's just text) and
> > paste it into
> > ~/.ssh/authorized_keys
> > 4) Edit /etc/pam.d/ssh and look for the line:
> > # Standard Un*x authentication.
> > @include common-auth
> > 
> > Put a "#" infront of @include common-auth so that
> > it's:
> > #@include common-auth
> > 
> > This will restrict ssh from looking at /etc/passwd
> > and /etc/shadow
> > 5) Create a passphrase for the key that you just
> > created.  Take the
> > private key that puttygen created for you and save
> > it.  You'll need it
> > _every_ time you login from that point on, even
> > internally.  If you're
> > using putty, you'll need to provide the filename in
> > connection > ssh >
> > auth when you're setting up your connection profile.
> > 6) If you don't want to keep typing your passphrase
> > every time, load the
> > private key into pageant; you type it in once, and
> > then if you use putty
> > to login, pageant will supply the passphrase
> > automatically.
> > _______________________________________________
> > mythtv-users mailing list
> > mythtv-users at mythtv.org
> >
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
> > 
> 
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


-- 

Bill Chmura
Director of Internet Technology
Explosivo ITG
Wolcott, CT

p: 860.621.8693
e: bill at Explosivo.com
w. http://www.explosivo.com