break-in attempt in my machine

Thu Sep 1 13:35:25 UTC 2016

I'm a bit late to the party, and I'm not sure if this has been mentioned,
but this is where Fail2Ban is ideal. I never put in a production web server
(or ANY public server) without having Fail2Ban configured to block stuff
like this.  Doesn't really fix this problem, but it will avoid a LOT of
this in the future.

On Thu, Sep 1, 2016 at 7:55 AM, <J.Witvliet at mindef.nl> wrote:

> If you have a /64 or a /48 IPv6 available, Just use one of them _only_
> for ssh. With the millions possible adresses, even kiddies Won't find them
> accidentally.
> And with the first failure, just change your AAAA entry.
>
>
> Verstuurd vanaf mijn iPhone
>
> > Op 30 aug. 2016 om 06:09 heeft Joel Rees <joel.rees at gmail.com> het
> volgende geschreven:
> >
> > n Tue, Aug 30, 2016 at 7:34 AM, Karl Auer <kauer at biplane.com.au> wrote:
> >>> On Tue, 2016-08-30 at 06:34 +0900, Joel Rees wrote:
> >>> I'm feeling ornery today.
> >>
> >> Clearly!
> >
> > Yeah.
> >
> >>>> 1: Turn off password access; require a publickey login.
> >>> Does not get rid of the password problem, just moves it. Be aware how
> >>> the management issues change, particularly that this doesn't help
> >>> against keyloggers.
> >>
> >> No. But it helps a LOT against the script kiddies,
> >
> > And my thought there was that skript kiddies are no longer the only
> > people we should worry about.
> >
> > It's a good list to get started, but we should really be encouraging
> > users to understand what logging in means, how it is done, how these
> > attacks use our computers against us, and so forth.
> >
> >> who are trying only
> >> passwords. Using publickey makes a successful ssh login with only a
> >> password impossible.
> >
> > One thing that people miss is that the keyboard and the network are
> > two separate vectors. What's appropriate for one is not appropriate
> > for the other.
> >
> >> As to keyloggers: That's a whole different class of attack, and it is
> >> just confusing the issue here.
> >
> > How confident can the average user who has been surfing random places
> > in the Internet be that one of the browser scripts, etc., that has
> > detached itself from a recent browser session is not, in fact, a
> > keylogger?
> >
> >>> We really do need tokens to be different according to the login
> >>> device, but nobody is focusing on that.
> >>
> >> There are a thousand things one could and should do. I gave a list of
> >> the most important ones, *in the context of script-kiddy attacks*.
> >
> > :)
> >
> >>>> 2: Move ssh to a different port.
> >>> Check commonly used port definitions. Watch your logs to be sure you
> >>> don't acidentally use a port used by malware, etc.
> >>
> >> That's why I said to use ports higher than 1024.
> >
> > A quick browse through /etc/services is amusing.
> >
> > So is a walk through a resource like
> >
> >    https://www.sans.org/security-resources/idfaq/which-
> backdoors-live-on-which-ports/8/4
> >
> >> Whatever port you use
> >> does have to be allowed to reach your ssh server though, and I guess
> >> that's what you are getting at when you mention malware.
> >
> > Actually, I was thinking of some time back when I moved home
> > workstation ssh port to something like 33561 and found I was living an
> > exciting life. So to speak. Not a neighborhood I had intended to be
> > in.
> >
> >>> In other words, this is helpful against non-targeted attacks, not so
> >>> much against targeted attacks.
> >>
> >> It's security through obscurity, but it is *extremely* effective
> >> against script-kiddy automated attacks. Move off port 22, and watch the
> >> attacks disappear.
> >
> > But we need to be thinking about whether the kiddies are the only
> > attackers we need to worry about.
> >
> > I know I have nothing of value in my home network. My son might not be
> > so sure he has nothing of value in my network. Or some attacker might
> > think I look like I might have something valuable, just because I rant
> > strange things in my blogs from time to time.
> >
> > Moving the port doesn't always make the attacks disappear. You need to
> > check your logs periodically. Of course, as you'll point out here,
> > attacks on an upper range port are something more of a cause for
> > concern than attacks on port 22.
> >
> >>> Especially make sure root ssh access is off, as someone mentioned,
> >>> and don't use obvious userids like "admin", as I think someone else
> >>> made a reference to.
> >>
> >> If you are allowing only publickey access, it doesn't matter a bean
> >> what your user names are.
> >
> > It matters less, anyway. Still, sudo admin looks a lot more
> > interesting in a keylogger report than sudo tom.
> >
> >>>> 5: If you will only be logging in from a limited set of other
> >>>> systems, allow ssh logins only from those addresses (or subnets).
> >>> And remember that IP addresses can be spoofed.
> >>
> >> Yes they can be. But they mostly aren't, and you have still massively
> >> reduced the range of potential source networks for the script-kiddy
> >> attacks. Also, unless the spoof is coming from a very close-by (or
> >> local) network, it's unlikely to be able to complete an ssh handshake,
> >> because the return packets will not reach the spoofer.
> >
> > It's the pwned boxes on the inside of the local network that we need
> > to think about, isn't it?
> >
> >>>> 7: If you are IPv6 capable, turn off IPv4 access.
> >>> Why? Are all the skript kiddies staying away from IPV6?
> >>
> >> Because it reduces the potential sources. And oddly enough, yes, most
> >> of the script kiddies DO seem not to use IPv6. I have not had a SINGLE
> >> such attack on my IPv6-capable networks. Doesn't mean others are not
> >> seeing them. When IPv6 becomes more widespread, I guess it will pick
> >> up, but for now this is a simple way to reduce the opportunities for
> >> such attacks if you are lucky enough to be able to use IPv6.
> >
> > Well, if you can afford to go all-IPv6 now, I think you've just told
> > the attackers you have something interesting in you network.
> >
> >>>>> My password is in no dictionary
> >>>> Don't bet on that.
> >>> r0C<3t5c!ensN0+?
> >>>
> >>> Yeah. Unfortunately, L337$pe4< can be partially automated these days.
> >>
> >> It's more that people are really bad at choosing good passwords. Even
> >> people who are trying hard to choose good ones end up choosing bad
> >> ones.
> >
> > So let's point at lessons in how to choose or make up hard, but useful
> > passwords and passphrases, because, even though, as you say,
> >
> >> A bad passphrase on an ssh private key is much better than a bad
> >> password being used directly.
> >
> > you still want good protection on your local keystore.
> >
> > (Suggesting you add a little theory to your blogpost you linked to a
> > bit back. I know how easy it is to get offtrack when you dig into
> > theory. Some of my own technical blogposts tend to be so esoteric that
> > they may be more hindrance than help to the average user, but I think
> > it's important to try to help each other understand what's going on.)
> >
> > --
> > Joel Rees
> >
> > I'm imagining I'm a novelist:
> > http://joel-rees-economics.blogspot.com/2016/06/econ101-novel-toc.html
> >
> > --
> > ubuntu-users mailing list
> > ubuntu-users at lists.ubuntu.com
> > Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/ubuntu-users
> >
>
> Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u
> niet de geadresseerde bent of dit bericht abusievelijk aan u is
> toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht
> te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van
> welke aard ook, die verband houdt met risico's verbonden aan het
> elektronisch verzenden van berichten.
>
> This message may contain information that is not intended for you. If you
> are not the addressee or if this message was sent to you by mistake, you
> are requested to inform the sender and delete the message. The State
> accepts no liability for damage of any kind resulting from the risks
> inherent in the electronic transmission of messages.
>
> --
> ubuntu-users mailing list
> ubuntu-users at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/ubuntu-users
>

-- 

Mark Haney ::: Senior Systems Engineer
*VIF* *International Education*
P.O. Box 3566 ::: Chapel Hill, N.C. 27515 ::: USA
919-265-5006 office

Global learning for all.
www.viflearn.com
Find VIF on Facebook <http://facebook.com/VIFInternationalEducation> |
Twitter <https://twitter.com/vifglobaled> | LinkedIn
<http://www.linkedin.com/company/vif-international-education>

Recognized as a ‘Best for the World’
<http://bestfortheworld.bcorporation.net/> B Corp!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-users/attachments/20160901/2acf24d1/attachment.html>