Allegedly, on or about 04 July 2017, William Mattison sent:
Yesterday evening, I used the firewall configuration tool to turn off
ssh in the public zone, and then make the the change permanent. I also entered the
* systemctl stop sshd
Stopped it now.
* systemctl mask sshd
Should stop it from being restarted ever again.
* systemctl stop httpd
* systemctl mask httpd
This evening, I see nothing in the journalctl logs for today that
like attempts to hack in. Definitely good news! Thank-you, everyone.
I'd expect that too. If the server isn't running, there's nothing to
poke at, and there won't be any logs from the server (proving the
1. I recall over the years several ways of connecting among computers:
kermit (am I dating myself here?!), ftp, rlogin, telnet, ssh, sftp,
and others. Are ***all*** these now blocked incoming?
I was under the impression that all of those protocols were blocked by
default, though someone (I can't remember who, now) pointed out that SSH
was allowed by default. If you look at your firewall configurator, it
ought to list what's allowed/disallowed. Or, you can look at iptable
rules on the command line.
On a home system, one that you say you're not going to access remotely,
or within a LAN, there's no point having any of those running, nor
2. I'm trying to get a fedora.people account. I'll be need
to ssh and
(s?)ftp(s?) out from my workstation into theirs. Will I still be able
to do that?
Outgoing connections from clients don't depend on you running a server
on your machine, they connect to the server on their machine. And, by
default, all traffic is allowed to go out through your firewall.
3. It was suggested that I block ssh login to root and ssh login via
password. Am I correct in assuming that I no longer need to do those
things? If no, how do I do those things?
If you don't have the service running, nobody can connect. I don't
configure services that I don't run. Though, if you ever intend to turn
the service on, you should look into doing that.
I agree with the block root SSH access by default, as a way that you
should configure it (if you're using it). And that's a fairly painless
thing to do, just set one option in the config file. But going
passwordless means that you need to set up keyfiles on the server,
manage keyfiles on flashdrives or some other way (for your computers
doing remote access). And I would challenge anybody to ever be able to
crack a passphrase like finkelbluetoadgrumpypelicans. You have no clues
to point to a nonsense phrase, no clues that you've almost guessed it,
and the number of permutations of just throwing every word in the
dictionary trying to brute force it would have to be astronomical. On
the other hand, if you're stupid enough to actually use "password," then
you deserve to get hacked.
I'm not convinced that SSH needs to be passwordless (if you're running
it). However, if you were to use the same password for a login as you
would to fetch mail or do other things (and that's the default way Linux
works, one password for almost everything you do), then you'd want to:
(a) Make sure that all login attempts are strongly encrypted (mail was
always plain text, but is moving towards encrypted logins), else
somewhere you'd have a service login that exposed your password,
allowing snoopers to grab your password all-too-easily.
(b) Make sure that anything that couldn't use encryption used a
different password than everything else (not so easy to implement for
[tim@localhost ~]$ uname -rsvp
Linux 3.9.10-100.fc17.x86_64 #1 SMP Sun Jul 14 01:31:27 UTC 2013 x86_64
(always current details of the computer that I'm writing this email on)
Boilerplate: All mail to my mailbox is automatically deleted, there is
no point trying to privately email me, I only get to see the messages
posted to the mailing list.
Windows (TM) [Typhoid Mary]. They refuse to believe that there's
anything wrong with it, but everyone else knows Windows is a disease