more ponder - Linux, security and the concept of "working from home"

[Per Christensen]

A few days ago I in another thread mentioned two recent significant
local "ransomware" attacks, one against a shipping company and another
affecting a local Municipality resulting in serious implications for
both, where I now today in a national "pink financial paper" read of yet
another attack locking a stock listed company servicing computerized
operation of many of our fish farms.
In a interview with the paper the CEO in "AKVA Group" is open and
explain about essential locked files, a ransom for money set to unlock,
and apropos mention that "Office" and "Teams" still works, In todays
article it is further noted that several national security authorities
Sunday issued a warning.
I myself is educated in and work in fields far away from IT and have no
idea how these "ransomware" find their way into the systems.
Thoughts are: Due to the pandemic many now work from a "home office",
perhaps often mainly constituting of a new Windows 10 laptop coming with
the Edge (Chrome based) browser. One could guess there is a link between
ransomware being on the rise and the relative new concept of "home office".
And when using a maintained and regularly updated Slackware 14.2 the big
question is - is a basic Linux home office system these days (e.g with
telnet, database, web-server uninstalled etc.) and running Firefox and
Thunderbird as secure as, or perhaps even to prefer over other operating
systems when "working from home"?

[bad sector]

maybe the security of home connections is something to look at,
not to mention all them 'cloud' thingies?

I always figured that security and connectivity didn't mix at all..

also, in the old days a wooden ships carried the goods while today
it may be a server-complex that does the same thing; piracy against
the former was a hanging crime.

[Henrik Carlqvist]

On Wed, 13 Jan 2021 02:17:35 +0100, Per Christensen wrote:
> And when using a maintained and regularly updated Slackware 14.2 the big
> question is - is a basic Linux home office system these days (e.g with
> telnet, database, web-server uninstalled etc.) and running Firefox and
> Thunderbird as secure as, or perhaps even to prefer over other operating
> systems when "working from home"?

Simply running a stock Slackware system connected directly to the
internet will not be secure as by default Slackware will have a lot of
ports open including ssh. It is prepared to become secure by adding some
kind of /etc/rc.d/rc.firewall and, as you say, you will need to keep it
updated with security patches.

Another, for most but not all obvious, thing to do is to add one or more
ordinary user accounts to the system for your everyday work. If such a
user account gets compromised the malware or intruder will only be able
to affect files which that user has access to. A normal user will not be
able to do things like wiping out traces in the log files or overwrite
system binaries like /bin/ls with malware versions.

But just running a stock Slackware will not make you safe just because it
is Linux. In my firewall I have done a port forward of the somewhat
customized port 2222 to the ssh port 22 to a machine in my DMZ network.
Even though I have ssh on a non standard port this is what comes into my
log files:

-8<--------------------------------------------------------------------
...
Jan 13 07:40:37 igor sshd[8241]: Failed password for invalid user atom
from 47.241.11.61 port 54948 ssh2
Jan 13 07:40:37 igor sshd[8243]: Failed password for invalid user ts3
from 208.109.11.24 port 51198 ssh2
Jan 13 07:40:56 igor sshd[8245]: Failed password for root from
202.73.13.139 port 53520 ssh2
Jan 13 07:41:24 igor sshd[8247]: Failed password for root from
121.54.189.15 port 38664 ssh2
Jan 13 07:41:53 igor sshd[8249]: Failed password for invalid user
q3server from 115.159.200.183 port 40402 ssh2
Jan 13 07:42:09 igor sshd[8253]: Failed password for invalid user rust
from 202.73.13.139 port 41648 ssh2
Jan 13 07:42:38 igor sshd[8255]: Failed password for invalid user ntps
from 47.241.11.61 port 58024 ssh2
Jan 13 07:42:42 igor sshd[8257]: Failed password for invalid user user001
from 180.76.61.29 port 37338 ssh2
Jan 13 07:43:11 igor sshd[8259]: Failed password for invalid user
ftp_test from 115.159.200.183 port 52232 ssh2
Jan 13 07:43:12 igor sshd[8261]: Failed password for invalid user
postgres from 159.203.37.91 port 49854 ssh2
Jan 13 07:43:21 igor sshd[8263]: Failed password for invalid user irina
from 202.73.13.139 port 58002 ssh2
Jan 13 07:43:28 igor sshd[8265]: Failed password for root from
121.54.189.15 port 48279 ssh2
Jan 13 07:44:29 igor sshd[8269]: Failed password for invalid user dev
from 115.159.200.183 port 35834 ssh2
Jan 13 07:44:32 igor sshd[8271]: Failed password for invalid user ftp
from 202.73.13.139 port 46124 ssh2
Jan 13 07:44:32 igor sshd[8274]: Failed password for invalid user
testuser from 173.24.113.136 port 41062 ssh2
Jan 13 07:44:36 igor sshd[8273]: Failed password for invalid user csgo
from 47.241.11.61 port 32874 ssh2
Jan 13 07:45:36 igor sshd[8279]: Failed password for root from
121.54.189.15 port 57897 ssh2
Jan 13 07:45:46 igor sshd[8281]: Failed password for invalid user user
from 202.73.13.139 port 34242 ssh2
Jan 13 07:45:58 igor sshd[8285]: Failed password for invalid user test
from 173.24.113.136 port 34248 ssh2
Jan 13 07:46:02 igor sshd[8283]: Failed password for daemon from
115.159.200.183 port 47664 ssh2
Jan 13 07:46:12 igor sshd[8287]: Failed password for invalid user
postgres from 159.203.37.91 port 40130 ssh2
Jan 13 07:46:37 igor sshd[8289]: Failed password for invalid user hadoop
from 47.241.11.61 port 35958 ssh2
Jan 13 07:47:02 igor sshd[8293]: Failed password for invalid user steve
from 202.73.13.139 port 50600 ssh2
Jan 13 07:47:02 igor sshd[8291]: Failed password for root from
192.144.167.212 port 55884 ssh2
Jan 13 07:47:21 igor sshd[8296]: Failed password for root from
173.24.113.136 port 56514 ssh2
Jan 13 07:47:44 igor sshd[8298]: Failed password for invalid user vijay
from 121.54.189.15 port 39283 ssh2
Jan 13 07:48:15 igor sshd[8300]: Failed password for invalid user tom
from 202.73.13.139 port 38722 ssh2
Jan 13 07:48:34 igor sshd[8325]: Failed password for invalid user ftpuser
from 208.109.11.24 port 64419 ssh2
Jan 13 07:48:35 igor sshd[8319]: Failed password for invalid user butter
from 47.241.11.61 port 39040 ssh2
Jan 13 07:48:41 igor sshd[8329]: Failed password for root from
173.24.113.136 port 49956 ssh2
Jan 13 07:48:45 igor sshd[8327]: Failed password for invalid user git
from 192.144.167.212 port 45760 ssh2
Jan 13 07:49:25 igor sshd[8350]: Failed password for invalid user tmpuser
from 159.203.37.91 port 58638 ssh2
Jan 13 07:49:29 igor sshd[8356]: Failed password for invalid user cesar
from 202.73.13.139 port 55080 ssh2
...
-8<-------------------------------------------------------------------

I have a cron job running every hour which parses the log file for IP
addresses failing too many times and routing those IP addresses to /dev/
null. The list of IP addresses being routed to /dev/null at the time of
this writing contains 30840 entries.

An unprotected Slackware machine with ssh open to internet will get
broken in to with root access within minutes, hours or days by brute
force depending upon the strength of the password. It is a rather good
idea to add the line "PermitRootLogin no" to /etc/ssh/sshd_config.

regards Henrik

[Per Christensen]

true, piracy in the days of wooden ships was a capital crime where the
corpse of Captain Kidd after his execution was put in a cage and on
display hanging outside Tower of London as a warning to other sailors.
Probably society will not reintroduce this punishment but setting others
health or welfare at risk just by programming these malicious intended
programs is a shameful offense.

[Per Christensen]

Henrik - the log you provide is very informative showing how
disturbingly frequent attempts of intrusion happen, thank you - I
immediately strengthened my passwords!
Personally I try to follow the recommendations given at

https://docs.slackware.com/howtos:security:basic_security

and have therefore copied a "rc.firewall" file generated with Alien Bobs
Firewall Generator into /etc/rc.d/ and the recommended "xserverrc" file
into /etc/X11/xinit/ and afterwards set both files as executables with
the chmod a+x command.
This have so far not affected Thunderbird or Firefox where e.g. PayPal
still works fine (using "double authentication" including a confirmation
key sent to my phone etc).
Following your suggestion I have added "PermitRootLogin no" to
sshd_config (probably meaning Firefox only will work from my user
account - which is great!) - thanks again :)

[Henrik Carlqvist]

On Thu, 14 Jan 2021 03:33:05 +0100, Per Christensen wrote:
> Following your suggestion I have added "PermitRootLogin no" to
> sshd_config (probably meaning Firefox only will work from my user
> account - which is great!)

The "PermitRootLogin no" in sshd_config only affects ssh logins which are
remote logins from other machines in the network. You will still be able
to login as root on the console and in any grapical login manager like
xdm/kdm. And once logged in as root you will still be able to run
graphical programs in X including Firefox.

However, as you say, running Firefox as root is not a great idea. Better
to login as an ordinary user to run such programs.

Yesterday I had 30840 IP addresses in my blacklist, at the time of this
writing that number has grown to 30918.

regards Henrik

[John Forkosh]

Thanks for that suggestion/info. I was going to ask for just
such a firewall recommendation. Any other comments/suggestions/etc
regarding choosing a firewall?

> This have so far not affected Thunderbird or Firefox where e.g. PayPal
> still works fine (using "double authentication" including a confirmation
> key sent to my phone etc).
> Following your suggestion I have added "PermitRootLogin no" to
> sshd_config (probably meaning Firefox only will work from my user
> account - which is great!) - thanks again :)

--
John Forkosh ( mailto: j...@f.com where j=john and f=forkosh )

[Chris Vine]

On Wed, 13 Jan 2021 07:07:27 -0000 (UTC)
Henrik Carlqvist <Henrik.C...@deadspam.com> wrote:
[snip]

> An unprotected Slackware machine with ssh open to internet will get
> broken in to with root access within minutes, hours or days by brute
> force depending upon the strength of the password. It is a rather good
> idea to add the line "PermitRootLogin no" to /etc/ssh/sshd_config.

Even better would be for slackware not to run sshd by default. I have
never understood slackware's choice of starting sshd by default on a
standard install: it seems to me to show a surprising lack of concern
for inexperienced users. Experienced users will know how to get sshd
to start (namely by making the relevant script in /etc/rc.d executable).

[Chris Vine]

I let them hammer away on port 22, knowing that they are going to
fail. I have set sshd_config to reject any password or
challenge-response login, my keys are ed25519 encrypted and I rate
limit connection attempts to 3 per 2 minutes. It would take longer
than the heat death of the universe to crack the keys at that rate.

I just let would-be attackers waste their cycles on a hopeless target.
I get about 50 intrusion attempts per hour.

[Jim Diamond]

On 2021-01-14 at 20:29 AST, Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
> On Wed, 13 Jan 2021 07:07:27 -0000 (UTC)
> Henrik Carlqvist <Henrik.C...@deadspam.com> wrote:
> [snip]
>> An unprotected Slackware machine with ssh open to internet will get
>> broken in to with root access within minutes, hours or days by brute
>> force depending upon the strength of the password. It is a rather good
>> idea to add the line "PermitRootLogin no" to /etc/ssh/sshd_config.

On my system (14.2) the default sshd config had
PermitRootLogin prohibit-password
which, I presume, means that root can't login using a password. If
I'm right, than the attackers can attack for as long as they want,
regardless of the strength of the password.

I think your prediction of a machine being broken into within days is
ludicrous, unless the user has gone out of their way to make it easy
for attackers. And if some user is going to do that, they get what
they ask for.

> Even better would be for slackware not to run sshd by default. I have
> never understood slackware's choice of starting sshd by default on a
> standard install: it seems to me to show a surprising lack of concern
> for inexperienced users. Experienced users will know how to get sshd
> to start (namely by making the relevant script in /etc/rc.d executable).

Don't inexperienced users run n00buntu or something similar?

I'm only being partially facetious. I don't doubt you can find some
inexperienced people running slackware on a machine which is open to
the internet, but I'd guess that such people are rare. Anyone running
a system at home is probably (almost certainly) behind a NAT wifi
router, and the routers I've seen (while not being a statistically
significant percentage of all routers) do not forward ssh by default.
Thus a n00b would have to figure out how to do that, which may promote
him/her from n00b to "slightly knowledgeable". In any case, given the
default setup for sshd_config, I'm not sure I see the danger. My
computers which are open to the world used to get a lot of attempts, but
anyone trying to guess root's password was in for a disappointment,
since password login was disabled for root.

Cheers.
Jim

[bad sector]

I would never suggest that it isn't, actually I would
farm-out/privatize their punishment to Mexico
where they would get a container in the sun and
maybe a dead iguana a week and that only because
I'm a christian :)

The thing is, how do you CATCH them? And what if
you do catch one that you cannot (legally) touch?
There are like 200 countries on the planet.

I'm really no expert but even to me working-from-home
sounds awful scary if connected to a corporate server.
Will deterrents EVER work, or will preclusion?

[Chris Vine]

On Thu, 14 Jan 2021 22:03:51 -0400
Jim Diamond <Jim.D...@deletethis.AcadiaU.ca> wrote:
> On 2021-01-14 at 20:29 AST, Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
> > On Wed, 13 Jan 2021 07:07:27 -0000 (UTC)
> > Henrik Carlqvist <Henrik.C...@deadspam.com> wrote:
> > [snip]
> >> An unprotected Slackware machine with ssh open to internet will get
> >> broken in to with root access within minutes, hours or days by brute
> >> force depending upon the strength of the password. It is a rather good
> >> idea to add the line "PermitRootLogin no" to /etc/ssh/sshd_config.
>
> On my system (14.2) the default sshd config had
> PermitRootLogin prohibit-password
> which, I presume, means that root can't login using a password. If
> I'm right, than the attackers can attack for as long as they want,
> regardless of the strength of the password.

That's fine if you are OK with an attacker getting into your user
account. I'm not.

> I think your prediction of a machine being broken into within days is
> ludicrous, unless the user has gone out of their way to make it easy
> for attackers. And if some user is going to do that, they get what
> they ask for.

First, you have your attributions wrong. Secondly, presumably the
poster concerned considered that natural words as passwords will
eventually fall victim to a dictionary attach, which they will.
Thirdly, your "get what they ask for" attitude might be OK if the
inexperienced user had chosen to start sshd, but not where sshd is
started by default.

> > Even better would be for slackware not to run sshd by default. I have
> > never understood slackware's choice of starting sshd by default on a
> > standard install: it seems to me to show a surprising lack of concern
> > for inexperienced users. Experienced users will know how to get sshd
> > to start (namely by making the relevant script in /etc/rc.d executable).
>
> Don't inexperienced users run n00buntu or something similar?
>
> I'm only being partially facetious. I don't doubt you can find some
> inexperienced people running slackware on a machine which is open to
> the internet, but I'd guess that such people are rare. Anyone running
> a system at home is probably (almost certainly) behind a NAT wifi
> router, and the routers I've seen (while not being a statistically
> significant percentage of all routers) do not forward ssh by default.

NAT'ing is ubiquitous with IPv4 and where in operation does offer a
defence to attempts to get into port 22 left open by default. But
NAT'ing is rare with IPv6. Most IPv6 routers have a firewall available
of course, but you have to be clueful enough to turn it on.

In my opinion, it is very poor practice for slackware to start sshd (or
any other daemon with a socket not bound to localhost) by default.
This is fairly basic stuff.

[Henrik Carlqvist]

On Fri, 15 Jan 2021 00:38:37 +0000, Chris Vine wrote:
> I let them hammer away on port 22, knowing that they are going to fail.

> I just let would-be attackers waste their cycles on a hopeless target.
> I get about 50 intrusion attempts per hour.

Interesting, even though I moved to port 2222 and blacklist addresses
which has failed to many times I still get more intrusion attempts than
you get.

11/1 I got 2793 attempts, an average of 116 attempts per hour
12/1 I got 2167 attempts, an average of 90 attempts per hour
13/1 I got 1900 attempts, an average of 79 attempts per hour
14/1 I got 2417 attempts, an average of 100 attempts per hour

So even though I have my ssh server on a non standard port and blacklist
IP addresses with too many failures I get about twice as many attempts as
you get.

The above are average numbers, today Between 18:00 and 18:59 I had 150
attepmts.

regards Henrik

[Henrik Carlqvist]

On Thu, 14 Jan 2021 22:03:51 -0400, Jim Diamond wrote:
> On my system (14.2) the default sshd config had
> PermitRootLogin prohibit-password
> which, I presume, means that root can't login using a password. If I'm
> right, than the attackers can attack for as long as they want,
> regardless of the strength of the password.

Yes, that is right, at least the root account will be secured.

> I think your prediction of a machine being broken into within days is
> ludicrous, unless the user has gone out of their way to make it easy for
> attackers. And if some user is going to do that, they get what they ask
> for.

I have seen a Slackware machine configured for a small internal network
as a toy used by many people for different unimportant purposes. That
machine only had a single user-account shared by all those people and if
I remember right that account did not even have a password. The root
password was also very short and easy to remember for all those people.
The root password was not "slac", but it was about that easy. In
sshd_config PermitRootLogin had been changed to yes and a lot of nice-to-
have services like rwhod, snmpd and lldp was running on the machine.

One day someone connected that machine to a new network connection and
that network connection had a dhcp server which gave the machine a public
IP address on internet. It took about half an hour until the machine was
compromised and the log files was cleaned up in an attempt to hide the
fact that it had been compromised. The only trace in the log files of the
intrusion was when sshd closed the connection to that IP address, the
successful connection and all failed attempts from that IP address had
been cleaned out.

The funny thing here was that the user account without any password was
more secure than the root account. Not only because you would have to
guess the rather easy to guess name of the user account, but mostly
because ssh was configured not to allow login if the password was empty.

The disk on the machine was wiped, OS was reinstalled and it got an
rc.firewall and PermitRootLogin was set to no. If that machine would have
had an UEFI bios I would suggest that the entire machine should get
ditched.

regards Henrik

[Chris Vine]

I rate limit to 3 connection attempts every 2 minutes for any one
address, with an iptables/ip6tables hitcount rule. If you try more than
that it is just dropped rather than logged. That is probably the
reason for the difference.

[Chris Vine]

On Fri, 15 Jan 2021 19:23:50 -0000 (UTC)
Henrik Carlqvist <Henrik.C...@deadspam.com> wrote:
> On Thu, 14 Jan 2021 22:03:51 -0400, Jim Diamond wrote:
> > On my system (14.2) the default sshd config had
> > PermitRootLogin prohibit-password
> > which, I presume, means that root can't login using a password. If I'm
> > right, than the attackers can attack for as long as they want,
> > regardless of the strength of the password.
>
> Yes, that is right, at least the root account will be secured.

Not necessarily. If you have cracked a user account with a dictionary
attack (which requires a dictionary attack on both the user name and
the password) you are most of the way there. For single user computers
often the root account has the same password as the single user, but
even where it doesn't once you have got into a user account it is
trivial to try the obvious ones on the root account with su or a
cracker-installed equivalent. Leaving that aside (i) cracking a user
account allows you to monitor much of what the user does on the
machine, as well as read her unencrypted files, and (ii) there may be
other known vulnerabilies on the host machine which can be exploited.

This must be fertile ground for the nasties who do this kind of thing,
because a lot more than half of the intrusion attempts on my machine
are for a non-root account.

[Per Christensen]

All this is not basic stuff for me, where my "noob secure Slackware
14.2" setup now is with Alien Bobs "rc.firewall" and the "X-nolisten
tcp" script installed and these 12 services activated:

acpid (power management)
cpufreq (balance cpu use)
cups (printer and scanner)
firewall (Alien Bobs script)
networkmanager
ntpd - time and date
syslog - logging
fuse (user can mount external USB and HDD)
udev - system device manager
consolekit (user can shutdown, reboot etc)
messagebus
wireless

Things work with this - printer, scanner, USB, Firefox, Thunderbird are
OK without problems using Dropbox, Paypal, Yahoo, G-mail, Google photos etc.

openssh, telnet, mariadb and apr (apache portable runtime) has been
uninstalled (my own idea). The wi-fi router's IPv4 SPI firewall and DoS
protection is set to on. Seen with my eyes this setup is relatively
secure, but you newer know :(

[Henrik Carlqvist]

On Sat, 16 Jan 2021 02:56:31 +0100, Per Christensen wrote:
> my "noob secure Slackware 14.2" setup now is with Alien Bobs
> "rc.firewall" and the "X-nolisten tcp" script installed and these 12
> services activated:
>
> acpid (power management)
> cpufreq (balance cpu use)
> cups (printer and scanner)
> firewall (Alien Bobs script)
> networkmanager
> ntpd - time and date
> syslog - logging
> fuse (user can mount external USB and HDD)
> udev - system device manager consolekit (user can shutdown, reboot etc)
> messagebus wireless
>
> Things work with this - printer, scanner, USB, Firefox, Thunderbird are
> OK without problems using Dropbox, Paypal, Yahoo, G-mail, Google photos
> etc.
>
> openssh, telnet, mariadb and apr (apache portable runtime) has been
> uninstalled (my own idea). The wi-fi router's IPv4 SPI firewall and DoS
> protection is set to on. Seen with my eyes this setup is relatively
> secure, but you newer know :(

I would agree that the above selection of "services" should be rather
secure against remote attacks as the only activated "service" above which
might allow some kind of network connection is syslog and by defualt in
Slackware it does not allow incoming network connections. And, again,
even if it would it would still be protected by the firewall.

Still however, I would recomend to keep the system up-to-date by
installing the new security patches published in the patches directory of
your favorite mirror. As you now have made an active choice not to
install some packages you might want to keep that choice by avoiding
those patches when they get updated.

regards Henrik

[Henrik Carlqvist]

On Fri, 15 Jan 2021 23:55:21 +0000, Chris Vine wrote:

> On Fri, 15 Jan 2021 19:23:50 -0000 (UTC)
> Henrik Carlqvist <Henrik.C...@deadspam.com> wrote:

>> On Thu, 14 Jan 2021 22:03:51 -0400, Jim Diamond wrote:
>> > On my system (14.2) the default sshd config had
>> > PermitRootLogin prohibit-password
>> > which, I presume, means that root can't login using a password. If
>> > I'm right, than the attackers can attack for as long as they want,
>> > regardless of the strength of the password.
>>
>> Yes, that is right, at least the root account will be secured.
>
> Not necessarily. If you have cracked a user account with a dictionary
> attack (which requires a dictionary attack on both the user name and the
> password) you are most of the way there.

Yes, that is also true, once someone or something passes into an ordinary
account it might be possible to continue to gain root level access by
some ways.

regards Henrik

[Per Christensen]

Thank you for feed back, Henrik, I now feel confident with this
Slackware set-up.And by the way - also thanks to the people (whoever
they are) who frequently patch the kernel and update packages for
download via the slackpkg system.
As a hobbyist I've have been in and out of Slackware for many years,
where I especially windows managers have evolved a lot over time.It is
still very satisfying for me to explore this deep system and i adore the
navy blue background of Midnight Commander ( as root ;( ).
IMHO the only place where 14.2 show its age is in its support of
Python.According to my son this the programming language of today where
Python above ver. 3.5 break things for me. Thank you again for help

[John McCue]

Per Christensen <orm...@gmail.com> wrote:
> I myself is educated in and work in fields far away from IT and have no
> idea how these "ransomware" find their way into the systems.

One of the best things to do use to use Alienbob's iptable generator.
That will create an rc.firewall for you.

http://www.slackware.com/~alien/efg/

For ransomware, I doubt an individual running Slackware
has to worry about that. Ransomeware people are looking
for a big payout and would guess they figure most people
running Linux at home keeps decent backups :)

> Thoughts are: Due to the pandemic many now work from a "home office",
> perhaps often mainly constituting of a new Windows 10 laptop coming with
> the Edge (Chrome based) browser. One could guess there is a link between
> ransomware being on the rise and the relative new concept of "home office".

Possible, but most companies provide their employees with
a workstation with a VPN, also I never do personal things
on their equipment. That provides me CYA. Plus at home
I have my own Slackware system for personal use :)

> And when using a maintained and regularly updated Slackware 14.2 the big
> question is - is a basic Linux home office system these days (e.g with
> telnet, database, web-server uninstalled etc.) and running Firefox and
> Thunderbird as secure as, or perhaps even to prefer over other operating
> systems when "working from home"?

The usual applies, be weary of attachments and Web Sites.
For Firefox I use noscript, but there are many other good
plugins too.

John

[Jim Diamond]

On 2021-01-15 at 05:56 AST, Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
> On Thu, 14 Jan 2021 22:03:51 -0400
> Jim Diamond <Jim.D...@deletethis.AcadiaU.ca> wrote:
>> On 2021-01-14 at 20:29 AST, Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
>> > On Wed, 13 Jan 2021 07:07:27 -0000 (UTC)
>> > Henrik Carlqvist <Henrik.C...@deadspam.com> wrote:
>> > [snip]
>> >> An unprotected Slackware machine with ssh open to internet will get
>> >> broken in to with root access within minutes, hours or days by brute
>> >> force depending upon the strength of the password. It is a rather good
>> >> idea to add the line "PermitRootLogin no" to /etc/ssh/sshd_config.

>> On my system (14.2) the default sshd config had
>> PermitRootLogin prohibit-password
>> which, I presume, means that root can't login using a password. If
>> I'm right, than the attackers can attack for as long as they want,
>> regardless of the strength of the password.

> That's fine if you are OK with an attacker getting into your user
> account. I'm not.

I was talking about attackers trying to get into root, not a user account.
Read closely and you will see "Root" in the middle of "PermitRootLogin".

Or are you suggesting that by making that "PermitRootLogin ..."
setting user accounts on a system are suddenly easily broken into?

>> I think your prediction of a machine being broken into within days is
>> ludicrous, unless the user has gone out of their way to make it easy
>> for attackers. And if some user is going to do that, they get what
>> they ask for.
>
> First, you have your attributions wrong.

I do not. You are not reading correctly. My comment followed text
with two levels of quoting (now four in this message), which indicated
I was replying to something Henrik said.

> Secondly, presumably the poster concerned considered that natural
> words as passwords will eventually fall victim to a dictionary
> attach, which they will.

Perhaps that is what he considered. But that isn't what he said. And
unless the root password is a word very near the start of a
dictionary, I doubt "minutes" would do.

> Thirdly, your "get what they ask for" attitude might be OK if the
> inexperienced user had chosen to start sshd, but not where sshd is
> started by default.

So given that the root account doesn't allow password login by
default, are you suggesting that the attacker will not only guess the
user's password, but also their userid? That is a much tougher problem.

I've watched the logs to see what userids are attacked on my systems.
Not surprisingly, "root" is a common choice of userid, but the userid
guesses I've seen have been things like "ftp" and "guest". I'm sure
some attacker out there is busily trying to guess login names of
systems they are attacking, but I haven't seen any interesting choices
in my logs.

> In my opinion, it is very poor practice for slackware to start sshd (or
> any other daemon with a socket not bound to localhost) by default.
> This is fairly basic stuff.

Perhaps you should try to convince Pat V of his (alleged) poor
practices. I don't think he reads this newsgroup.

Jim

[Jim Diamond]

That is an interesting case study, but there was a machine which people
essentially set up to be easy to break into. Heck, maybe it was one of the
users who broke in and did some log cleaning as a "learning
experience". But in any case, it really doesn't seem to have much to
do with sshd being turned on my default in Slackware.

Cheers.
Jim

[Jim Diamond]

You are apparently a popular guy. On a system I have behind a NAT
router these are all of the attacks for non-root users in the last 24
hours (count, info):

1 Invalid user abc from 138.197.138.41
1 Invalid user admin from 138.197.138.41
1 Invalid user ai from 138.197.138.41
1 Invalid user centos from 138.197.138.41
1 Invalid user cl from 138.197.138.41
1 Invalid user cwl from 138.197.138.41
1 Invalid user dasusr1 from 138.197.138.41
1 Invalid user dbc from 138.197.138.41
1 Invalid user develop from 138.197.138.41
1 Invalid user docker from 138.197.138.41
1 Invalid user elasticsearch from 138.197.138.41
2 Invalid user es from 138.197.138.41
1 Invalid user fsgy from 138.197.138.41
1 Invalid user gfy from 138.197.138.41
1 Invalid user git from 138.197.138.41
2 Invalid user gpu from 138.197.138.41
1 Invalid user grid from 138.197.138.41
2 Invalid user hadoop from 138.197.138.41
1 Invalid user hechunyu from 138.197.138.41
1 Invalid user hy from 138.197.138.41
1 Invalid user hyh from 138.197.138.41
1 Invalid user jangmin from 138.197.138.41
1 Invalid user jtang from 138.197.138.41
1 Invalid user kafka from 138.197.138.41
3 Invalid user lfy from 138.197.138.41
1 Invalid user liu from 138.197.138.41
1 Invalid user liuhui from 138.197.138.41
1 Invalid user lsh from 138.197.138.41
1 Invalid user lu from 138.197.138.41
1 Invalid user lynn from 138.197.138.41
1 Invalid user lzh from 138.197.138.41
2 Invalid user nginx from 138.197.138.41
13 Invalid user nvidia from 138.197.138.41
1 Invalid user open from 138.197.138.41
1 Invalid user oracle from 138.197.138.41
1 Invalid user psh from 138.197.138.41
1 Invalid user qilei from 138.197.138.41
2 Invalid user qym from 138.197.138.41
2 Invalid user roo from 138.197.138.41
1 Invalid user sugon from 138.197.138.41
1 Invalid user team2 from 138.197.138.41
1 Invalid user tmax from 138.197.138.41
1 Invalid user tzq from 138.197.138.41
3 Invalid user ubuntu from 138.197.138.41
1 Invalid user user from 138.197.138.41
1 Invalid user user1 from 138.197.138.41
1 Invalid user user4 from 138.197.138.41
1 Invalid user user7 from 138.197.138.41
1 Invalid user wangtao from 138.197.138.41
1 Invalid user wangting from 138.197.138.41
1 Invalid user wangwei from 138.197.138.41
2 Invalid user weblogic from 138.197.138.41
1 Invalid user wh from 138.197.138.41
1 Invalid user ws from 138.197.138.41
1 Invalid user wtian from 138.197.138.41
1 Invalid user wxy from 138.197.138.41
1 Invalid user yh from 138.197.138.41
1 Invalid user zhangnan from 138.197.138.41
1 Invalid user zhengrc from 138.197.138.41
1 Invalid user zwl from 138.197.138.41

Apparently only one attacker (or group of attackers at the same IP)
were going after me. The attack only lasted a few seconds, and then
they were gone.

I was intrigued by the percentage of Chinese names. Henrik, if you
read this far, do you also see that?

Cheers.
Jim

[Chris Vine]

On Mon, 18 Jan 2021 10:46:34 -0400

Jim Diamond <Jim.D...@deletethis.AcadiaU.ca> wrote:
> On 2021-01-15 at 05:56 AST, Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
> > On Thu, 14 Jan 2021 22:03:51 -0400
> > Jim Diamond <Jim.D...@deletethis.AcadiaU.ca> wrote:
> >> On 2021-01-14 at 20:29 AST, Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
> >> > On Wed, 13 Jan 2021 07:07:27 -0000 (UTC)
> >> > Henrik Carlqvist <Henrik.C...@deadspam.com> wrote:
> >> > [snip]
> >> >> An unprotected Slackware machine with ssh open to internet will get
> >> >> broken in to with root access within minutes, hours or days by brute
> >> >> force depending upon the strength of the password. It is a rather good
> >> >> idea to add the line "PermitRootLogin no" to /etc/ssh/sshd_config.
>
> >> On my system (14.2) the default sshd config had
> >> PermitRootLogin prohibit-password
> >> which, I presume, means that root can't login using a password. If
> >> I'm right, than the attackers can attack for as long as they want,
> >> regardless of the strength of the password.
>
> > That's fine if you are OK with an attacker getting into your user
> > account. I'm not.
>
> I was talking about attackers trying to get into root, not a user account.
> Read closely and you will see "Root" in the middle of "PermitRootLogin".

I fully understand what you were talking about. You are missing the
point. Try reading my post again.

> Or are you suggesting that by making that "PermitRootLogin ..."
> setting user accounts on a system are suddenly easily broken into?

Of course not. You are missing the point.

> >> I think your prediction of a machine being broken into within days is
> >> ludicrous, unless the user has gone out of their way to make it easy
> >> for attackers. And if some user is going to do that, they get what
> >> they ask for.
> >
> > First, you have your attributions wrong.
>
> I do not. You are not reading correctly. My comment followed text
> with two levels of quoting (now four in this message), which indicated
> I was replying to something Henrik said.

Nope. You said in response to me that "I think your prediction ...".
You have your attributions wrong - it wasn't me who made the prediction
to which you refer

> > Secondly, presumably the poster concerned considered that natural
> > words as passwords will eventually fall victim to a dictionary
> > attach, which they will.
>
> Perhaps that is what he considered. But that isn't what he said. And
> unless the root password is a word very near the start of a
> dictionary, I doubt "minutes" would do.

This is the same problem with your attributions. I didn't say "minutes"
would do. I said such passwords "will eventually fall victim to a
dictionary attach (sic)".

> > Thirdly, your "get what they ask for" attitude might be OK if the
> > inexperienced user had chosen to start sshd, but not where sshd is
> > started by default.
>
> So given that the root account doesn't allow password login by
> default, are you suggesting that the attacker will not only guess the
> user's password, but also their userid? That is a much tougher problem.

Yes that is what I was suggesting. Attackers routinely go through
lists (dictionaries) of user names.

[Henrik Carlqvist]

On Mon, 18 Jan 2021 11:20:24 -0400, Jim Diamond wrote:
> I was intrigued by the percentage of Chinese names. Henrik, if you read
> this far, do you also see that?

Among the attemmpts of attacks with random user names I do see some
chinese names, but I wouldn't say it is a very high percentage:

Jan 19 00:02:55 igor sshd[19900]: Invalid user nginx from 151.80.61.249
Jan 19 00:03:23 igor sshd[19902]: Invalid user uno8 from 34.93.177.66
Jan 19 00:03:55 igor sshd[19906]: Invalid user chen from 178.128.21.180
Jan 19 00:04:06 igor sshd[19908]: Invalid user weblogic from 37.187.102.31
Jan 19 00:04:18 igor sshd[19910]: Invalid user postgres from 111.67.201.7
Jan 19 00:04:56 igor sshd[19914]: Invalid user markus from 187.1.81.161
Jan 19 00:05:23 igor sshd[19916]: Invalid user voip from 79.172.79.219
Jan 19 00:05:28 igor sshd[19918]: Invalid user hadoop from 176.53.180.124
Jan 19 00:06:27 igor sshd[19920]: Invalid user ubuntu from 111.67.201.7
Jan 19 00:06:29 igor sshd[19922]: Invalid user bot from 34.93.177.66
Jan 19 00:06:35 igor sshd[19924]: Invalid user ftp-user from
178.128.21.180
Jan 19 00:06:57 igor sshd[19926]: Invalid user zhou from 176.53.180.124
Jan 19 00:07:36 igor sshd[19928]: Invalid user ana from 139.155.34.181
Jan 19 00:07:41 igor sshd[19930]: Invalid user sysadmin from 187.1.81.161
Jan 19 00:08:20 igor sshd[19932]: Invalid user amsftp from 79.172.79.219
Jan 19 00:08:28 igor sshd[19934]: Invalid user oscar from 176.53.180.124
Jan 19 00:08:55 igor sshd[19938]: Invalid user anthony from 37.187.102.31
Jan 19 00:09:22 igor sshd[19942]: Invalid user test from 178.128.21.180
Jan 19 00:09:26 igor sshd[19940]: Invalid user hero from 134.209.117.181
Jan 19 00:09:33 igor sshd[19944]: Invalid user ftp from 34.93.177.66
Jan 19 00:10:01 igor sshd[19946]: Invalid user monitoring from
176.53.180.124
Jan 19 00:10:27 igor sshd[19948]: Invalid user zabbix from 187.1.81.161
Jan 19 00:10:46 igor sshd[19950]: Invalid user mysql from 111.67.201.7
Jan 19 00:11:06 igor sshd[19952]: Invalid user vnc from 79.172.79.219
Jan 19 00:11:16 igor sshd[19954]: Invalid user user from 139.155.34.181
Jan 19 00:11:55 igor sshd[19958]: Invalid user cloud from 37.187.102.31
Jan 19 00:12:36 igor sshd[19962]: Invalid user ftp from 34.93.177.66
Jan 19 00:12:58 igor sshd[19964]: Invalid user scpuser from 111.67.201.7
Jan 19 00:13:11 igor sshd[19968]: Invalid user user2 from 187.1.81.161
Jan 19 00:13:48 igor sshd[19970]: Invalid user tsbot from 79.172.79.219
Jan 19 00:14:45 igor sshd[19976]: Invalid user ubuntu from 37.187.102.31
Jan 19 00:14:52 igor sshd[19978]: Invalid user testuser1 from
139.155.34.181
Jan 19 00:14:54 igor sshd[19980]: Invalid user asecruc from 178.128.21.180
Jan 19 00:15:10 igor sshd[19982]: Invalid user sonar from 111.67.201.7
Jan 19 00:15:40 igor sshd[19984]: Invalid user sansforensics from
34.93.177.66
Jan 19 00:16:21 igor sshd[19988]: Invalid user ubuntu from 176.53.180.124
Jan 19 00:16:41 igor sshd[19990]: Invalid user tom from 79.172.79.219

The fact that the attacker attempts with chinese names is probably
because there are many unsecure chinese computers out there. Many of the
attacks come from chinese IP addresses and also much email spam comes
from chinese IP addresses.

regards Henrik

[#Paul]

Henrik Carlqvist <Henrik.C...@deadspam.com> wrote:
> On Fri, 15 Jan 2021 00:38:37 +0000, Chris Vine wrote:
>> I let them hammer away on port 22, knowing that they are going to fail.
>
>> I just let would-be attackers waste their cycles on a hopeless target.
>> I get about 50 intrusion attempts per hour.
>
> Interesting, even though I moved to port 2222 and blacklist addresses
> which has failed to many times I still get more intrusion attempts than
> you get.

> [...]

Perhaps 2222 is an "obvious" alternative ssh port number, and so
often scanned as well as the standard 22. I use a randomish port
number, and get hardly any scanning.

#Paul

[Jim Diamond]

I read your post again. I pointed out that the default config doesn't
permit logins to root with a password and you said that's fine if I'm
OK with someone getting in to my user account. Try to stay on
point... I was responding to Henrik's comment about root being broken
into, not about user accounts.

>> Or are you suggesting that by making that "PermitRootLogin ..."
>> setting user accounts on a system are suddenly easily broken into?
>
> Of course not. You are missing the point.

Maybe. But I think it is you who is not following this particular
part of the conversation: it is about whether the root account will be
compromised via ssh.

>> >> I think your prediction of a machine being broken into within days is
>> >> ludicrous, unless the user has gone out of their way to make it easy
>> >> for attackers. And if some user is going to do that, they get what
>> >> they ask for.
>> >
>> > First, you have your attributions wrong.
>>
>> I do not. You are not reading correctly. My comment followed text
>> with two levels of quoting (now four in this message), which indicated
>> I was replying to something Henrik said.

> Nope. You said in response to me
> that "I think your prediction ...". You have your attributions
> wrong - it wasn't me who made the prediction to which you refer

I think you are having reading problems. I clearly said that ("I
think your prediction...") in response to Henrik's comment, as is
indicated right above. Look up and you will see (now with six '>'s)
Henrik's text. Then, right below that, I say "On my system..." (now
with four '>'s). That was replying to Henrik, as the attribution
information at the very top of this article shows. Are you thinking
that everything in a reply to your article must be a reply to you? If
you are thinking that, you are wrong. Is your newsreader hiding or
mangling the presentation of the quoted material? If so, perhaps you
should fix that, or at least take that into account when reading
postings.

>> > Secondly, presumably the poster concerned considered that natural
>> > words as passwords will eventually fall victim to a dictionary
>> > attach, which they will.
>>
>> Perhaps that is what he considered. But that isn't what he said. And
>> unless the root password is a word very near the start of a
>> dictionary, I doubt "minutes" would do.
>
> This is the same problem with your attributions. I didn't say "minutes"
> would do.

No, but the person to whom that part of my reply was directed did.

> I said such passwords "will eventually fall victim to a dictionary
> attach (sic)".

>> > Thirdly, your "get what they ask for" attitude might be OK if the
>> > inexperienced user had chosen to start sshd, but not where sshd is
>> > started by default.
>>
>> So given that the root account doesn't allow password login by
>> default, are you suggesting that the attacker will not only guess the
>> user's password, but also their userid? That is a much tougher problem.
>
> Yes that is what I was suggesting. Attackers routinely go through
> lists (dictionaries) of user names.

And if an attacker is randomly guessing user names, as well as
passwords, they have a big job in front of them, unless someone has no
password and they try that. But loggind in via ssh with no password
also seems to be disallowed by default in Slackware 14.2.

Jim

[Jim Diamond]

On 2021-01-19 at 02:40 AST, Henrik Carlqvist <Henrik.C...@deadspam.com> wrote:
> On Mon, 18 Jan 2021 11:20:24 -0400, Jim Diamond wrote:
>> I was intrigued by the percentage of Chinese names. Henrik, if you read
>> this far, do you also see that?
>
> Among the attemmpts of attacks with random user names I do see some
> chinese names, but I wouldn't say it is a very high percentage:
>
> Jan 19 00:02:55 igor sshd[19900]: Invalid user nginx from 151.80.61.249
> Jan 19 00:03:23 igor sshd[19902]: Invalid user uno8 from 34.93.177.66
> Jan 19 00:03:55 igor sshd[19906]: Invalid user chen from 178.128.21.180

<snip>

Thanks. By the way, have you considered using fail2ban? (Or are you
using it already, and you are still getting lots of attacks?)

My logs indicate no attacks in the last day. I'm not sure whether I
should be worried about that or not.

Jim

[Henrik Carlqvist]

On Wed, 20 Jan 2021 13:50:15 -0400, Jim Diamond wrote:
> Thanks. By the way, have you considered using fail2ban? (Or are you
> using it already, and you are still getting lots of attacks?)

At some point I did look at fail2ban, but that was after I had
implemented my home grown solution which basically does the same. At that
point I saw no reason to replace my own solution.

regards Henrik

[Henrik Carlqvist]

On Tue, 19 Jan 2021 19:23:49 +0000, #Paul wrote:
> Perhaps 2222 is an "obvious" alternative ssh port number, and so often
> scanned as well as the standard 22.

So it could be.

regards Henrik

[Chris Vine]

On Wed, 20 Jan 2021 13:40:10 -0400
Jim Diamond <Jim.D...@deletethis.AcadiaU.ca> wrote:
[snip]

> I read your post again. I pointed out that the default config doesn't
> permit logins to root with a password and you said that's fine if I'm
> OK with someone getting in to my user account. Try to stay on
> point... I was responding to Henrik's comment about root being broken
> into, not about user accounts.

This is really hard work. The point I was making was that protecting
the root account is not enough. You need to protect user accounts from
dictionary attacks on passwords which are natural words also.

[snip]

> I think you are having reading problems. I clearly said that ("I
> think your prediction...") in response to Henrik's comment, as is
> indicated right above. Look up and you will see (now with six '>'s)
> Henrik's text. Then, right below that, I say "On my system..." (now
> with four '>'s). That was replying to Henrik, as the attribution
> information at the very top of this article shows. Are you thinking
> that everything in a reply to your article must be a reply to you? If
> you are thinking that, you are wrong. Is your newsreader hiding or
> mangling the presentation of the quoted material? If so, perhaps you
> should fix that, or at least take that into account when reading
> postings.

That's not how it works. If you reply to someone's post with "your
prediction ..." then as a matter of common English you are referring to
the person to whom you are replying. If you meant someone else you
should have said so.

> And if an attacker is randomly guessing user names, as well as
> passwords, they have a big job in front of them, unless someone has no
> password and they try that. But loggind in via ssh with no password
> also seems to be disallowed by default in Slackware 14.2.

They do have a big job but the problem is that a sole user on a
particular computer might reasonably assume on setting a password for
their account on a fresh install of slackware that, as they are sole
user, they don't need to be careful about choosing these. They may
reasonably assume that port 22 is not open to the world. If so, they
are likely to be disabused in due course if it is open. Opening up port
22 should not be a default.

A strong password is difficult for users to remember. For simplicity I
have a not particularly strong password for the sole account on the
laptop which only I use. That's fine because I do not intend the
password to guard against physical loss of the laptop (any critical
stuff is encrypted), and the only way of ssh'ing into the machine is
via a ed25519 key.

[John Forkosh]

John Forkosh <for...@panix.com> wrote:
> Per Christensen <orm...@gmail.com> wrote:
<<snip>>
>> Personally I try to follow the recommendations given at
>> https://docs.slackware.com/howtos:security:basic_security
>> and have therefore copied a "rc.firewall" file generated with Alien Bobs
>> Firewall Generator into /etc/rc.d/ and the recommended "xserverrc" file
>> into /etc/X11/xinit/ and afterwards set both files as executables with
>> the chmod a+x command.
>
> Thanks for that suggestion/info. I was going to ask for just
> such a firewall recommendation. Any other comments/suggestions/etc
> regarding choosing a firewall?

Okay, so I'm now using the firewall script generated by
http://www.slackware.com/~alien/efg/
and it seems to be working okay -- except for one thing.
It seems to be driving xsane insane. Starting up xsane
now emits the error message
Failed to open device 'brother3:bus2;dev1': Invalid argument
But it used to work with my older and simpler firewall script,
given below. And when I reboot and just use that older script,
rather than alienbob's, then xsane starts right up as usual,
and works fine. No other change whatsoever; just which firewall
script I use. So what's going on with alienbob's script that's
giving xsane headaches?

Here's the older/simpler script with which xsane works...

#!/bin/sh
#
# firewall-standalone This script sets up firewall rules for a standalone
# machine
#
# Copyright (C) 2005 Roaring Penguin Software Inc. This software may
# be distributed under the terms of the GNU General Public License, version
# 2 or any later version.
# LIC: GPL

# Interface to Internet
### EXTIF=ppp+
EXTIF=eth+

iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP

iptables -F FORWARD
iptables -F INPUT
iptables -F OUTPUT

# Deny TCP and UDP packets to privileged ports
iptables -A INPUT -p udp -i $EXTIF --dport 0:1023 -j LOG
iptables -A INPUT -p tcp -i $EXTIF --dport 0:1023 -j LOG
iptables -A INPUT -p udp -i $EXTIF --dport 0:1023 -j DROP
iptables -A INPUT -p tcp -i $EXTIF --dport 0:1023 -j DROP

# Deny TCP connection attempts
iptables -A INPUT -i $EXTIF -p tcp --syn -j LOG
iptables -A INPUT -i $EXTIF -p tcp --syn -j DROP

# Deny ICMP echo-requests
iptables -A INPUT -i $EXTIF -p icmp --icmp-type echo-request -j DROP
### end-of-file
--
John Forkosh ( mailto: j...@f.com where j=john and f=forkosh )