LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)
-   -   Is it an attack? (https://www.linuxquestions.org/questions/linux-security-4/is-it-an-attack-4175593107/)

ardabro 11-07-2016 02:27 PM

Is it an attack?
 
In my systemd logs I found a long series of entries of this type:
Code:

error: maximum authentication attempts exceeded for invalid user root from 91.201.236.158 port 54566 ssh2 [preauth]
IP is everytime the same, port number differs. Looks like the address is from Ukraine. But I don't have friends there :) Am I right that it was a brute attack?
And why does source port differ every time?

arizonagroovejet 11-07-2016 02:57 PM

If you expose SSH to the Internet bots will try to log in via it.


Ensure you don't allow root login via SSH (some distros allow it by default) E.g.
https://wiki.centos.org/HowTos/Netwo...5980dc6434d3ba

Install fail2ban or similar.
http://www.fail2ban.org/wiki/index.php/Main_Page

Ideally, don't expose SSH to the Internet.

ardabro 11-07-2016 03:10 PM

Quote:

Originally Posted by arizonagroovejet (Post 5628106)
If you expose SSH to the Internet bots will try to log in via it.

Ensure you don't allow root login via SSH (some distros allow it by default) E.g.
https://wiki.centos.org/HowTos/Netwo...5980dc6434d3ba

Install fail2ban or similar.
http://www.fail2ban.org/wiki/index.php/Main_Page

Ideally, don't expose SSH to the Internet.

Yes, I expose ssh because I need to.
My root account is disabled at all and I'm not sure, but suspect that "for invalid user root" in the message confirms this fact.
Thanks for fail2ban! I didn't know it.

sundialsvcs 11-07-2016 04:29 PM

Well, maybe you don't "need to."

As I describe in my blog post, it is entirely possible to deploy OpenVPN (with digital certificates) as your first line of defense, then to arrange for your sshd daemons (et al) to "listen" only to the virtual IP-addresses that are on the inside of that. (Every service daemon allows you to specify just what it will, and will not, "listen to.")

In order to reach sshd or what-have-you, therefore, you must now first succeed in making an OpenVPN connection . . . which will require one kind of one-of-a-kind digital certificate . . .

. . . and, furthermore . . . your OpenVPN server won't even respond to you, to allow you to try to make a connection to it, unless you can show that you are in possession of a(nother) one-of-a-kind (tls-auth ...) certificate.

In a single stroke, the cacophony of "access attempts" is replaced by ... an almost-eerie silence. To the Internet world-at-large, your servers have become: "The Walls of Moria." There appear to be no "open ports" at all. A port-scan reveals ... nothing.
Quote:

(1:06) "Dwarf doors are invisible when closed. [Even...] their masters cannot find them, if their secrets are forgotten ..."
Meanwhile, all of your legitimate users, armed with their one-of-a-kind (and non-revoked) digital certificates, pass easily and quickly through the gantlet. They are not impeded in the slightest, yet "no one else can enter." In fact, "no one else can even come near."

Yes, it can be done. Easily.

But kindly notice what has quietly disappeared: "passwords." (At least on the front lines ...) No more is anyone or anything asking you to "say the magic word." You may enter (nay, you may approach ...) only if you possess the necessary one-of-a-kind credentials, and then(!) only if those credentials have not been revoked.

Which, but-of-course, should not be "even the slightest bit strange to you," because you face the self-same gantlet every single day when you "swipe or tap your $BADGE at $WORK." :)

So ... "go thee, and do the selfsame thing," and rejoice at the silence which ensues! :jawa:

ardabro 11-07-2016 04:37 PM

Quote:

Originally Posted by sundialsvcs (Post 5628139)
Well, maybe you don't "need to."
As I describe in my blog post, it is entirely possible to deploy OpenVPN (with digital certificates) as your first line of defense,
Yes, it can be done. Easily.

Looks very interesting. Maybe one day...

sundialsvcs 11-07-2016 05:07 PM

Quote:

Originally Posted by ardabro (Post 5628143)
Looks very interesting. Maybe one day...

Eventually, you grow tired of wasting your own time. (No offense intended ...)

Basically, "some technologies are suitable to be your first line of defense," while others are not.

IMHO, sshd falls irreparably into the second category, for one very simple reason:
Quote:

"ssh, in spite of the fact that it encrypts its traffic to the destination host, nevertheless is . . . 'a shell.' And this, unfortunately, is a damnation that it by-definition(!) can never expunge."
Unless you go to rather extraordinary efforts to do otherwise, ssh will always present you with this accursed(!) prompt . . .

login:

Because "there is where your troubles begin and end." Suddenly, the security of your entire system(!) has been reduced to "a race between a guessed-userid and Webster's Unabridged Dictionary, which can be freely initiated by any and every computer system on Planet Earth."

... Which is emphatically not the gantlet that "your company's employees very-routinely face every day, at the front door."
  • First of all, either they have a badge, or they don't.
  • Then, either that badge works, or it doesn't.
Period.™

Face it: "the front door" is billions(!) of times more secure!

"That electronic badge which you routinely keep in the coffee-cup holder in your car," after all, contains probably quite-a-bit of random cryptographic content, which ensures that another badge manufactured by the same security vendor would work at your place of employment.

Provisions exist by which your company's security department is able to centrally and securely control exactly who is able to gain access to "the front door," and who is not.

Believe it or not, the same level of control is available to you, and to your company. (Through Linux, and/or otherwise.)

Sefyir 11-07-2016 11:00 PM

Securing sshd isn't hard. sshd is plenty secure by simply disabling username / password entry and enabling public key encryption.

Follow this short guide

Local
Code:

$ ssh-keygen -t rsa -b 4096
$ ssh-copy-id your_server
$ ssh your_server

Server
Code:

/etc/ssh/sshd_config
# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no
...
RSAAuthentication yes
PubkeyAuthentication yes

Now, keep the current ssh session open and restart the sshd service on the server

Code:

sudo service ssh restart
Make sure you can connect to the server with a new terminal before you close the old one.
This can be completed in less then 5 minutes and will prevent someone breaking in by guessing your pass. Just make sure to backup your private key (~/.ssh/id_rsa)

rkelsen 11-07-2016 11:26 PM

Quote:

Originally Posted by sundialsvcs (Post 5628148)
Unless you go to rather extraordinary efforts to do otherwise, ssh will always present you with this accursed(!) prompt . . .

login:

Because "there is where your troubles begin and end." Suddenly, the security of your entire system(!) has been reduced to "a race between a guessed-userid and Webster's Unabridged Dictionary, which can be freely initiated by any and every computer system on Planet Earth."

You can easily easily configure sshd to only accept PKI. This will prevent it from presenting a login prompt.


All times are GMT -5. The time now is 10:48 PM.