Again sent earlier. Thanks for the intervening comments about
vulnerabiliteis and versions.
A lot of issues and suggestions have been made and raised. My brief
response is that yes, according to nmap and my intention I had port 23,
for ssh (I moved it) and port 5900 open and the rpc port, I think. I'm
going by memory.
Theoretically the only pinhole in the ISP router firewall was port 23.
To use port 5900, you had to use an ssh tunnel.
My web server is on another machine. Since I only use it for
development, I don't leave it up.
My actual web pages are hosted externally on a vendor's box.
My experience with the upgrade treadmill is that it is a waste of time.
By its own admission (if a concept can have that) the new versions will
have issues and you need to upgrade. If the issues with an older
version don't affect you, then it is perfectly fine to use it. Why
upgrade and risk the fact that the new issues will affect your use case.
The developers for Fedora 13 were no smarter or dumber than the
developers who are writing Fedora 36. Or pick your distro of choice.
The issue with an older release is that nifty new things come out and
you can't really use them. But, if you run a VM with a recent version
of the distro, you can use them just fine.
The other issues is that if you are getting vendor support, they can
only reasonably commit to supporting a limited number of versions.
This is AMD hardware from '06.
-Gary
On Fri, Aug 05, 2022 at 06:19:54PM -0700, Rick Moen wrote:
> Quoting Brian E. Lavender (brian(a)brie.com):
>
> > Gary,
> >
> > You were running Fedora 13?
>
> If so, _that_ is likely a big problem. Fedora 13's initial release was
> May 25, 2010, and it was EOLed on June 24, 2011.
>
> Because Fedora. If you don't want to keep moving to newer versions,
> it's about the worst possible distro. (But it's possible Gary meant
> that he did _original_ installation 15 years ago, but has been following
> the recommended upgrade treadmill^W path.
>
> Linus Sphinx wrote:
>
> > https://www.bleepingcomputer.com/news/security/new-linux-malware-brute-forc…
>
> You know, I have a _lot_ of things to be grateful for, and somewhere on
> the list is the glad tidings that I don't need to rely on
> Bleepingcomputer.com for IT information.
>
> Over the past 1.5 months since its discovery, the new botnet used
> over 3,500 unique IPs worldwide to scan and attempt brute-forcing Linux
> SSH servers.
> [...]
> The SSH brute-forcing relies on a list of credentials downloaded from
> the [command and control server]. [...]
>
> *snore*
>
> So, doorknob-twisting for "joe accounts", like user=service
> password=manager and like that.
>
> Guestimate the math, and measure the lengthly setup and teardown times
> for remote connections to an sshd, and you'll find that
> dictionary-attacking an sshd with any reasonable rules set about
> password quality and length is going to take an appreciable fraction of
> the time to the heat death of the universe, to succeed.
>
> I mentioned upthread that a lot of IT device comes from gadget freaks.
> The _other_ common problem is that most security _articles_ are
> copied-pasted press releases from security/antimalware firms.
> So, they're big on shockhorror, and small on conveying understanding.
>
> I've only quick-glanced at this article about enforcing password policy
> via PAM, so won't swear to it being a good one:
> https://www.techrepublic.com/article/controlling-passwords-with-pam/
> Of course, if you're the -only- user, you ought to stick to decent
> passwords without PAM forcing you to. (Also, a user who can su to
> root has the power to overrule PAM. But if you do that, you have only
> yourself to blame for consequences.)
>
> _______________________________________________
> Lug-nuts mailing list -- lug-nuts(a)bigbrie.com
> To unsubscribe send an email to lug-nuts-leave(a)bigbrie.com
----- End forwarded message -----
It looks like I've managed to recover almost everything. Gparted's disk/partition recovery option worked really well. I don't know if or how it found any superblocks, but it built a loopback /tmp that was just golden.
It took 4 days to run but hey, it was the weekend.
The KVM/qemu files had to be edited quite a but due to the passage of versions/time. And aqemu won't run, but I think this is a Fedora 36 bug.
I'm glad almost everything was in VM's.
I used xxd and gawk to do some carving, but its nice that I won't have to grok all that stuff. Although since I split my RAID1, I'm going to keep the old info around and may play with it some just for fun.
Thanks for all the support, moral and otherwise.
I'm going to spend some time now and come up with a more sane and secure set up. Something I should probably due more than once every decade.
-Gary
I'm looking into locking down ssh some more. It seems that google
provides a PAM module to enable a one time password as part of two
factor authentication.
But changing sshd.comfig to have:
AuthenticationMethods publickey,password
Would require both a password and a key. Since I'm in no hurry to get
Google involved, I thought I might give it a try.
Anyone have any thoughts or played around with this?
-Gary
There may be. But I doubt if many apply to me. However, on a whim, I
installed Fedora 36 on the new drive and it works great. It's possible
that there was some other issue that was causing me difficulty in
upgrading. One prime candidate is operator error. Be that as it may, I
am now working on getting things working under Fedora 36.
I did some reading on UEFI and I have lots of philosopical
disagreements, primarily the same one I always have: It solves a problem
that shouldn't or doesn't exist and it is unnecessarily complex. Is
this really the wave of the future? I notice my Fedora 36 install
didn't use it. Apparently the NSA thinks it is a good idea. They go
all google eyed and mushy over secure boot. On their
page they have a "call for action" and a disclaimer that they aren't
making a recommendation within 3 adjacent paragraphs.
UEFI looks like a WinTel boondoggle to me. Putting a simulator of
Snoopy flying his dog house in a spreadsheet just has to be a good idea.
Apparently the NSA is now the old NSA calld SIGNT and the new NSA called
CSS. I don't know how this all relates to DHS.
-Gary
On Thu, Aug 11, 2022 at 02:46:23PM -0700, Brian E. Lavender wrote:
> On Mon, Aug 08, 2022 at 09:39:34AM -0700, saclug(a)garymcglinn.com wrote:
> > My experience with the upgrade treadmill is that it is a waste of time.
> > By its own admission (if a concept can have that) the new versions will
> > have issues and you need to upgrade. If the issues with an older
> > version don't affect you, then it is perfectly fine to use it. Why
> > upgrade and risk the fact that the new issues will affect your use case.
> > The developers for Fedora 13 were no smarter or dumber than the
> > developers who are writing Fedora 36. Or pick your distro of choice.
>
> There are probably a boat load of known vulnerabilities in F13. It's
> probably a script kitty winter wonderland, depending upon what you have
> installed/running! If you you want software that is secure proof, you
> have to run something like "Ironsides", written using SPARK/Ada.
>
> https://ironsides.martincarlisle.com/
>
> Beyon that, the best is to keep patching on a stable distro that doesn't
> have API changes, or minimal changes.
>
> Brian
>
> --
> 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 -----
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
> >