[opensuse] SuSEfirewall2-fail2ban
I thought I would throw this out for discussion based on my recent experience with this particular package. I installed this in my new installation of OpenSuSE15.0. I thought initially this package SuSEfirewall2-fail2ban was a good idea for integration between these two applications. But based on my recent experience with trying to install it I got to say either this package needs to be tossed or fixed, as it stands it seriously breaks SuSEfirewall2 and it is not an easy thing to debug. Some of the problems I had, once it was installed were - 1. It forces the startup of the fail2ban service each time SuSEfirewall service is started, not something you might want sometimes, and not easy to figure out how to discover and stop this relationship. 2. It has/causes dependency errors in the systemd launcher that breaks the ability of the SuSEfirewall service from starting properly. (this problem is widely talked about in other distros as well with their versions of firewalls, bug reports have been submitted, and no fix is yet available) 3. It caused/forced my networks internal NIC card to be relabeled as an external facing NIC, which then caused me to have 2 external facing NIC's and that broke all sorts of other services I had running on my server. (which led me on many wild goose chases trying to track down errors that other services such as Apache2, Tomcat, Apache James and even Named were reporting.) Given all the headaches this package caused me, my recommendation is to get rid of it, it is not really necessary AFAIK and my system seems to be running fine without it. Want to have some fun? Try it yourself, install the fail2ban service and this package also. Then restart the SuSEfirewall2 service and watch it belly ache. If you have two NICs like I do, one ext and one int then you will also see what happens with the int NIC. Yarrg! Marc... -- Linux Counter -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Marc Chamberlin <marc@marcchamberlin.com> [01-16-19 23:36]:
I thought I would throw this out for discussion based on my recent experience with this particular package. I installed this in my new installation of OpenSuSE15.0. I thought initially this package SuSEfirewall2-fail2ban was a good idea for integration between these two applications. But based on my recent experience with trying to install it I got to say either this package needs to be tossed or fixed, as it stands it seriously breaks SuSEfirewall2 and it is not an easy thing to debug. Some of the problems I had, once it was installed were -
1. It forces the startup of the fail2ban service each time SuSEfirewall service is started, not something you might want sometimes, and not easy to figure out how to discover and stop this relationship.
why would you not want the service running?????
2. It has/causes dependency errors in the systemd launcher that breaks the ability of the SuSEfirewall service from starting properly. (this problem is widely talked about in other distros as well with their versions of firewalls, bug reports have been submitted, and no fix is yet available)
and you are still running SuSEfirewall2 on Leap 15? change to firewalld, SuSEfirewall2 is no longer supported.
3. It caused/forced my networks internal NIC card to be relabeled as an external facing NIC, which then caused me to have 2 external facing NIC's and that broke all sorts of other services I had running on my server. (which led me on many wild goose chases trying to track down errors that other services such as Apache2, Tomcat, Apache James and even Named were reporting.)
fail2ban did not but you may have changed something to do that.
Given all the headaches this package caused me, my recommendation is to get rid of it, it is not really necessary AFAIK and my system seems to be running fine without it. Want to have some fun? Try it yourself, install the fail2ban service and this package also. Then restart the SuSEfirewall2 service and watch it belly ache. If you have two NICs like I do, one ext and one int then you will also see what happens with the int NIC. Yarrg!
if you are not running a server, don't install fail2ban. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Am Donnerstag, 17. Januar 2019, 06:07:11 CET schrieb Patrick Shanahan:
2. It has/causes dependency errors in the systemd launcher that breaks the ability of the SuSEfirewall service from starting properly. (this problem is widely talked about in other distros as well with their versions of firewalls, bug reports have been submitted, and no fix is yet available)
and you are still running SuSEfirewall2 on Leap 15? change to firewalld, SuSEfirewall2 is no longer supported.
Seriously? I must have missed that in the release notes, link please. Cheers MH -- Mathias Homann Senior Systems Engineer, IT Consultant. IT Trainer Mathias.Homann@openSUSE.org http://www.tuxonline.tech gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
Mathias Homann wrote:
Am Donnerstag, 17. Januar 2019, 06:07:11 CET schrieb Patrick Shanahan:
2. It has/causes dependency errors in the systemd launcher that breaks the ability of the SuSEfirewall service from starting properly. (this problem is widely talked about in other distros as well with their versions of firewalls, bug reports have been submitted, and no fix is yet available)
and you are still running SuSEfirewall2 on Leap 15? change to firewalld, SuSEfirewall2 is no longer supported.
Seriously? I must have missed that in the release notes, link please.
I don't know about "SuSEfirewall2 is no longer supported", but the switch to firewalld is mentioned: https://doc.opensuse.org/release-notes/x86_64/openSUSE/Leap/15.0/ Search for "SuSEfirewall2" to skip down to "Removed Packages". -- Per Jessen, Zürich (4.4°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 17/01/2019 08.26, Per Jessen wrote:
Mathias Homann wrote:
Am Donnerstag, 17. Januar 2019, 06:07:11 CET schrieb Patrick Shanahan:
2. It has/causes dependency errors in the systemd launcher that breaks the ability of the SuSEfirewall service from starting properly. (this problem is widely talked about in other distros as well with their versions of firewalls, bug reports have been submitted, and no fix is yet available)
and you are still running SuSEfirewall2 on Leap 15? change to firewalld, SuSEfirewall2 is no longer supported.
Seriously? I must have missed that in the release notes, link please.
I don't know about "SuSEfirewall2 is no longer supported", but the switch to firewalld is mentioned:
https://doc.opensuse.org/release-notes/x86_64/openSUSE/Leap/15.0/
Search for "SuSEfirewall2" to skip down to "Removed Packages".
The non supported status has been mentioned on the lists, but apparently there is no official message. In fact I'm still using it on two 15.0 machines till I set aside time to do the migration. I remember a thread where someone found that SuSEfirewall service files installed by other packages are being removed, causing SuSEfirewall to fail, too. I tried to find that thread but failed. I think it affected Tumbleweed. Meanwhile, SUSEfirewall2 in 15.0 got updates, I saw changes compared to 42.3 Warning: firewalld does not support NFS below V4, because it does not support NFSv3 and ypserv/ypbind, random ports. The first announcement I can find is this: From: Dominique Leuenberger / DimStar <...@opensuse.org> Date: Sat, 20 Jan 2018 13:16:20 +0100 Subject: [opensuse-factory] Tumbleweed - Review of the week 2018/03 +++------------- * Default firewall module picked for new installs is now firewalld -------------++- From: Matthias Gerstner <...@suse.de> Date: Mon, 22 Jan 2018 11:29:36 +0100 Subject: [opensuse-factory] Tumbleweed - Review of the week 2018/03 +++------------- We're in the process of changing the default firewall from SuSEfirewall2 to firewalld for SLE-15 and openSUSE Leap 15. The YaST installer should now be able to enable/disable firewalld and open/close the ssh port for it. The YaST firewall module will try to start the firewall-config X application for configuring firewalld at the moment. There will be some time without a YaST curses GUI for firewalld. firewalld comes with the firewall-cmd command line tool for configuring it. There will not be an automated migration path from an old SuSEfirewall2 configuration to a firewalld configuration. There is a package "susefirewall2-to-firewalld" which contains a utility for converting SuSEfirewall2 configurations to firewalld. It's only a supporting tool that tries to do the right thing. But it requires manual interaction and review of the resulting firewall rules. SuSEfirewall2 can stay in Tumbleweed for the moment but there are no plans to ship it as a legacy module in releases (at least not in SLE-15). SuSEfirewall2 and firewalld can live side by side but the user needs to take care that only one of them is active at any time. For users that extensively use SuSEfirewall2 with custom rules etc. I recommend to carefully setup new firewall rules using firewalld command line or GUI utilities. firewalld allows to pass raw iptables rules and also so called "rich rules" (proprietary simpler syntax provided by firewalld). These can be used to add custom rules to firewalld that are not otherwise covered by firewalld features. -------------++- And then there was a new thread asking for information: From: Robert Munteanu <...@gmail.com> Date: Mon, 22 Jan 2018 12:34:35 +0200 Subject: [opensuse-factory] firewalld migration (was: Tumbleweed - Review of the week 2018/03) -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
Hi carlos, Am 17.01.19 um 14:41 schrieb Carlos E. R.:> The non supported status has been mentioned on the lists, but apparently
there is no official message. In fact I'm still using it on two 15.0 machines till I set aside time to do the migration.
I remember a thread where someone found that SuSEfirewall service files installed by other packages are being removed, causing SuSEfirewall to fail, too. I tried to find that thread but failed. I think it affected Tumbleweed.
Meanwhile, SUSEfirewall2 in 15.0 got updates, I saw changes compared to 42.3
Warning: firewalld does not support NFS below V4, because it does not support NFSv3 and ypserv/ypbind, random ports.
if you want to change to firewalld: install firewalld-rpcbind-helper firewall-rpc-helper.py --help and follow the examples. this will change /etc/sysconfig/nfs for static nfs maybe if not inside this file present, add the line: RQUOTAD_PORT="" (to make sure all rules are applied (maybe for later use of this service) after that: yast firewall remove nfs remove nfs3 add the new created nfs-server-static and of course you have to uninstall susefirewall2 before... simoN -- www.becherer.de -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 17/01/2019 16.28, Simon Becherer wrote:
Hi carlos,
Am 17.01.19 um 14:41 schrieb Carlos E. R.:> The non supported status has been mentioned on the lists, but apparently
there is no official message. In fact I'm still using it on two 15.0 machines till I set aside time to do the migration.
I remember a thread where someone found that SuSEfirewall service files installed by other packages are being removed, causing SuSEfirewall to fail, too. I tried to find that thread but failed. I think it affected Tumbleweed.
Meanwhile, SUSEfirewall2 in 15.0 got updates, I saw changes compared to 42.3
Warning: firewalld does not support NFS below V4, because it does not support NFSv3 and ypserv/ypbind, random ports.
if you want to change to firewalld:
install firewalld-rpcbind-helper
firewall-rpc-helper.py --help
and follow the examples. this will change /etc/sysconfig/nfs for static nfs maybe if not inside this file present, add the line: RQUOTAD_PORT="" (to make sure all rules are applied (maybe for later use of this service)
after that: yast firewall remove nfs remove nfs3 add the new created nfs-server-static
and of course you have to uninstall susefirewall2 before...
Thanks for the info. In my case, I'll just make sure everything uses version 4. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
* Marc Chamberlin <marc@marcchamberlin.com> [01-16-19 23:36]:
I thought I would throw this out for discussion based on my recent experience with this particular package. I installed this in my new installation of OpenSuSE15.0. I thought initially this package SuSEfirewall2-fail2ban was a good idea for integration between these two applications. But based on my recent experience with trying to install it I got to say either this package needs to be tossed or fixed, as it stands it seriously breaks SuSEfirewall2 and it is not an easy thing to debug. Some of the problems I had, once it was installed were -
1. It forces the startup of the fail2ban service each time SuSEfirewall service is started, not something you might want sometimes, and not easy to figure out how to discover and stop this relationship. why would you not want the service running????? When I am testing and trying to get things working. Turning on/off one or both services allowed me to do A/B comparisons and relax constraints. I was getting confusing results when I turned SuSEfirewall2 on and was
Hi Patrick and thanks for responding. I will intersperse my answers with yours... On 01/16/2019 09:07 PM, Patrick Shanahan wrote: thinking I had turned off fail2ban.
2. It has/causes dependency errors in the systemd launcher that breaks the ability of the SuSEfirewall service from starting properly. (this problem is widely talked about in other distros as well with their versions of firewalls, bug reports have been submitted, and no fix is yet available) and you are still running SuSEfirewall2 on Leap 15? change to firewalld, SuSEfirewall2 is no longer supported.
I wasn't aware that SuSEfirewall2 has been deprecated and that the OpenSuSE distro is switching to firewalld. I will look into using it but regret all the work I have put into SuSEfirewall2, over the years, getting it configured the way I want for all the services I am running... Oh well, guess that is called progress...
3. It caused/forced my networks internal NIC card to be relabeled as an external facing NIC, which then caused me to have 2 external facing NIC's and that broke all sorts of other services I had running on my server. (which led me on many wild goose chases trying to track down errors that other services such as Apache2, Tomcat, Apache James and even Named were reporting.) fail2ban did not but you may have changed something to do that.
Um I am not saying fail2ban itself is at fault, but the additional stuff that controls the sequence and dependencies for systemd, in starting both the fail2ban and SuSEfirewall2 services, that was added by the SuSEfirewall2-fail2ban optional package. When I figured out I was having troubles with the stuff that the package SuSEfirewall2-fail2ban had installed, I simply uninstalled it and SuSEfirewall began to work as expected (along with all my other services). I saw a warning message that was appearing when I was starting up SuSEfirewall2, about the reassignment of my int NIC card reclassifying it as an ext NIC which got me suspicious that something was broken with SuSEfirewall2. That and the warning about conflicts in systemd dependencies from fail2ban (also seen when SuSEfirewall2 was started) lead me to discover that it was this particular package that was causing problems. So I simply uninstalled it, and SuSEfirewall was once again a happy camper, along with all my other services that I was struggling to get working.
Given all the headaches this package caused me, my recommendation is to get rid of it, it is not really necessary AFAIK and my system seems to be running fine without it. Want to have some fun? Try it yourself, install the fail2ban service and this package also. Then restart the SuSEfirewall2 service and watch it belly ache. If you have two NICs like I do, one ext and one int then you will also see what happens with the int NIC. Yarrg! if you are not running a server, don't install fail2ban.
But I am running a server! ;-) With lots of services as I mentioned, including Apache2, Tomcat, Apache-James, Bind, DHCPD, VSFTPD, SSHD, VNC, VPN, PortKnock etc. All of which are/were dependent on SuSEfirewall2 defining network interfaces and ports correctly. And when the interface definitions, as I defined them in /etc/sysconfig/SuSEfirewall2, got overruled somehow by the installation of the SuSEfirewall2-fail2ban package, things got really confusing. And I had to spend a lot of time trying to understand why many of these services were failing... One thing I have learned through the school of hard knocks is never trust error messages! Most of them are either balderdash, lazy guesswork on the part of the developers, or most commonly the results from poorly designed/implemented error handlers in the software. Ya gots to wade through lots of red herrings before finding the kernel of truth sometimes ;-) and this problem was particularly nasty to resolve, with lots of misleading error messages to grok. Anywise, I will follow your recommendation and take a look at firewalld, but that still begs the question, why include this particular package in the distro anymore. IMHO it badly breaks things... Marc... -- Linux Counter -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Patrick Shanahan wrote:
if you are not running a server, don't install fail2ban.
Any reasoning for this? I definitely disagree. Anything that has an open ssh port should run it IMHO. And that's more than just servers.... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Peter Suetterlin <pit@astro.su.se> [01-17-19 06:15]:
Patrick Shanahan wrote:
if you are not running a server, don't install fail2ban.
Any reasoning for this? I definitely disagree. Anything that has an open ssh port should run it IMHO. And that's more than just servers....
but ssh is a server service, and would definitely be a candidate for employing fail2ban. providing a web service or mail is not the only reason(s) for running a server. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Patrick Shanahan wrote:
* Peter Suetterlin <pit@astro.su.se> [01-17-19 06:15]:
Patrick Shanahan wrote:
if you are not running a server, don't install fail2ban.
Any reasoning for this? I definitely disagree. Anything that has an open ssh port should run it IMHO. And that's more than just servers....
but ssh is a server service, and would definitely be a candidate for employing fail2ban. providing a web service or mail is not the only reason(s) for running a server.
Well OK, with that definition of course all of my computers (even the Pi) are servers. This is the end of the Desktop :D -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Peter Suetterlin <pit@astro.su.se> [01-17-19 10:05]:
Patrick Shanahan wrote:
* Peter Suetterlin <pit@astro.su.se> [01-17-19 06:15]:
Patrick Shanahan wrote:
if you are not running a server, don't install fail2ban.
Any reasoning for this? I definitely disagree. Anything that has an open ssh port should run it IMHO. And that's more than just servers....
but ssh is a server service, and would definitely be a candidate for employing fail2ban. providing a web service or mail is not the only reason(s) for running a server.
Well OK, with that definition of course all of my computers (even the Pi) are servers.
This is the end of the Desktop :D
yes, the proliferation of computers, read small devices as tablets and phones, and the need to communicate and share information between makes "desktop" a physical description rather than a functional description. and vague at that as a laptop is more and more being utilized as a desktop. most devices can now be described as servers, if by no other function than sharing information. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, 17 Jan 2019 08:15:43 -0500 Patrick Shanahan <paka@opensuse.org> wrote:
* Peter Suetterlin <pit@astro.su.se> [01-17-19 06:15]:
Patrick Shanahan wrote:
if you are not running a server, don't install fail2ban.
Any reasoning for this? I definitely disagree. Anything that has an open ssh port should run it IMHO. And that's more than just servers....
but ssh is a server service, and would definitely be a candidate for employing fail2ban. providing a web service or mail is not the only reason(s) for running a server.
Could you clarify please? If I don't have sshd enabled and active, and only use ssh to connect to other machines, am I running an ssh server? I had always thought not, but this thread is confusing me. The same applies to rsync and rsyncd. Bob -- Bob
Bob Williams wrote:
On Thu, 17 Jan 2019 08:15:43 -0500 Patrick Shanahan <paka@opensuse.org> wrote:
* Peter Suetterlin <pit@astro.su.se> [01-17-19 06:15]:
Patrick Shanahan wrote:
if you are not running a server, don't install fail2ban.
Any reasoning for this? I definitely disagree. Anything that has an open ssh port should run it IMHO. And that's more than just servers....
but ssh is a server service, and would definitely be a candidate for employing fail2ban. providing a web service or mail is not the only reason(s) for running a server.
Could you clarify please?
"ssh is a server service" = "accepting ssh logins is a server task"
If I don't have sshd enabled and active, and only use ssh to connect to other machines, am I running an ssh server?
No. sshd is the server part.
I had always thought not, but this thread is confusing me.
Don't get confused. You're right ;^>
The same applies to rsync and rsyncd.
Same there. Running rsyncd to accept remote connects = server. using rsync (usually then via ssh) for syncing is not. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/17/2019 07:38 AM, Bob Williams wrote:
On Thu, 17 Jan 2019 08:15:43 -0500 Patrick Shanahan <paka@opensuse.org> wrote:
* Peter Suetterlin <pit@astro.su.se> [01-17-19 06:15]:
Patrick Shanahan wrote:
if you are not running a server, don't install fail2ban.
Any reasoning for this? I definitely disagree. Anything that has an open ssh port should run it IMHO. And that's more than just servers.... but ssh is a server service, and would definitely be a candidate for employing fail2ban. providing a web service or mail is not the only reason(s) for running a server.
Could you clarify please? If I don't have sshd enabled and active, and only use ssh to connect to other machines, am I running an ssh server? I had always thought not, but this thread is confusing me.
The same applies to rsync and rsyncd.
Bob
Hmmm this thread seems to have gone sideways but I think I got an answer... Since SuSEfirewall is going the way of dinosaurs I suspect my question about the SuSEFirewall2-fail2ban is moot.... Bob, as for the distinction, I would argue that the distinction between servers and desktops, and whether you are running an ssh server or not, lies in whether you are opening up ports on your system to accept incoming connections. If you are just initiating outgoing connections, such as using ssh to connect to other systems, or a mail client like Thunderbird to pick up your email, then you are not running a server. Fail2ban is a support service designed to prevent attacks against a server's services from some idiot who is attempting to gain access by guessing login names and passwords. Therefore it is monitoring incoming connections and thus falls in the realm of being a service/server. Marc... -- Linux Counter -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Quoting Marc Chamberlin <marc@marcchamberlin.com>:
On 01/17/2019 07:38 AM, Bob Williams wrote:
On Thu, 17 Jan 2019 08:15:43 -0500 Patrick Shanahan <paka@opensuse.org> wrote:
* Peter Suetterlin <pit@astro.su.se> [01-17-19 06:15]:
Patrick Shanahan wrote:
if you are not running a server, don't install fail2ban.
Any reasoning for this? I definitely disagree. Anything that has an open ssh port should run it IMHO. And that's more than just servers.... but ssh is a server service, and would definitely be a candidate for employing fail2ban. providing a web service or mail is not the only reason(s) for running a server.
Could you clarify please? If I don't have sshd enabled and active, and only use ssh to connect to other machines, am I running an ssh server? I had always thought not, but this thread is confusing me.
The same applies to rsync and rsyncd.
Bob
Hmmm this thread seems to have gone sideways but I think I got an answer... Since SuSEfirewall is going the way of dinosaurs I suspect my question about the SuSEFirewall2-fail2ban is moot....
Bob, as for the distinction, I would argue that the distinction between servers and desktops, and whether you are running an ssh server or not, lies in whether you are opening up ports on your system to accept incoming connections. If you are just initiating outgoing connections, such as using ssh to connect to other systems, or a mail client like Thunderbird to pick up your email, then you are not running a server. Fail2ban is a support service designed to prevent attacks against a server's services from some idiot who is attempting to gain access by guessing login names and passwords. Therefore it is monitoring incoming connections and thus falls in the realm of being a service/server.
Server is a role, as is client. Clients initiate connections to servers, which may then turn around and initiate a connection (i.e. as a client) to another server. Mail Transfer Agents such as Postfix, sendmail, qmail, etc. are a prime example of client/servers. E.g. I use Mutt as e-mail client to compose a message, it connects to Postfix (server), which connects (as client) to my ISP SMTP server, and so on. Unix and Linux systems presume a e-mail server. It may not allow incoming connections from other computers. Anything below with LISTEN in the last column is a server. # netstat -ant Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:3000 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:3001 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:9306 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:9312 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:6379 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:143 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:80 0.0.0.0:* LISTEN tcp 0 0 192.168.10.102:60388 199.59.150.44:443 ESTABLISHED tcp 0 0 127.0.0.1:6379 127.0.0.1:52760 ESTABLISHED tcp 32 0 192.168.10.102:55984 34.206.244.91:443 CLOSE_WAIT tcp 32 0 192.168.10.102:45810 54.192.7.216:443 CLOSE_WAIT tcp 0 0 192.168.10.102:47688 35.241.33.125:443 ESTABLISHED tcp 0 0 127.0.0.1:56014 127.0.0.1:143 ESTABLISHED tcp 0 0 127.0.0.1:52760 127.0.0.1:6379 ESTABLISHED tcp 147707 0 192.168.10.102:57286 173.239.76.148:80 ESTABLISHED tcp 0 0 127.0.0.1:44046 127.0.0.1:6379 ESTABLISHED tcp 0 0 127.0.0.1:143 127.0.0.1:56014 ESTABLISHED tcp 0 0 127.0.0.1:6379 127.0.0.1:44046 ESTABLISHED tcp 0 0 ::1:631 :::* LISTEN tcp 0 0 ::1:25 :::* LISTEN -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 17/01/2019 16.38, Bob Williams wrote:
On Thu, 17 Jan 2019 08:15:43 -0500 Patrick Shanahan <paka@opensuse.org> wrote:
* Peter Suetterlin <pit@astro.su.se> [01-17-19 06:15]:
Patrick Shanahan wrote:
if you are not running a server, don't install fail2ban.
Any reasoning for this? I definitely disagree. Anything that has an open ssh port should run it IMHO. And that's more than just servers....
but ssh is a server service, and would definitely be a candidate for employing fail2ban. providing a web service or mail is not the only reason(s) for running a server.
Could you clarify please? If I don't have sshd enabled and active, and only use ssh to connect to other machines, am I running an ssh server? I had always thought not, but this thread is confusing me.
The same applies to rsync and rsyncd.
In Linux, many things provide "server" facilities. It does not mean that the machine is a public or internal server. In Windows world, they have a different product that is called Windows Server, and charge for it differently. In Linux any machine can act as server easily. If you use ssh on your laptop to connect to your desktop, then you desktop is asking as server and the laptop as client. And the role can be reversed instantly, even simultaneously. If you share a directory on your desktop to access it from your laptop, then the desktop is acting as file server. Regarding ssh, then you need to have the sshd service running to be a "ssh server". And the port opened in the firewalld. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On Thu, 17 Jan 2019 19:33:54 +0100 "Carlos E. R." <robin.listas@telefonica.net> wrote:
In Linux, many things provide "server" facilities.
The one that always used to provoke the most arguments was X windows: The X windows server runs on the client machine. The X windows client runs on the server machine. So .. horses for courses, and make sure you've defined terms in advance. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Peter Suetterlin wrote:
Patrick Shanahan wrote:
if you are not running a server, don't install fail2ban.
Any reasoning for this? I definitely disagree. Anything that has an open ssh port should run it IMHO. And that's more than just servers....
Alternatively - use keys for ssh, and that problem is gone. Or if that's too cumbersome, move ssh to a higher port. Works wonders. -- Per Jessen, Zürich (5.6°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 17/01/2019 14.49, Per Jessen wrote:
Peter Suetterlin wrote:
Patrick Shanahan wrote:
if you are not running a server, don't install fail2ban.
Any reasoning for this? I definitely disagree. Anything that has an open ssh port should run it IMHO. And that's more than just servers....
Alternatively - use keys for ssh, and that problem is gone. Or if that's too cumbersome, move ssh to a higher port. Works wonders.
I do both. Curious thing is, I have no idea if there are attempts at my router, it doesn't report anything. What I know is only on the inside machine: Isengard sshd 6221 - - Accepted publickey for cer from 192.168.1.1 port ... ssh2: RSA SHA256:... and you see, it logs the internal IP of the router, not the external. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
Carlos E. R. wrote:
On 17/01/2019 14.49, Per Jessen wrote:
Peter Suetterlin wrote:
Patrick Shanahan wrote:
if you are not running a server, don't install fail2ban.
Any reasoning for this? I definitely disagree. Anything that has an open ssh port should run it IMHO. And that's more than just servers....
Alternatively - use keys for ssh, and that problem is gone. Or if that's too cumbersome, move ssh to a higher port. Works wonders.
I do both.
When you're using keys, there is no need to change the port. You gain nothing.
Curious thing is, I have no idea if there are attempts at my router, it doesn't report anything.
With keys, there is nothing to report. -- Per Jessen, Zürich (5.6°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 17/01/2019 17.30, Per Jessen wrote:
Carlos E. R. wrote:
On 17/01/2019 14.49, Per Jessen wrote:
Peter Suetterlin wrote:
Patrick Shanahan wrote:
if you are not running a server, don't install fail2ban.
Any reasoning for this? I definitely disagree. Anything that has an open ssh port should run it IMHO. And that's more than just servers....
Alternatively - use keys for ssh, and that problem is gone. Or if that's too cumbersome, move ssh to a higher port. Works wonders.
I do both.
When you're using keys, there is no need to change the port. You gain nothing.
Less noise on the logs, banging the port 22 produces nothing. Actually, apparently my router has its own ssh service, and it can not be stopped. I had to firewall it instead, because IRC would not let me in: they actively probe ports on clients: [19:19] [Notice] -freenode-connect- Welcome to freenode. To protect the network all new connections will be scanned for vulnerabilities. This will not harm your computer, and vulnerable hosts will be notified.
Curious thing is, I have no idea if there are attempts at my router, it doesn't report anything.
With keys, there is nothing to report.
Yes, the attempts. There is noise. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
Carlos E. R. wrote:
On 17/01/2019 17.30, Per Jessen wrote:
Carlos E. R. wrote:
On 17/01/2019 14.49, Per Jessen wrote:
Peter Suetterlin wrote:
Patrick Shanahan wrote:
if you are not running a server, don't install fail2ban.
Any reasoning for this? I definitely disagree. Anything that has an open ssh port should run it IMHO. And that's more than just servers....
Alternatively - use keys for ssh, and that problem is gone. Or if that's too cumbersome, move ssh to a higher port. Works wonders.
I do both.
When you're using keys, there is no need to change the port. You gain nothing.
Less noise on the logs, banging the port 22 produces nothing.
1) one line is logged per attempt 2) no one is going to bother Personally, I don't bother. And any rapid "banging" is easily rejected by the firewall. -- Per Jessen, Zürich (-2.8°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 1/17/19 8:30 AM, Per Jessen wrote:
Alternatively - use keys for ssh, and that problem is gone. Or if that's too cumbersome, move ssh to a higher port. Works wonders. I do both. When you're using keys, there is no need to change the port. You gain nothing.
Curious thing is, I have no idea if there are attempts at my router, it doesn't report anything. With keys, there is nothing to report.
Unless a zero-day is discovered in sshd! BTW, I remember when I first installed SuSE 5.2 on my home computer the documentation for the firewall was still in German. I decided to just turn it off until I could figure things out later. Alas, I was quickly pwned via a remote-root vulnerability in mountd. I caught it right away and re-installed the system, this time with the firewall running. Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Lew Wolfgang wrote:
On 1/17/19 8:30 AM, Per Jessen wrote:
Alternatively - use keys for ssh, and that problem is gone. Or if that's too cumbersome, move ssh to a higher port. Works wonders. I do both. When you're using keys, there is no need to change the port. You gain nothing.
Curious thing is, I have no idea if there are attempts at my router, it doesn't report anything. With keys, there is nothing to report.
Unless a zero-day is discovered in sshd!
Nothing much to report except : sshd[11505]: Accepted publickey for user from 192.168.112.114 port 59294
BTW, I remember when I first installed SuSE 5.2 on my home computer the documentation for the firewall was still in German. I decided to just turn it off until I could figure things out later. Alas, I was quickly pwned via a remote-root vulnerability in mountd. I caught it right away and re-installed the system, this time with the firewall running.
Going a bit off-topic here, but I expect we have all been there. I had a webserver compromised by someone brute forcing the password and I think we also had someone very close to gaining access by way of a PHP vulnerability. It was caught by outbound emails failing. -- Per Jessen, Zürich (-2.8°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 1/17/19 5:49 AM, Per Jessen wrote:
Peter Suetterlin wrote:
Patrick Shanahan wrote:
if you are not running a server, don't install fail2ban.
Any reasoning for this? I definitely disagree. Anything that has an open ssh port should run it IMHO. And that's more than just servers.... Alternatively - use keys for ssh, and that problem is gone. Or if that's too cumbersome, move ssh to a higher port. Works wonders.
Security through obscurity? What could possibly go wrong? Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 17/01/2019 19.31, Lew Wolfgang wrote:
On 1/17/19 5:49 AM, Per Jessen wrote:
Peter Suetterlin wrote:
Patrick Shanahan wrote:
if you are not running a server, don't install fail2ban.
Any reasoning for this? I definitely disagree. Anything that has an open ssh port should run it IMHO. And that's more than just servers.... Alternatively - use keys for ssh, and that problem is gone. Or if that's too cumbersome, move ssh to a higher port. Works wonders.
Security through obscurity? What could possibly go wrong?
Actually, it works fantastically. And arguably, it is not "obscurity". Consider your door key: it has a number of notches, perhaps eight, in different height values, perhaps twenty (guessing, I'm not a locksmith). You can do the math and find out the number of combinations: it is finite and not astronomical. You can sequentially try every combination of "mechanical key values" and finally you open the door without "breaking" it. Ie, find the correct key. This is the same: the attacker has to poll every port in order to find the correct one. Sixty something thousand combinations. It is just a key with not a huge number of combinations: and it works, only people that really want your machine try to enter. The scripts usually abandon and try another host. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On 1/17/19 10:42 AM, Carlos E. R. wrote:
On 17/01/2019 19.31, Lew Wolfgang wrote:
On 1/17/19 5:49 AM, Per Jessen wrote:
Peter Suetterlin wrote:
Patrick Shanahan wrote:
if you are not running a server, don't install fail2ban.
Any reasoning for this? I definitely disagree. Anything that has an open ssh port should run it IMHO. And that's more than just servers.... Alternatively - use keys for ssh, and that problem is gone. Or if that's too cumbersome, move ssh to a higher port. Works wonders. Security through obscurity? What could possibly go wrong? Actually, it works fantastically. And arguably, it is not "obscurity".
Consider your door key: it has a number of notches, perhaps eight, in different height values, perhaps twenty (guessing, I'm not a locksmith). You can do the math and find out the number of combinations: it is finite and not astronomical. You can sequentially try every combination of "mechanical key values" and finally you open the door without "breaking" it. Ie, find the correct key.
This is the same: the attacker has to poll every port in order to find the correct one. Sixty something thousand combinations. It is just a key with not a huge number of combinations: and it works, only people that really want your machine try to enter. The scripts usually abandon and try another host.
Well, doesn't all security rely on obscurity? The goal should be to increase obscurity as much as possible. Crypto keys can be guessed, if you can throw enough guesses. But if you block access after a low number of failed guesses you've decreased your odds of being successfully guessed by huge amount. A full nmap scan of all ephemeral ports doesn't take all that long, and you could also use shodan. Once you discover the sshd port, you can start guessing/hacking/etc. Yes, a door key is an example of security through obscurity, and most of them are trivially easy to compromise. I've done it myself, even without carrying around a bag of all possible key combinations. I think the number of key combinations is less than one would think. Sure, moving sshd to an ephemeral port helps, but it's only an inconvenience to even a moderately skilled hacker. Using crypto keys and disabling username/password logins for public-facing servers is good, adding fail2ban or SSHGuard makes it even better. Then, if you allow port 22 access only from IP's that you own, you're golden. Defense in depth! Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/17/2019 02:48 PM, Lew Wolfgang wrote:
Well, doesn't all security rely on obscurity? The goal should be to increase obscurity as much as possible. Crypto keys can be guessed, if you can throw enough guesses.
Actually, no. The method can be open, provided the keys are secret. Given the size of current keys, they'd take a huge amount of guessing. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 17/01/2019 20.53, James Knott wrote:
On 01/17/2019 02:48 PM, Lew Wolfgang wrote:
Well, doesn't all security rely on obscurity? The goal should be to increase obscurity as much as possible. Crypto keys can be guessed, if you can throw enough guesses.
Actually, no. The method can be open, provided the keys are secret. Given the size of current keys, they'd take a huge amount of guessing.
And that's not security through obscurity. That would be using a non-published secret crypto method, and where knowing the method would instantly lead to opening the door. Example: hiding the door latch somewhere, like with with a button press that you can not see with simple eyes. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On 1/17/19 12:33 PM, Carlos E. R. wrote:
On 17/01/2019 20.53, James Knott wrote:
On 01/17/2019 02:48 PM, Lew Wolfgang wrote:
Well, doesn't all security rely on obscurity? The goal should be to increase obscurity as much as possible. Crypto keys can be guessed, if you can throw enough guesses. Actually, no. The method can be open, provided the keys are secret. Given the size of current keys, they'd take a huge amount of guessing. And that's not security through obscurity. That would be using a non-published secret crypto method, and where knowing the method would instantly lead to opening the door. Example: hiding the door latch somewhere, like with with a button press that you can not see with simple eyes.
Huh? Throwing guesses at a public crypto system doesn't require any knowledge of the method. It might take a few billion years, but it's possible to do. You might get lucky at the first guess! Of course, one could put bounds on the guesses if you knew the encryption algorithm, that's what hacker reconnaissance does, like identifying the version number of the sshd server. Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 17/01/2019 22.10, Lew Wolfgang wrote:
On 1/17/19 12:33 PM, Carlos E. R. wrote:
On 17/01/2019 20.53, James Knott wrote:
On 01/17/2019 02:48 PM, Lew Wolfgang wrote:
Well, doesn't all security rely on obscurity? The goal should be to increase obscurity as much as possible. Crypto keys can be guessed, if you can throw enough guesses. Actually, no. The method can be open, provided the keys are secret. Given the size of current keys, they'd take a huge amount of guessing. And that's not security through obscurity. That would be using a non-published secret crypto method, and where knowing the method would instantly lead to opening the door. Example: hiding the door latch somewhere, like with with a button press that you can not see with simple eyes.
Huh? Throwing guesses at a public crypto system doesn't require any knowledge of the method. It might take a few billion years, but it's possible to do. You might get lucky at the first guess! Of course, one could put bounds on the guesses if you knew the encryption algorithm, that's what hacker reconnaissance does, like identifying the version number of the sshd server.
No. I'm saying that the term "security through obscurity" does not refer to having to guess the key or password. It refers to hiding the lock mechanism, to keeping the encryption method secret - because the instant it is known, the lock can be opened without knowing or guessing the password.. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On 17/01/2019 22.17, Carlos E. R. wrote:
On 17/01/2019 22.10, Lew Wolfgang wrote:
On 1/17/19 12:33 PM, Carlos E. R. wrote:
On 17/01/2019 20.53, James Knott wrote:
On 01/17/2019 02:48 PM, Lew Wolfgang wrote:
Well, doesn't all security rely on obscurity? The goal should be to increase obscurity as much as possible. Crypto keys can be guessed, if you can throw enough guesses. Actually, no. The method can be open, provided the keys are secret. Given the size of current keys, they'd take a huge amount of guessing. And that's not security through obscurity. That would be using a non-published secret crypto method, and where knowing the method would instantly lead to opening the door. Example: hiding the door latch somewhere, like with with a button press that you can not see with simple eyes.
Huh? Throwing guesses at a public crypto system doesn't require any knowledge of the method. It might take a few billion years, but it's possible to do. You might get lucky at the first guess! Of course, one could put bounds on the guesses if you knew the encryption algorithm, that's what hacker reconnaissance does, like identifying the version number of the sshd server.
No. I'm saying that the term "security through obscurity" does not refer to having to guess the key or password. It refers to hiding the lock mechanism, to keeping the encryption method secret - because the instant it is known, the lock can be opened without knowing or guessing the password..
For instance, ROR encryption. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On 1/17/19 1:17 PM, Carlos E. R. wrote:
No. I'm saying that the term "security through obscurity" does not refer to having to guess the key or password. It refers to hiding the lock mechanism, to keeping the encryption method secret - because the instant it is known, the lock can be opened without knowing or guessing the password..
The "lock mechanism" of ssh is known, can it be opened without knowing or guessing the password? The mechanism of a doorknob lock is known, the one good key is obfuscated by hiding it among all the keys that won't work. Security through obscurity! Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 17/01/2019 22.32, Lew Wolfgang wrote:
On 1/17/19 1:17 PM, Carlos E. R. wrote:
No. I'm saying that the term "security through obscurity" does not refer to having to guess the key or password. It refers to hiding the lock mechanism, to keeping the encryption method secret - because the instant it is known, the lock can be opened without knowing or guessing the password..
The "lock mechanism" of ssh is known, can it be opened without knowing or guessing the password?
No
The mechanism of a doorknob lock is known, the one good key is obfuscated by hiding it among all the keys that won't work. Security through obscurity!
No, that is not obfuscation. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On 1/17/19 4:31 PM, Carlos E. R. wrote:
On 17/01/2019 22.32, Lew Wolfgang wrote:
On 1/17/19 1:17 PM, Carlos E. R. wrote:
No. I'm saying that the term "security through obscurity" does not refer to having to guess the key or password. It refers to hiding the lock mechanism, to keeping the encryption method secret - because the instant it is known, the lock can be opened without knowing or guessing the password.. The "lock mechanism" of ssh is known, can it be opened without knowing or guessing the password? No
But you said that once the encryption method (not the key) is known the lock can be opened. SSH's encryption methods are open-source, they are known.
The mechanism of a doorknob lock is known, the one good key is obfuscated by hiding it among all the keys that won't work. Security through obscurity! No, that is not obfuscation.
I have 2000 different keys. One of those keys work in my door lock. To keep Per from sneaking in and drinking all of my beer, I put all 2000 keys in a bag and hang it on the front door. The one good key is hidden among 1999 other ones. It's obscured, isn't it? If not, what is it? Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/17/2019 07:18 PM, Lew Wolfgang wrote:
I have 2000 different keys. One of those keys work in my door lock. To keep Per from sneaking in and drinking all of my beer, I put all 2000 keys in a bag and hang it on the front door. The one good key is hidden among 1999 other ones. It's obscured, isn't it? If not, what is it?
Regards, Lew
Watch it... even a blind squirrel finds a nut ever now and then... If it were my beer, I'd hide the tap the keep that lush away from it... -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 18/01/2019 02.18, Lew Wolfgang wrote:
On 1/17/19 4:31 PM, Carlos E. R. wrote:
On 17/01/2019 22.32, Lew Wolfgang wrote:
On 1/17/19 1:17 PM, Carlos E. R. wrote:
No. I'm saying that the term "security through obscurity" does not refer to having to guess the key or password. It refers to hiding the lock mechanism, to keeping the encryption method secret - because the instant it is known, the lock can be opened without knowing or guessing the password.. The "lock mechanism" of ssh is known, can it be opened without knowing or guessing the password? No
But you said that once the encryption method (not the key) is known the lock can be opened. SSH's encryption methods are open-source, they are known.
Exactly. And even knowing the method in detail, you still need the key to open it, so it is not "security through obscurity"
The mechanism of a doorknob lock is known, the one good key is obfuscated by hiding it among all the keys that won't work. Security through obscurity! No, that is not obfuscation.
I have 2000 different keys. One of those keys work in my door lock. To keep Per from sneaking in and drinking all of my beer, I put all 2000 keys in a bag and hang it on the front door. The one good key is hidden among 1999 other ones. It's obscured, isn't it? If not, what is it?
This is a bit contrived, people don't put a bag of keys by the door. If you do that, you are changing the premises. Still, I don't think that is obfuscation; it would be similar to posting a list of passwords with one correct. Even so, the key lock system is not using obfuscation, just a small set of possible password combinations. However. Keylocks. Someone, somewhere, at some prison, used the inmates to assemble some brand door locks. The inmates got thus intimate knowledge of how the lock worked, and designed a system to break it. Soon all the thieves in the country knew how to open those locks easily. That is security through obscurity, and it was found out :-p Compared to analysts finding a debility in some encryption software allowing to break the codes easily. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On 01/18/2019 04:20 AM, Carlos E. R. wrote:
But you said that once the encryption method (not the key) is known the lock can be opened. SSH's encryption methods are open-source, they are known. Exactly. And even knowing the method in detail, you still need the key to open it, so it is not "security through obscurity"
I'm talking about obscuring the one good key with a large number of bad ones. You're taking about the lock, I'm talking about the keys. I think we're talking past each other? Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Lew Wolfgang wrote:
On 01/18/2019 04:20 AM, Carlos E. R. wrote:
But you said that once the encryption method (not the key) is known the lock can be opened. SSH's encryption methods are open-source, they are known. Exactly. And even knowing the method in detail, you still need the key to open it, so it is not "security through obscurity"
I'm talking about obscuring the one good key with a large number of bad ones. You're taking about the lock, I'm talking about the keys. I think we're talking past each other?
Maybe this has gone a bit too off-topic? -- Per Jessen, Zürich (0.2°C) member, openSUSE Heroes -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 1/17/19 11:53 AM, James Knott wrote:
On 01/17/2019 02:48 PM, Lew Wolfgang wrote:
Well, doesn't all security rely on obscurity? The goal should be to increase obscurity as much as possible. Crypto keys can be guessed, if you can throw enough guesses. Actually, no. The method can be open, provided the keys are secret. Given the size of current keys, they'd take a huge amount of guessing.
Yes, of course, but theoretically possible to guess nevertheless. The risk of there being a vulnerability in the sshd daemon is probably greater, which is why a bad guess filter is also a good idea, along with firewall ACL's to limit who can connect (if appropriate for the requirements, of course). Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Lew Wolfgang wrote:
On 1/17/19 5:49 AM, Per Jessen wrote:
Peter Suetterlin wrote:
Patrick Shanahan wrote:
if you are not running a server, don't install fail2ban.
Any reasoning for this? I definitely disagree. Anything that has an open ssh port should run it IMHO. And that's more than just servers.... Alternatively - use keys for ssh, and that problem is gone. Or if that's too cumbersome, move ssh to a higher port. Works wonders.
Security through obscurity? What could possibly go wrong?
Hi Lew Obviously YMMV, but we had a number of systems where we didn't want to use keys (can't remember why, it's 10+ years ago), moving the port was sufficient to stop the brute force attacks. At the time, someone also suggested picking a new port every day, but we never implemented that. Today, I would insist on using keys. -- Per Jessen, Zürich (-1.9°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Marc Chamberlin wrote:
I thought I would throw this out for discussion based on my recent experience with this particular package. I installed this in my new installation of OpenSuSE15.0. I thought initially this package SuSEfirewall2-fail2ban was a good idea for integration between these two applications. But based on my recent experience with trying to install it I got to say either this package needs to be tossed or fixed, as it stands it seriously breaks SuSEfirewall2 and it is not an easy thing to debug. Some of the problems I had, once it was installed were -
You are aware that Leap15 switched from SuSEfirewall2 to using the new firewalld by default? I would expect fail2ban to work fine for the moment, but unless it is updated to work with firewalld, it probably won't continue to do so.
Try it yourself, install the fail2ban service and this package also. Then restart the SuSEfirewall2 service and watch it belly ache. If you have two NICs like I do, one ext and one int then you will also see what happens with the int NIC. Yarrg!
Anyone running a firewall will presumably have at least two NICs ? -- Per Jessen, Zürich (4.2°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Mathias Homann wrote:
Am 2019-01-17 08:19, schrieb Per Jessen:
Anyone running a firewall will presumably have at least two NICs ?
So if your webserver has only one NIC you wouldn't put any firewall on it?
Ah yes, that's true, I was thinking more of a router, but you're right of course. -- Per Jessen, Zürich (6.8°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (14)
-
Bob Williams -
Carlos E. R. -
Dave Howorth -
David C. Rankin -
James Knott -
Jeffrey L. Taylor -
Lew Wolfgang -
Marc Chamberlin -
Mathias Homann -
Mathias Homann
-
Patrick Shanahan -
Per Jessen -
Peter Suetterlin -
Simon Becherer