2 Mar
2018
2 Mar
'18
11:11 a.m.
Hi,
The level of SSH scanning is getting ridiculous.
Here's some stats on the number of Fail2Ban bans across all Xen
Shell hosts in the last 7 days:
# each ∎ represents a count of 46. total 4653
59.63.166.104 [ 2037] ∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ (43.78%)
58.218.198.142 [ 998] ∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ (21.45%)
59.63.166.105 [ 641] ∎∎∎∎∎∎∎∎∎∎∎∎∎ (13.78%)
58.218.198.146 [ 352] ∎∎∎∎∎∎∎ (7.57%)
58.218.198.161 [ 272] ∎∎∎∎∎ (5.85%)
59.63.188.36 [ 145] ∎∎∎ (3.12%)
192.99.138.37 [ 61] ∎ (1.31%)
103.99.0.188 [ 40] (0.86%)
218.65.30.40 [ 15] (0.32%)
202.104.147.26 [ 13] (0.28%)
42.7.26.15 [ 8] (0.17%)
163.172.229.252 [ 8] (0.17%)
42.7.26.91 [ 8] (0.17%)
198.98.57.188 [ 8] (0.17%)
58.242.83.26 [ 8] (0.17%)
58.242.83.27 [ 8] (0.17%)
182.100.67.82 [ 6] (0.13%)
217.99.228.158 [ 5] (0.11%)
218.65.30.25 [ 4] (0.09%)
117.50.14.83 [ 4] (0.09%)
46.148.21.32 [ 4] (0.09%)
178.62.213.66 [ 3] (0.06%)
116.99.255.111 [ 3] (0.06%)
165.124.176.146 [ 1] (0.02%)
101.226.196.136 [ 1] (0.02%)
First three octets only:
# each ∎ represents a count of 61. total 4653
59.63.166.0/24 [ 2678] ∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ (57.55%)
58.218.198.0/24 [ 1622] ∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ (34.86%)
59.63.188.0/24 [ 145] ∎∎ (3.12%)
192.99.138.0/24 [ 61] ∎ (1.31%)
103.99.0.0/24 [ 40] (0.86%)
218.65.30.0/24 [ 19] (0.41%)
42.7.26.0/24 [ 16] (0.34%)
58.242.83.0/24 [ 16] (0.34%)
202.104.147.0/24 [ 13] (0.28%)
163.172.229.0/24 [ 8] (0.17%)
198.98.57.0/24 [ 8] (0.17%)
182.100.67.0/24 [ 6] (0.13%)
217.99.228.0/24 [ 5] (0.11%)
46.148.21.0/24 [ 4] (0.09%)
117.50.14.0/24 [ 4] (0.09%)
116.99.255.0/24 [ 3] (0.06%)
178.62.213.0/24 [ 3] (0.06%)
165.124.176.0/24 [ 1] (0.02%)
101.226.196.0/24 [ 1] (0.02%)
That is with Fail2Ban adding a 10 minute ban after 10 login
failures. If there was no ban this would be 100s of thousands of
login attempts instead of 4,653 bans.
Yes I can send an abuse report to Chinanet's "Jiangxi telecom
network operation support department". Yes I can just firewall it
off. But that relies on periodic log file auditing.
There is already an SSH listening on port 922 that is not subject to
Fail2Ban. I would rather not have SSH on port 22 at all but in the
past I have been told this would not be acceptable because some
people are sometimes on networks where they can't connect to port
922. If that would be fine with you then no need to comment but it
might be interesting to hear from anyone who would still find this a
problem.
What are the feelings about setting port 22 Xen Shell access to
require SSH public key auth (while leaving 922 to allow password
authentication as well)?
Do those of you who've added SSH keys want an option to *require*
SSH keys even on port 922?
At the very least the Fail2Ban ban time is going to have to go up
from 10 minutes to let's say 6 hours.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
announce mailing list
announce(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/announce
2 Mar
2 Mar
11:26 a.m.
Hi Andy,
Have you considered a multilevel approach with fail2ban? Something
like the link below increases the ban timeout for repeat offenders.
http://blog.shanock.com/fail2ban-increased-ban-times-for-repeat-offenders/
Cheers,
Roger
On 2 March 2018 at 11:11, Andy Smith <andy(a)bitfolk.com> wrote:
Hi,
The level of SSH scanning is getting ridiculous.
Here's some stats on the number of Fail2Ban bans across all Xen
Shell hosts in the last 7 days:
# each ∎ represents a count of 46. total 4653
59.63.166.104 [ 2037] ∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ (43.78%)
58.218.198.142 [ 998] ∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ (21.45%)
59.63.166.105 [ 641] ∎∎∎∎∎∎∎∎∎∎∎∎∎ (13.78%)
58.218.198.146 [ 352] ∎∎∎∎∎∎∎ (7.57%)
58.218.198.161 [ 272] ∎∎∎∎∎ (5.85%)
59.63.188.36 [ 145] ∎∎∎ (3.12%)
192.99.138.37 [ 61] ∎ (1.31%)
103.99.0.188 [ 40] (0.86%)
218.65.30.40 [ 15] (0.32%)
202.104.147.26 [ 13] (0.28%)
42.7.26.15 [ 8] (0.17%)
163.172.229.252 [ 8] (0.17%)
42.7.26.91 [ 8] (0.17%)
198.98.57.188 [ 8] (0.17%)
58.242.83.26 [ 8] (0.17%)
58.242.83.27 [ 8] (0.17%)
182.100.67.82 [ 6] (0.13%)
217.99.228.158 [ 5] (0.11%)
218.65.30.25 [ 4] (0.09%)
117.50.14.83 [ 4] (0.09%)
46.148.21.32 [ 4] (0.09%)
178.62.213.66 [ 3] (0.06%)
116.99.255.111 [ 3] (0.06%)
165.124.176.146 [ 1] (0.02%)
101.226.196.136 [ 1] (0.02%)
First three octets only:
# each ∎ represents a count of 61. total 4653
59.63.166.0/24 [ 2678] ∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ (57.55%)
58.218.198.0/24 [ 1622] ∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ (34.86%)
59.63.188.0/24 [ 145] ∎∎ (3.12%)
192.99.138.0/24 [ 61] ∎ (1.31%)
103.99.0.0/24 [ 40] (0.86%)
218.65.30.0/24 [ 19] (0.41%)
42.7.26.0/24 [ 16] (0.34%)
58.242.83.0/24 [ 16] (0.34%)
202.104.147.0/24 [ 13] (0.28%)
163.172.229.0/24 [ 8] (0.17%)
198.98.57.0/24 [ 8] (0.17%)
182.100.67.0/24 [ 6] (0.13%)
217.99.228.0/24 [ 5] (0.11%)
46.148.21.0/24 [ 4] (0.09%)
117.50.14.0/24 [ 4] (0.09%)
116.99.255.0/24 [ 3] (0.06%)
178.62.213.0/24 [ 3] (0.06%)
165.124.176.0/24 [ 1] (0.02%)
101.226.196.0/24 [ 1] (0.02%)
That is with Fail2Ban adding a 10 minute ban after 10 login
failures. If there was no ban this would be 100s of thousands of
login attempts instead of 4,653 bans.
Yes I can send an abuse report to Chinanet's "Jiangxi telecom
network operation support department". Yes I can just firewall it
off. But that relies on periodic log file auditing.
There is already an SSH listening on port 922 that is not subject to
Fail2Ban. I would rather not have SSH on port 22 at all but in the
past I have been told this would not be acceptable because some
people are sometimes on networks where they can't connect to port
922. If that would be fine with you then no need to comment but it
might be interesting to hear from anyone who would still find this a
problem.
What are the feelings about setting port 22 Xen Shell access to
require SSH public key auth (while leaving 922 to allow password
authentication as well)?
Do those of you who've added SSH keys want an option to *require*
SSH keys even on port 922?
At the very least the Fail2Ban ban time is going to have to go up
from 10 minutes to let's say 6 hours.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
announce mailing list
announce(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/announce
_______________________________________________
users mailing list
users(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/users
11:37 a.m.
On 02/03/2018 11:26, Roger Light wrote:
Hi Andy,
Have you considered a multilevel approach with fail2ban? Something
like the link below increases the ban timeout for repeat offenders.
http://blog.shanock.com/fail2ban-increased-ban-times-for-repeat-offenders/
Also see
https://github.com/fail2ban/fail2ban/blob/master/config/filter.d/recidive.c…
I've included the filter I use (I think I edited it) below which I call
"repeatoffender" in my setup.
Thanks
Gavin
# From
https://github.com/fail2ban/fail2ban/blob/master/config/filter.d/recidive.c…
# Fail2Ban filter for repeat bans
#
# This filter monitors the fail2ban log file, and enables you to add long
# time bans for ip addresses that get banned by fail2ban multiple times.
#
# Reasons to use this: block very persistent attackers for a longer time,
# stop receiving email notifications about the same attacker over and
# over again.
#
# This jail is only useful if you set the 'findtime' and 'bantime'
parameters
# in jail.conf to a higher value than the other jails. Also, this jail
has its
# drawbacks, namely in that it works only with iptables, or if you use a
# different blocking mechanism for this jail versus others (e.g. hostsdeny
# for most jails, and shorewall for this one).
[INCLUDES]
# Read common prefixes. If any customizations available -- read them from
# common.local
before = common.conf
[Definition]
_daemon = fail2ban\.actions\s*
# The name of the jail that this filter is used for. In jail.conf, name the
# jail using this filter 'recidive', or change this line!
_jailname = repeatoffender
failregex = ^(%(__prefix_line)s|
%(_daemon)s%(__pid_re)s?:\s+)NOTICE\s+\[(?!%(_jailname)s\])(?:.*)\]\s+Ban\s+<HOST>\s*$
ignoreregex =
[Init]
journalmatch = _SYSTEMD_UNIT=fail2ban.service PRIORITY=5
# Author: Tom Hendrikx, modifications by Amir Caspi
11:43 a.m.
On 02/03/2018 11:11, Andy Smith wrote:
<snip>
There is already an SSH listening on port 922 that is not subject to
Fail2Ban. I would rather not have SSH on port 22 at all but in the
past I have been told this would not be acceptable because some
people are sometimes on networks where they can't connect to port
922. If that would be fine with you then no need to comment but it
might be interesting to hear from anyone who would still find this a
problem.
What are the feelings about setting port 22 Xen Shell access to
require SSH public key auth (while leaving 922 to allow password
authentication as well)?
My concern is that I may not always have access from a machine with the
SSH key. I wasn't aware of port 922 though, so will try to remember
this if I need it in future. I have experienced networks where trying
to use SSH over any port except 22 (well, any that I'd configured) is
blocked.
Do those of you who've added SSH keys want an
option to *require*
SSH keys even on port 922?
I'd be happy with this. In case of an emergency where I don't have the
SSH key, I presume that I could turn this off and then log in?
At the very least the Fail2Ban ban time is going to
have to go up
from 10 minutes to let's say 6 hours.
This could be a problem for users who genuinely mess up a few password
attempts when trying to sort out what is most likely an urgent issue
(else they would be using their server's own SSH). See Roger's/my other
email about alternative ways to catch repeat offenders - you could add
the 6 hour ban for those that continue to make attempts after X SSH
fail2ban bans.
Thanks
Gavin
11:48 a.m.
On 02/03/2018 11:11, Andy Smith wrote:
Hi,
The level of SSH scanning is getting ridiculous.
Here's some stats on the number of Fail2Ban bans across all Xen
Shell hosts in the last 7 days:
<snip>
Something that you, Andy, and others with a large number of internet
facing servers might be interested in is this article that I just found
about sharing the fail2ban information with your other servers:
https://www.blackhillsinfosec.com/configure-distributed-fail2ban/
I hope that's helpful.
Thanks
Gavin
12:08 p.m.
I travel quite a lot and do not always have access to all my keys. Although
I do not often have to access the Xen shell, it would be very difficult if
both were key only. It makes absolute sense to make port 22 key only, but
if 922 were password as well it would be helpful. I use nonstandard ports
for access to SSH on my VPS and as soon as I changed it I noticed a big
change in my fail2ban logs.
One other thing I have done is to set up ipset, No one should ever attempt
to connect to port 22 on my machines so I have iptables add any that do to
an ipset which is then blocked from any port. But that may not be possible
for the Bitfolk set up
On 2 March 2018 at 19:48, Gavin Westwood <
bitfolk-lists-2015(a)gavinwestwood.uk> wrote:
On 02/03/2018 11:11, Andy Smith wrote:
--
Keith Williams
คืนใดมืดที่สุด จะเห็นดาวชัดที่สุด
Wondrous Thai http://www.wondrousthai.com
FCLT magazine http://issuu.com/fcltmagazine/docs/fclt_september_2014_issue_1
Farang Can Learn Thai www.farangcanlearnthai.com
Keith's Place www.keiths-place.co.uk
Tailor Made English www.tmenglish.org
Hi,
The level of SSH scanning is getting ridiculous.
Here's some stats on the number of Fail2Ban bans across all Xen
Shell hosts in the last 7 days:
<snip>
Something that you, Andy, and others with a large number of internet
facing servers might be interested in is this article that I just found
about sharing the fail2ban information with your other servers:
https://www.blackhillsinfosec.com/configure-distributed-fail2ban/
I hope that's helpful.
Thanks
Gavin
_______________________________________________
users mailing list
users(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/users
1:09 p.m.
I agree with Keith. I would find it problematic if I couldn't have password access to
the Xen shell from time to time to resolve issues. I also use ipset on my VPS which I find
flexible and powerful in keeping unwanted callers out. I'm using port 22 on the VPS
but with key access only.
Richard.
On 2 March 2018 13:08:18 CET, Keith Williams <keithwilliamsnp(a)gmail.com> wrote:
I travel quite a lot and do not always have access to
all my keys.
Although
I do not often have to access the Xen shell, it would be very difficult
if
both were key only. It makes absolute sense to make port 22 key only,
but
if 922 were password as well it would be helpful. I use nonstandard
ports
for access to SSH on my VPS and as soon as I changed it I noticed a big
change in my fail2ban logs.
One other thing I have done is to set up ipset, No one should ever
attempt
to connect to port 22 on my machines so I have iptables add any that do
to
an ipset which is then blocked from any port. But that may not be
possible
for the Bitfolk set up
On 2 March 2018 at 19:48, Gavin Westwood <
bitfolk-lists-2015(a)gavinwestwood.uk> wrote:
On 02/03/2018 11:11, Andy Smith wrote:
found
Hi,
The level of SSH scanning is getting ridiculous.
Here's some stats on the number of Fail2Ban bans across all Xen
Shell hosts in the last 7 days:
<snip>
Something that you, Andy, and others with a large number of internet
facing servers might be interested in is this article that I just about sharing the fail2ban information with your
other servers:
https://www.blackhillsinfosec.com/configure-distributed-fail2ban/
I hope that's helpful.
Thanks
Gavin
_______________________________________________
users mailing list
users(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/users
--
Keith Williams
คืนใดมืดที่สุด จะเห็นดาวชัดที่สุด
Wondrous Thai http://www.wondrousthai.com
FCLT magazine
http://issuu.com/fcltmagazine/docs/fclt_september_2014_issue_1
Farang Can Learn Thai www.farangcanlearnthai.com
Keith's Place www.keiths-place.co.uk
Tailor Made English www.tmenglish.org 
2:38 p.m.
On Fri, 02 Mar 2018 14:09:38 +0100
Richard Glynos <richardmglynos(a)gmail.com> wrote:
I agree with Keith. I would find it problematic if I
couldn't have
password access to the Xen shell from time to time to resolve
issues. I also use ipset on my VPS which I find flexible and powerful
in keeping unwanted callers out. I'm using port 22 on the VPS but
with key access only.
Something I find useful: libpam-google-authenticator. I seem to remember
you're already using Google Authenticator for other things, Andy, so
it probably wouldn't take much extra work to set up.
I've configured SSH on my VPS (and other Internet facing SSH services)
so that if public key authentication is used, I get straight in, but if
password authentication is used then a Google authenticator challenge is
required too.
That way, the authenticator stays out of the way for most usage, but I can
get in from anywhere using my password, so long as I've got my phone handy.
I don't need to worry about SSH brute force attempts against accounts on
my machines and I just let fail2ban do its thing.
Would that help for access to Xen Shell? It's not a very high extra bar for
people to leap over in emergency cases. Just a thought...
Cheers,
Alun.
3:58 p.m.
Hello,
On Fri, Mar 02, 2018 at 02:38:56PM +0000, Alun Jones wrote:
Something I find useful: libpam-google-authenticator.
I seem to remember
you're already using Google Authenticator for other things, Andy, so
it probably wouldn't take much extra work to set up.
This is already available. If you enable two factor auth then it
asks for the Google authenticator code on SSH. Most people don't
configure two factor auth, and many do not want to see it made
mandatory.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
5:53 p.m.
On Fri, 2 Mar 2018 15:58:36 +0000
Andy Smith <andy(a)bitfolk.com> wrote:
I wonder what the feeling is if it's only mandatory for
password-based access, if the choice is between that and
key-only.
Cheers,
Alun.
Something I find useful:
libpam-google-authenticator. I seem to
remember you're already using Google Authenticator for other
things, Andy, so it probably wouldn't take much extra work to set
up.
This is already available. If you enable two factor auth then it
asks for the Google authenticator code on SSH. Most people don't
configure two factor auth, and many do not want to see it made
mandatory. 
12:19 p.m.
I found blocking large network ranges for upto 60 minutes worked well
for my kind of ssh, together with an IP Whitelist of my most common IPs
. Perhaps an agressive fail2ban policy together with a user-maintained
ip whitelist would work well for bitfolk?
On Fri, 2018-03-02 at 11:11 +0000, Andy Smith wrote:
Hi,
The level of SSH scanning is getting ridiculous.
Here's some stats on the number of Fail2Ban bans across all Xen
Shell hosts in the last 7 days:
# each ∎ represents a count of 46. total 4653
59.63.166.104 [ 2037] ∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
(43.78%)
58.218.198.142 [ 998] ∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ (21.45%)
59.63.166.105 [ 641] ∎∎∎∎∎∎∎∎∎∎∎∎∎ (13.78%)
58.218.198.146 [ 352] ∎∎∎∎∎∎∎ (7.57%)
58.218.198.161 [ 272] ∎∎∎∎∎ (5.85%)
59.63.188.36 [ 145] ∎∎∎ (3.12%)
192.99.138.37 [ 61] ∎ (1.31%)
103.99.0.188 [ 40] (0.86%)
218.65.30.40 [ 15] (0.32%)
202.104.147.26 [ 13] (0.28%)
42.7.26.15 [ 8] (0.17%)
163.172.229.252 [ 8] (0.17%)
42.7.26.91 [ 8] (0.17%)
198.98.57.188 [ 8] (0.17%)
58.242.83.26 [ 8] (0.17%)
58.242.83.27 [ 8] (0.17%)
182.100.67.82 [ 6] (0.13%)
217.99.228.158 [ 5] (0.11%)
218.65.30.25 [ 4] (0.09%)
117.50.14.83 [ 4] (0.09%)
46.148.21.32 [ 4] (0.09%)
178.62.213.66 [ 3] (0.06%)
116.99.255.111 [ 3] (0.06%)
165.124.176.146 [ 1] (0.02%)
101.226.196.136 [ 1] (0.02%)
First three octets only:
# each ∎ represents a count of 61. total 4653
59.63.166.0/24 [ 2678] ∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
(57.55%)
58.218.198.0/24 [ 1622] ∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ (34.86%)
59.63.188.0/24 [ 145] ∎∎ (3.12%)
192.99.138.0/24 [ 61] ∎ (1.31%)
103.99.0.0/24 [ 40] (0.86%)
218.65.30.0/24 [ 19] (0.41%)
42.7.26.0/24 [ 16] (0.34%)
58.242.83.0/24 [ 16] (0.34%)
202.104.147.0/24 [ 13] (0.28%)
163.172.229.0/24 [ 8] (0.17%)
198.98.57.0/24 [ 8] (0.17%)
182.100.67.0/24 [ 6] (0.13%)
217.99.228.0/24 [ 5] (0.11%)
46.148.21.0/24 [ 4] (0.09%)
117.50.14.0/24 [ 4] (0.09%)
116.99.255.0/24 [ 3] (0.06%)
178.62.213.0/24 [ 3] (0.06%)
165.124.176.0/24 [ 1] (0.02%)
101.226.196.0/24 [ 1] (0.02%)
That is with Fail2Ban adding a 10 minute ban after 10 login
failures. If there was no ban this would be 100s of thousands of
login attempts instead of 4,653 bans.
Yes I can send an abuse report to Chinanet's "Jiangxi telecom
network operation support department". Yes I can just firewall it
off. But that relies on periodic log file auditing.
There is already an SSH listening on port 922 that is not subject to
Fail2Ban. I would rather not have SSH on port 22 at all but in the
past I have been told this would not be acceptable because some
people are sometimes on networks where they can't connect to port
922. If that would be fine with you then no need to comment but it
might be interesting to hear from anyone who would still find this a
problem.
What are the feelings about setting port 22 Xen Shell access to
require SSH public key auth (while leaving 922 to allow password
authentication as well)?
Do those of you who've added SSH keys want an option to *require*
SSH keys even on port 922?
At the very least the Fail2Ban ban time is going to have to go up
from 10 minutes to let's say 6 hours.
Cheers,
Andy
_______________________________________________
announce mailing list
announce(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/announce
_______________________________________________
users mailing list
users(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/users
12:25 p.m.
Hi Conrad,
On Fri, Mar 02, 2018 at 12:19:11PM +0000, Conrad Wood wrote:
I found blocking large network ranges for upto 60
minutes worked well
for my kind of ssh, together with an IP Whitelist of my most common IPs
. Perhaps an agressive fail2ban policy together with a user-maintained
ip whitelist would work well for bitfolk?
Yes, it may be a workable idea to block port 22 access completely
but then allow people to supply some allowed netblocks via the web
panel.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
12:41 p.m.
On 2/3/2018 14:25, Andy Smith wrote:
Hi Conrad,
On Fri, Mar 02, 2018 at 12:19:11PM +0000, Conrad Wood wrote:
I'm not so sure about this. Users are notorious for being too lax with
their whitelists. What limit will you impose on this user-set netblock?
/24? If you do this limit is as follows:
* 1 IP per entry
* Max 3 entries
I am for blocking 22 completely and allowing port password and key login
on 922.
--GM
I found blocking large network ranges for upto 60
minutes worked well
for my kind of ssh, together with an IP Whitelist of my most common IPs
. Perhaps an agressive fail2ban policy together with a user-maintained
ip whitelist would work well for bitfolk?
Yes, it may be a workable idea to block port 22 access completely
but then allow people to supply some allowed netblocks via the web
panel.
Cheers,
Andy
3:10 p.m.
On Fri, Mar 02, 2018 at 11:11:06AM +0000, Andy Smith wrote:
What are the feelings about setting port 22 Xen Shell
access to
require SSH public key auth (while leaving 922 to allow password
authentication as well)?
Do those of you who've added SSH keys want an option to *require*
SSH keys even on port 922?
At the very least the Fail2Ban ban time is going to have to go up
from 10 minutes to let's say 6 hours.
I only access the xen shell from one or two machines with the keys, so
personally I'd be all in favour of requiring auth, and probably
generally in favour of restrictions.
Michael
8:30 p.m.
Hi,
On 03/02/2018 04:10 PM, Michael Stevens wrote:
On Fri, Mar 02, 2018 at 11:11:06AM +0000, Andy Smith
wrote:
+1
Regards,
Sam
What are the feelings about setting port 22 Xen
Shell access to
require SSH public key auth (while leaving 922 to allow password
authentication as well)?
Do those of you who've added SSH keys want an option to *require*
SSH keys even on port 922?
At the very least the Fail2Ban ban time is going to have to go up
from 10 minutes to let's say 6 hours.
I only access the xen shell from one or
two machines with the keys, so
personally I'd be all in favour of requiring auth, and probably
generally in favour of restrictions. 
3:29 p.m.
fre 2018-03-02 klockan 11:11 +0000 skrev Andy Smith:
...
What are the feelings about setting port 22 Xen Shell access to
require SSH public key auth (while leaving 922 to allow password
authentication as well)?
Please do.
Do those of you who've added SSH keys want an
option to *require*
SSH keys even on port 922?
Yes, please.
// Andreas
8:38 p.m.
On Fri, Mar 02, 2018 at 11:11:06AM +0000, Andy Smith wrote:
[...]
What are the feelings about setting port 22 Xen Shell access to
require SSH public key auth (while leaving 922 to allow password
authentication as well)?
There have been times when I've logged into my VPS late at night from my
mobile phone, a little drunk maybe, and run 'poweroff', thinking that
I'm logged into a local computer. At times like this I've been thankful
of the Xen shell, accessible from my phone.
Yes, I'd probably learn to copy the key.
[...]
At the very least the Fail2Ban ban time is going to have to go up
from 10 minutes to let's say 6 hours.
Could you post the results of this a week after and see if that makes
things good again?
--
Best regards,
Ed http://www.s5h.net/
2486
days inactive
2486
days old
16 comments
12 participants
participants (12)
-
Alun Jones -
Andreas Olsson -
Andy Smith -
Conrad Wood -
Ed -
G. Miliotis -
Gavin Westwood -
Keith Williams -
Michael Stevens -
Richard Glynos -
Roger Light -
Samuel Bächler