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@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-force...
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@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
----- End forwarded message -----
On 8/8/22 09:39, saclug@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.
This is a perfectly valid viewpoint. A friend in the computer security industry, a senior developer, agrees with you 100%. Like all things security, this stance has plusses and minuses, but it's sensible.
If that's your choice, there's a premium on defending your system's attack surface, and maintaining due diligence. Since you've chosen Fedora, SELinux should be enabled (I know, there are a million recommendations to turn it off, all wrong) and a solid set of firewall rules should be in place. Certificate-only SSH might have prevented your last attacker from compromising the host, or a 14-character passphrase, or diligent log review. For example (fedora):
# ausearch -ts week-ago --success no --interpret
or maybe
# last -x
I recognize that most security recommendations present hurdles, SELinux configuration and firewall rules are no exception. I'm working on a suite of tools to help with that, but they're not ready for release.
Fedora seems to be at one end of a spectrum, with perhaps Slackware on the other end, where the above strategy seems a little weak. Fedora seems to push out changes quickly and with great tumult, not infrequently requiring patches to their patches. In contrast, Slackware releases after exhaustive testing and review, and doesn't seem to chase - or incorporate- moving targets. I'm not recommending one over the other, just trying to compare and contrast.
The developers for Fedora 13 were no smarter or dumber than the developers who are writing Fedora 36. Or pick your distro of choice.
I disagree. The previous generation of developers (Alan Cox was an exemplar) were more careful, thoughtful, and expert in their craft. Kids these days... Eventually they'll get better, maybe better than the Old Guard. But for now, there are a plethora of semi-skilled Kool Kids in the fray. Perhaps my view is jaundiced because I'm doing front-end (web) development this month.
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.
Again, some distributions are like mayflies, some are like elephants. Fedora is perhaps an unconventional choice for longevity.
Thanks for your insights and thoughts. I would be in denial, except that I can't ignore that my system was rebooted by an actor other than me. Yes, I should be reviewing the logs more. I'm not sure about SSH certificate access as there seems to be a very active attack directly against these in the last few months. And, many of the systems I was using to SSH into my box aren't as physically secure and if they were hacked, it would give access to my set up.
SElinux, I"ll have to look into it more. As you mentioned, I have been turning it off.
And, I was wrong, now that I am recovering things, I can see I was running Fedora 19, not 13. Memory can be a bit fickle :)
My passwords are at least 14 characters ( I just counted on my fingers) and fairly complex. But I'm still grappling with the fact that I have a low bandwidth connection and a brute force attack should be prohibitivly slow. I can see a lot of attemps, thousands for sure, but it should take a lot more than that.
I've been using SSH to make a VNC tunnel so I can access this desktop from anywhere. Which has lots of advantages, especially when accessing sites that have 2 factor authentication.
I've been refusing to make my phone into a security device. It's a toy or perhaps a tool for business. So, my contact number has been a land line via voice for the 2nd factor.
I'm going to have to review everything and come up with a new solution. Maybe I'll get two phones or something. But the whole shoving ads and "news" at me and forced upgrades and harvesting of personal information really turn me off about phones. Friends complain that I never have my phone on me. I am somewhat surprised that they think I should be instantly available almost 24/7. Well, I prefer to control my time as opposed to letting the Borg/phone do it.
I'm delusional, I know, I still think I'm someboday and I'm not quite willing to join the Borg of nobodies :)
-Gary
gn Tue, Aug 09, 2022 at 09:29:37AM -0700, Charles Polisher wrote:
On 8/8/22 09:39, saclug@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.
This is a perfectly valid viewpoint. A friend in the computer security industry, a senior developer, agrees with you 100%. Like all things security, this stance has plusses and minuses, but it's sensible.
If that's your choice, there's a premium on defending your system's attack surface, and maintaining due diligence. Since you've chosen Fedora, SELinux should be enabled (I know, there are a million recommendations to turn it off, all wrong) and a solid set of firewall rules should be in place. Certificate-only SSH might have prevented your last attacker from compromising the host, or a 14-character passphrase, or diligent log review. For example (fedora):
# ausearch -ts week-ago --success no --interpret
or maybe
# last -x
I recognize that most security recommendations present hurdles, SELinux configuration and firewall rules are no exception. I'm working on a suite of tools to help with that, but they're not ready for release.
Fedora seems to be at one end of a spectrum, with perhaps Slackware on the other end, where the above strategy seems a little weak. Fedora seems to push out changes quickly and with great tumult, not infrequently requiring patches to their patches. In contrast, Slackware releases after exhaustive testing and review, and doesn't seem to chase - or incorporate- moving targets. I'm not recommending one over the other, just trying to compare and contrast.
The developers for Fedora 13 were no smarter or dumber than the developers who are writing Fedora 36. Or pick your distro of choice.
I disagree. The previous generation of developers (Alan Cox was an exemplar) were more careful, thoughtful, and expert in their craft. Kids these days... Eventually they'll get better, maybe better than the Old Guard. But for now, there are a plethora of semi-skilled Kool Kids in the fray. Perhaps my view is jaundiced because I'm doing front-end (web) development this month.
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.
Again, some distributions are like mayflies, some are like elephants. Fedora is perhaps an unconventional choice for longevity.
-- Chuck Polisher
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
Quoting saclug@garymcglinn.com (saclug@garymcglinn.com):
Again sent earlier. Thanks for the intervening comments about vulnerabilities and versions.
Glad to. Hope they're useful.
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.
My instant reaction would be to think that having an RPC portmapper process running and exposed (TCP/UDP port 111) to public networks is... curious.
RPC portmappers have a troubling security history, although that's a complex story that includes but is not limited to them making firewalling complex to the point of near-impossibility, because by definition they hand out service port assignments to other services, and that alone is a challenge to control. Possibly, you're already fully aware of that.
The other thing that is curious about that is that, when I think of RPC portmapper daemons, I think of them as the foundation of NIS and NFS -- both of which are likewise security-challenging. Thus the old joke dating back to SunOS 2.0 days that NFS stands for "No Friggin' Security".
Theoretically the only pinhole in the ISP router firewall was port 23. To use port 5900, you had to use an ssh tunnel.
I'm curious what you use the RPC portmapper for, then, and how you manage the security of services handed ports by it.
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.
Well, let's talk about that.
Any host is going, over time, to require security maintenance, as to (at minimum, all software exposed to public data, which includes the kernel's network stack and all network services that use the network stack (and can be reached from public).
It is _absolutely_ feasible to adopt a set of software issued 15 years ago as part of a distro release, and for it to retain reasonable security going forward indefinitely, long past when distro security updates cease for that release -- _provided_ that you diligently assume manual security maintence duties from that time forward.
I may be doing a similar thing with my next server rebuild: I plan to have a very sparse, very hardened base system, that is just enough of a system to run KVM/qemu as a hypervisor. The system would then run two guest VM sessions, one of which would be my production server, the other the in-progress beta for its replacement.
In all likelihood (pending testing), I may compile my own host-system kernel in order to exercise maximum control on completely omitting code I don't absolutely need, so that it isn't present even as unloaded modules. And maybe I'll do the same for related code, maybe switching the libc to one of the minimal ones, and so on.
If I do that, then any such portion of the host-OS system will be outside the distro package regime, though I might bother to construct local packages so that the distro regime is aware of them, maybe with package pinning. The entire host-OS system would probably be under Ansible or Puppet configuration management, anyway.
But, the main point is, _you_ become the security maintainer of such a system. _You_ have to spend time reading CVEs and deciding what's system-relevant and what to do about it.
Backing up a bit, I'll confess I wasn't really paying close attention to your original "Hacked" posting eight days ago. If I understand correctly:
1. After noting an unexplained reboot,
2. you looked in "the audit log" and found successful SSH login (not by you) using a keypair, and some stuff about a service on a high-numbered port.
[Ugh, Mailman3's Hyperkitty archiver is _still_ dreadful.]
I'm not at all sure that initial entry was via ssh. That sounds quite improbable, for lots of reasons, including "how did the user's public key get into authorized_keys"?. OTOH, I have insufficient data to say what the avenue of entry was.
Going by your detailed description of the many things that the intruders changed and broke, it may be way too late to figure out for sure what the avenue of entry was. However, if you really _were_ running a 15-year-old Linux kernel, then don't forget that the public attack service includes the network stack -- and CVEs for the kernel get ignored for 15 years at your peril.
Typo patrol:
Going by your detailed description of the many things that the intruders changed and broke, it may be way too late to figure out for sure what the avenue of entry was. However, if you really _were_ running a 15-year-old Linux kernel, then don't forget that the public attack service includes the network stack -- and CVEs for the kernel get
^^^^^^^ "surface"
ignored for 15 years at your peril.
On Mon, Aug 08, 2022 at 09:39:34AM -0700, saclug@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
Quoting Brian E. Lavender (brian@brie.com):
There are probably a boat load of known vulnerabilities in F13.
The only way running Internet-exposed Fedora 13, even for a minimal host that's just barely enough of an OS build to support a hypervisor, in 2022, would involve the local sysadmin _completely_ having assumed and diligently carried out, without fail, all security maintenance _manually_ for all eleven years, since 2011-06-24, when Security Team coverage of F13 ceased permanently.
That would mean diligently reading all CVEs for all local components exposed to public traffic -- including the Linux kernel (especially its network stack), all public-facing services, and all of their libs and support utilities -- doing, as appropriate, paring of code/functionality, upgrading, mitigating, applying needed source patches, etc.
That could be done, by a sufficiently determined and well-prepared sysadmin who wishes to hand-maintain a very minimal system for locally-compelling reasons. Gary, _did_ you do all that?
If you didn't, Gary, that's likely a key part of your problem. And dismissing the problem of need to plug proven security holes with "the upgrade treadmill is that it is a waste of time" is a reminder that denial isn't a river in Egypt.
The work of managing your own distro even for a device like a media server or handheld gameplayer around the turn of the century was a huge task that's broken more than one admin but almost manageable as long as you didn't have to do the custom apps too but that was long before the opensource eco-system puddle swole up into an ocean. Think you'd need a team of at least 4-6 to do it now. Freezing a version forever is not even an option today, waiting until it's hacked aka letting your users find the bugs never was.
On Thu, Aug 11, 2022 at 4:09 PM Rick Moen rick@linuxmafia.com wrote:
Quoting Brian E. Lavender (brian@brie.com):
There are probably a boat load of known vulnerabilities in F13.
The only way running Internet-exposed Fedora 13, even for a minimal host that's just barely enough of an OS build to support a hypervisor, in 2022, would involve the local sysadmin _completely_ having assumed and diligently carried out, without fail, all security maintenance _manually_ for all eleven years, since 2011-06-24, when Security Team coverage of F13 ceased permanently.
That would mean diligently reading all CVEs for all local components exposed to public traffic -- including the Linux kernel (especially its network stack), all public-facing services, and all of their libs and support utilities -- doing, as appropriate, paring of code/functionality, upgrading, mitigating, applying needed source patches, etc.
That could be done, by a sufficiently determined and well-prepared sysadmin who wishes to hand-maintain a very minimal system for locally-compelling reasons. Gary, _did_ you do all that?
If you didn't, Gary, that's likely a key part of your problem. And dismissing the problem of need to plug proven security holes with "the upgrade treadmill is that it is a waste of time" is a reminder that denial isn't a river in Egypt.
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
Anyone who is in charge of security on systems for an organization of any size should do all those things anyhow. Vendor support may not be focused on the requirements of a specific organization. Most security is driven by configuration and organizational policy. The vast majority of hacks are social. I used to go though all the attack vectors, but nothing ever applied to me. I got tired or reading about how firefox had a vulnerability because a page running on a tab other than the current one, could open a window.
My system, which is reasonably secure, has just been running for 15 years or so. I've been doing a lot of rebooting and I notice the BIOS boot screen says something about indestrutable and list a bunch of hazards like humidity that I am protected from. Maybe it will last another 15 years :).
I could probably just ignore the hack and be fine. What do I have to steal? Some tax returns and meatloaf recipies. All the things I wanted to keep private 15 years ago are now routinly stolen. My contacts, where I've been, who I saw, and my correspondence. As a public servant, my salary is public. If tax returns are made public, and there is occasional talk about that, it will only leave the meatloaf recipies.
So, no, for this system, I don't spend time doing all the security activities that I would if I had an organization with data that needed to be protected. Getting bricked is no fun, I'll admit, but it isn't the end of the world either.
I enjoy learning and using the technology. I'll beef some things up and give it a whirl. Review what I back up. I missed my raid scripts. Basically, I want security and privacy just because I should be able to have these things. I'd like to get back some of the privacy I've lost, but I seem to be alone in that.
-Gary
On Thu, Aug 11, 2022 at 03:08:55PM -0700, Rick Moen wrote:
Quoting Brian E. Lavender (brian@brie.com):
There are probably a boat load of known vulnerabilities in F13.
The only way running Internet-exposed Fedora 13, even for a minimal host that's just barely enough of an OS build to support a hypervisor, in 2022, would involve the local sysadmin _completely_ having assumed and diligently carried out, without fail, all security maintenance _manually_ for all eleven years, since 2011-06-24, when Security Team coverage of F13 ceased permanently.
That would mean diligently reading all CVEs for all local components exposed to public traffic -- including the Linux kernel (especially its network stack), all public-facing services, and all of their libs and support utilities -- doing, as appropriate, paring of code/functionality, upgrading, mitigating, applying needed source patches, etc.
That could be done, by a sufficiently determined and well-prepared sysadmin who wishes to hand-maintain a very minimal system for locally-compelling reasons. Gary, _did_ you do all that?
If you didn't, Gary, that's likely a key part of your problem. And dismissing the problem of need to plug proven security holes with "the upgrade treadmill is that it is a waste of time" is a reminder that denial isn't a river in Egypt.
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
Quoting saclug@garymcglinn.com (saclug@garymcglinn.com):
Anyone who is in charge of security on systems for an organization of any size should do all those things anyhow.
No, that would be insane.
My system, which is reasonably secure
O RLY?
Good luck to you. Peace, out.
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@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@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
It's a rare day when I don't patch FC38.
On Wed, Sep 13, 2023 at 3:09 PM lug-nuts@bigbrie.com wrote:
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@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@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
Lug-nuts mailing list -- lug-nuts@bigbrie.com To unsubscribe send an email to lug-nuts-leave@bigbrie.com
-
Brian E. Lavender -
Charles Polisher -
Linus Sphinx -
lug-nuts＠bigbrie.com -
Rick Moen -
saclug＠garymcglinn.com