Thanks for all the helpful information and comments.
My 'new'/replacement system arrived. It's a refurbed Dell with Windows
10 installed. My original plan was just to install a VM in Windows,
until I did the actual set up. It comes with a keystroke logger. Wow.
And they really want to improve your user experience by collenting a lot
of information and sending you a lot of stuff and giving you rewards.
I know you can "turn it off", but I never believe these claims. That's
why I have Google send me my timeline once a month. At least that way I
have some idea of what they are tracking.
Gparted worked pretty well. I like to use good old standard partitions,
so of course Windows uses 4 primaries. I deleted the recovery partition
and resized the main Windows partition and had a decent amount of space.
I burnt a Fedora XFCE disk and off to the races.
The install went fine. But I had remembered that during some installs
in the past there were more options/questions about bootloaded config.
It just installed grub2. I did a custom standard partition and started
with it's "default" suggestion, which has no swap space. After making
adjustments and adding swap and /var and configing users, the install
went without a hitch.
Now I have a system that boots into Fedora 36 just fine, which is all I
need. I can begin to figure out how to lock the system down and what to
bring in/set up to regain my old setup.
Doing the switch to boot from the disk was interesting. It seems like
Dell's BIOS is a little bit out of control. It's redundant and
unnecssarily complex. There are two hotkeys F2 and F12 and you have to
use them both. According to Dell's own web site, each BIOS is
'customized' to specific hardware. What turning off boot security and
turning on legacy boot actually do apparently varies a lot. I had to do
that to boot into the live OS and actually do the install.
Apparently Dell believes that difficulting in performing a task is a
type of security.
I decided to explore dual boot. I have heard for years that Windows and
Linux don't play well. But, an easy test was just to exit out of grub,
which then dumps you into Windows bootloader. This worked fine, but the
boot option to start windows simply doesn't work.
In looking into adding Windows boot to grub, it should be very easy.
Just run os-prober and then update-grub and magically you're done. These
are instructions for a Debian based system. I have to do some
translation for Fedora and update-grub becomes mkconfig-grub.
But it doesn't work.
It is interesting though that the Linux world is mostly Debian for the
'home' user and more Fedora for the more enterprise folks. No one is
going to dual boot their enterprise server, so there is no info. I did
find some interesting grub menuitems to try. But I might just abandon
the dual boot, because if it breaks when I'm in Windowsland, a distinct
possibility, I won't have any tools. Well I'd have the live CD.
But in addition to Windows and Linux not playing well together at boot
time, it seems the UEFI and Legacy don't play well together either. I
was surpised to find that Fedora 36 is a Legacy boot and Windows is a
UEFI.
Just for your entertainment. More reading for me.
And just one bug so far in Fedora or maybe it's Firefox:Firefox won't
play any videos. It just tells me the video is unavalable. I don't use
this system for that, but it is curious.
-Gary
I sent this early, but as the wrong person :).
Yes, the hardware is old and nothing more recent than that would install
and run. I use VM's that had more recent versions, but I was stuck at
Fedora 13 for the host hardware. I have a new system on order from
Dell. When I revive the hacked system, it will still probably be
running Fedora 13, but I'll use it for something else.
-Gary
On Fri, Aug 05, 2022 at 12:53:42PM -0700, Brian E. Lavender wrote:
> Gary,
>
> You were running Fedora 13?
>
> Brian
>
> On Fri, Aug 05, 2022 at 09:55:57AM -0700, Gary wrote:
> > In thinking a little more, even if they are attacking the certificate
> > directly, it is using the user they are logging in as .ssh certificate.
> > If that user doesn't exist, it seems that the attack should never work.
> >
> > I guess I still don't understand how they got in. But, my system was
> > rebooted. There must be more going on. They couldn't log in as root
> > directly since I, like most of the world, have that disabled and the
> > logs don't show that.
> >
> > -Gary
> >
> > On Fri, Aug 05, 2022 at 09:42:20AM -0700, Gary wrote:
> > > Interesting. Looks like keys are a risk. But, I still don't
> > > understand, and I don't think the article was clear about, how a brute force
> > > SSH password attack is possible over my very limited network. AT&T's
> > > cheapest plan isn't a very big pipe and I use good passwords. The
> > > attacker would have to have a great deal of luck.
> > >
> > > Since I use ssh for personal access, I'm considering looking into a
> > > firewall rule that simply walls out any IP that tries to log in with a
> > > user that isn't my account. Another thing that makes me wonder about
> > > this vector is the successful login wasn't from an account on my system.
> > >
> > > It seems to me that the keys/certifcates are being attacked directly.
> > > I've read other articles indicating that there are attackers in the wild doing this.
> > >
> > > So, it seems to me that eliminating key/certificate logins from outward
> > > facing systems may buy a lot of extra security. There were keys in my
> > > .ssh directory, but whether I installed them or the attacker did, is not
> > > clear. I wouldn't need them, but it is possible I could have created
> > > them at some point over the last 15 years I've been using this system :)
> > >
> > > -Gary
> > >
> > > On Fri, Aug 05, 2022 at 03:54:33AM -0600, Linus Sphinx wrote:
> > > > Join the club.
> > > > https://www.bleepingcomputer.com/news/security/new-linux-malware-brute-forc…
> > > >
> > > > On Tue, Aug 2, 2022 at 12:43 PM Gary <saclug(a)garymcglinn.com> wrote:
> > > >
> > > > > Hi Brian,
> > > > >
> > > > > Open letter.
> > > > >
> > > > > I remember years ago you did a presentation on snort.
> > > > >
> > > > > Do you still like it?
> > > > >
> > > > > -Gary
> > > > >
> > > > > _______________________________________________
> > > > > Lug-nuts mailing list -- lug-nuts(a)bigbrie.com
> > > > > To unsubscribe send an email to lug-nuts-leave(a)bigbrie.com
> > > > >
> > > _______________________________________________
> > > Lug-nuts mailing list -- lug-nuts(a)bigbrie.com
> > > To unsubscribe send an email to lug-nuts-leave(a)bigbrie.com
> > _______________________________________________
> > Lug-nuts mailing list -- lug-nuts(a)bigbrie.com
> > To unsubscribe send an email to lug-nuts-leave(a)bigbrie.com
>
> --
> Brian Lavender
> http://www.brie.com/brian/
>
> "There are two ways of constructing a software design. One way is to
> make it so simple that there are obviously no deficiencies. And the other
> way is to make it so complicated that there are no obvious deficiencies."
>
> Professor C. A. R. Hoare
> The 1980 Turing award lecture
> _______________________________________________
> Lug-nuts mailing list -- lug-nuts(a)bigbrie.com
> To unsubscribe send an email to lug-nuts-leave(a)bigbrie.com
----- End forwarded message -----
Interesting. Looks like keys are a risk. But, I still don't
understand, and I don't think the article was clear about, how a brute force
SSH password attack is possible over my very limited network. AT&T's
cheapest plan isn't a very big pipe and I use good passwords. The
attacker would have to have a great deal of luck.
Since I use ssh for personal access, I'm considering looking into a
firewall rule that simply walls out any IP that tries to log in with a
user that isn't my account. Another thing that makes me wonder about
this vector is the successful login wasn't from an account on my system.
It seems to me that the keys/certifcates are being attacked directly.
I've read other articles indicating that there are attackers in the wild doing this.
So, it seems to me that eliminating key/certificate logins from outward
facing systems may buy a lot of extra security. There were keys in my
.ssh directory, but whether I installed them or the attacker did, is not
clear. I wouldn't need them, but it is possible I could have created
them at some point over the last 15 years I've been using this system :)
-Gary
On Fri, Aug 05, 2022 at 03:54:33AM -0600, Linus Sphinx wrote:
> Join the club.
> https://www.bleepingcomputer.com/news/security/new-linux-malware-brute-forc…
>
> On Tue, Aug 2, 2022 at 12:43 PM Gary <saclug(a)garymcglinn.com> wrote:
>
> > Hi Brian,
> >
> > Open letter.
> >
> > I remember years ago you did a presentation on snort.
> >
> > Do you still like it?
> >
> > -Gary
> >
> > _______________________________________________
> > Lug-nuts mailing list -- lug-nuts(a)bigbrie.com
> > To unsubscribe send an email to lug-nuts-leave(a)bigbrie.com
> >
Before I powered down, while looking through the system logs on my poor
hacked computer, I noticed it was running chronyd, because it
complained. It is an old Fedora 13 system. It runs ntpd. That's bad.
But, on the VM and different box I am on on now, running Fedora 33, I
get:
[gary@entertain Mail]$ man -k date
date: nothing appropriate.
[gary@entertain Mail]$ man date
[gary@entertain Mail]$ man man
Where man date returns a man page. And according to the man page for
man:
man -k printf
Search the short descriptions and manual page names for the keyword
printf as regular expression. Print out any matches. Equivalent
to apropos printf.
Obviously man -k doesn't work.
I've been noticing more and more cruft like this. All kinds of things,
especially at the command line, where you can see, are broken.
I'm temporarily working from my entertainment system.
In reading so far, it looks like this is some kind of SSH key attack.
Makes me wonder why the default permissions in .ssh are what they are.
I must be missing somehting because the articles seem to call the .pub
file the private key. One even had a graphic with xxx.pub circled, to
show me where the private key is.
-Gary
Just when i was thinking of resurrecting meetings, Hacker Lab decided to
close! Wouldn't you know it! I wonder if Silver Skillet is still open?!
--
Brian Lavender
http://www.brie.com/brian/
"There are two ways of constructing a software design. One way is to
make it so simple that there are obviously no deficiencies. And the other
way is to make it so complicated that there are no obvious deficiencies."
Professor C. A. R. Hoare
The 1980 Turing award lecture
It looks like I've been hacked.
I came home after being away for 3 days to find my system had been rebooted. I have other systems that were fine, so I knew it wasn't a power glitch. My systems don't reboot if the power comes on. I checked my logs and the reboot occured at about 11 PM on Friday.
Before that, for at least hours and possibly days, there were a lot of login attempts. Some from users named terrorist, some that trace to Iran. I checked the audit log and found this:
type=CRYPTO_KEY_USER msg=audit(1659374984.916:5741): pid=5877 uid=0 auid=4294967295 ses=4294967295 msg='op=destroy kind=session fp=? direction=both spid=5878 suid=74 rport=51686 laddr=192.168.2.5 lport=23 exe="/usr/sbin/sshd" hostname=? addr=156.251.130.170 terminal=? res=success'
type=CRYPTO_KEY_USER msg=audit(1659374984.917:5742): pid=5877 uid=0 auid=4294967295 ses=4294967295 msg='op=destroy kind=server fp=b3:4d:28:a2:ce:77:2a:f8:58:21:75:95:d1:08:6d:26 direction=? spid=5877 suid=0 exe="/usr/sbin/sshd" hostname=? addr=156.251.130.170 terminal=? res=success
It traces to Africa. And I run sshd on port 23. This is the only IP I've found successful logins from. So, I've added a reject rule to the firewall.
It is interesting the journalctl only reports failed logins from this IP since the reboot. Audit.log has the successes, but no timestamp. I'm not sure why there should be continued failures from this address.
And now, I've got to start cleaning up.
And redoing with better security. Sigh.
-Gary
Permissions can be fun. I grant execute to the world to the operator home directory files, just for convenience.
But I haven't really played around with extended file attributes, for example. And I wonder if anyone actually uses SELinux.
And, I'm still trying to figure out how systemd is better than init.d. It's just different. I hate things that are just different since I waste energy learning them without gaining any benefit.
-Gary
----- Forwarded message from Linus Sphinx <sphinxtar(a)gmail.com> -----
Date: Wed, 6 Jul 2022 15:36:00 -0600
From: Linus Sphinx <sphinxtar(a)gmail.com>
To: Gary <saclug(a)garymcglinn.com>
Subject: Re: [Lug-nuts] [sphinxtar(a)gmail.com: Re: [sphinxtar(a)gmail.com: Re:
Basic SSH]]
Downside is you always have that caveat of one user to rule them all, you
can hide him, tighten his permissions til he's almost useless but you still
have to have that one shared account for all the admins to use, after all
the goal is to have scripts that run root level stuff everywhere from one
location, sudo helps but for a large enterprise there is no avoiding the
descent into madness that is UNIX permissions itself.
On Wed, Jul 6, 2022 at 8:45 AM Gary <saclug(a)garymcglinn.com> wrote:
> Yes, I have a script to send a nice melody to my living room computer when
> my coffee is ready that uses at and ssh.
>
> But, I often log in and get up and do things and theoretically someone
> could walk in the front door and sit down. Not that I'm paranoid, but I
> don't like the session/user to be able to do too much or know too much. So
> I don't make accessing another box too easy, unless I have a good reason.
> Plus there is the whole layered defense concept and all that.
>
> So, for a lot of scripting with ssh certificates, I use user operator. It
> was just sitting around with it's teeth in its mouth, so I put it to work.
> Plus the name sounded sort of descriptive. I wrote a script to do
> clipboard sharing over the network, for example. And, since I don't log in
> as operator ever, unless I am adding scripts or features, I have less of a
> security concern.
>
> -Gary
>
> ----- Forwarded message from Linus Sphinx <sphinxtar(a)gmail.com> -----
>
> Date: Wed, 6 Jul 2022 07:54:01 -0600
> From: Linus Sphinx <sphinxtar(a)gmail.com>
> To: Gary <saclug(a)garymcglinn.com>
> Subject: Re: [Lug-nuts] [sphinxtar(a)gmail.com: Re: Basic SSH]
>
> Way we had everything wired at etrade, made for some nice easy scripting.
>
> On Wed, Jul 6, 2022 at 6:37 AM Gary <saclug(a)garymcglinn.com> wrote:
>
> > I was thining of tyring that just to see if it would work. You would
> > think there would be an example of it somewhere. It's not how I'd like
> to
> > use it, but it would be a good way to figure things out.
> >
> > ----- Forwarded message from Linus Sphinx <sphinxtar(a)gmail.com> -----
> >
> > Date: Wed, 6 Jul 2022 05:01:48 -0600
> > From: Linus Sphinx <sphinxtar(a)gmail.com>
> > To: Gary <saclug(a)garymcglinn.com>
> > Subject: Re: [Lug-nuts] Basic SSH
> >
> > Do you own both servers? Maybe generate keys and exchange them? Sorry for
> > the RTFM: https://man7.org/linux/man-pages/man1/ssh-keygen.1.html
> >
> >
> > On Tue, Jul 5, 2022 at 11:35 PM Gary <saclug(a)garymcglinn.com> wrote:
> >
> > > So, my eyes grow weary of google nonsense.
> > >
> > > But is there ever a way to use anything other than:
> > >
> > > ssh -L xxxx:localhost:yyyy server.com
> > > or
> > > ssh -L xxxx:server.com:yyyy server.com
> > >
> > > for example
> > >
> > > ssh -L xxxx:anotherserver.com:yyyy server.com
> > >
> > > for example when there are firewalls.
> > >
> > > How would it work? Certificates only? I'd like to use a password on
> > > anotherserver.com
> > >
> > > I know I could get what I want using a double login and chaining ports.
> > > But, it seems like a real waste if the :localhost: is just to tickle
> the
> > > bind addresses on the server.
> > >
> > > -Gary
> > >
> > > _______________________________________________
> > > Lug-nuts mailing list -- lug-nuts(a)bigbrie.com
> > > To unsubscribe send an email to lug-nuts-leave(a)bigbrie.com
> > >
> >
> > ----- End forwarded message -----
> > _______________________________________________
> > Lug-nuts mailing list -- lug-nuts(a)bigbrie.com
> > To unsubscribe send an email to lug-nuts-leave(a)bigbrie.com
> >
>
> ----- End forwarded message -----
> _______________________________________________
> Lug-nuts mailing list -- lug-nuts(a)bigbrie.com
> To unsubscribe send an email to lug-nuts-leave(a)bigbrie.com
>
----- End forwarded message -----
