BALUG-Talk

balug-talk@lists.balug.org

1 participants
154 discussions

Go back and record raw symptom data (was: BALUG list(s) unsubscribe)
by Rick Moen 11 Jun '18

11 Jun '18

Expanding audience beyond just the balug-admin mailing list. ----- Forwarded message from Rick Moen <rick(a)linuxmafia.com> ----- Date: Tue, 15 May 2018 15:46:49 -0700 From: Rick Moen <rick(a)linuxmafia.com> To: Michael Paoli <Michael.Paoli(a)cal.berkeley.edu> Cc: balug-admin(a)lists.balug.org Subject: Re: BALUG list(s) unsubscribe Organization: If you lived here, you'd be $HOME already. Michael, let me recap points I made in our offlist discussion involving trying to help the guy who insists unsubscribing 'doesn't work'. In the case of such a user: 1. It's useless merely asking the subscriber 'What steps you're following?', because the subscriber doesn't remember. Comment: If you're serious, stress the need to _reproduce_ the problem and take accurate notes. 2. It's useless merely asking the subscriber 'The error diagnostic(s) (if any) you're getting', because the subscriber doesn't remember. Comment: As above. 3. It's useless merely asking the subscriber to provide 'FULL EMAIL HEADERS of an example message', because the subscriber has no idea how. (Shouting doesn't clarify.) Comment: The user may not even know what a 'header' is, at all. If he/she does, the current ones look pretty 'full'; what does 'full' mean? They've probably never seen full headers, and wouldn't know them from an anaconda. If you're serious, best solution would be to provide two image files, showing the same message with truncated vs. full headers, and say 'See how the full version has many your mailer normally hides for simplicity? Notice the ones starting with Received? Those and more are needed for diagnosis. Dig in your mailer for a means to reveal them that might be called "Show original" or "Show source", but might be called something else.' 4. It's pointless to admonish the subscriber to never furnish his/her subscription password to the listadmins, as the listadmins have full power to do mischief if they're Bad People, without such passwords. And telling 'I can't unsubscribe' people that is just a pointless distraction from their real problem. Comment: Seriously, users haplessly mailing their subscriptions around the Internet is very close to harmless to them. Them mailing those to listdmins is _totally_ harmless. Neither risk is worth dwelling on, especially in an instructional mail the user is already going to find both challenging and a little offputting. On points 1-3, I'm very, very much reminded of hard lessons learned from CABAL's long history running public installfests. When we started doing that in 1998, we brightly and optimistically hoped and expected attendees would download and fill out a simple hardware questionnaire, e.g., how much RAM, what CPU, how big hard drives. As other 1990s LUGs around the world also found out, this was a total, whopping flop. I think it flopped so hard that we deleted the questionnaire out of sheer disgust, though some other early CABAL materials survive here: http://linuxmafia.com/pub/linux/cabal/ Note in particular the CABAL FAQ that Don Marti and I co-wrote: Some of that excess optimism about attendees being able to pony up information about their computers survives in parts of the FAQ. The hard lesson was: They don't know. Which means, if you're serious about getting that information accurately out of them, you need to either teach them or furnish an automated software tool to gather it. The best answer we got (to the questionnaire) was no answer. But some attendees figured they needed to write down something to make the organisers happy, so they took wild guesses about, say, how much RAM their machines had, and tended to be hilariously wrong. (Needless to say, guesses were worse than lack of answers.) Why don't they know? Because they never bothered to figure out how to get those answers, and didn't know where to start. Even though, say, the POST RAM count whizzed by their eyes every time they booted (well, until OEMs started hiding the POST process behind pretty pictures), they lacked the curiosity to poke at the machine and investigate to answer obvious questions. But, the subtler problem: Sometimes they _once_ knew, but forgot what they used to know, and figured a retrospective attempt to guess from dim and fading memory was good enough. _You and I_ know that getting reliable information from a computer means producing it contemporaneously and capturing / writing it down _then_. But amateurs make the error of trying to just remember this stuff -- _all the time_. I had been co-author of 'How to Ask Questions the Smart Way' for untold years when the insight of people totally failing to capture contemporaneous diagnostic data hit me like a ton of bricks. I had kept on, for years, trying to convey the right message to readers through cute, clever word tricks like this 'Missouri' one in the essay: Describe the problem's symptoms, not your guesses [...] Since the preceding point seems to be a tough one for many people to grasp, here's a phrase to remind you: "All diagnosticians are from Missouri." That US state's official motto is "Show me" (earned in 1899, when Congressman Willard D. Vandiver said "I come from a country that raises corn and cotton and cockleburs and Democrats, and frothy eloquence neither convinces nor satisfies me. I'm from Missouri. You've got to show me.") In diagnosticians' case, it's not a matter of skepticism, but rather a literal, functional need to see whatever is as close as possible to the same raw evidence that you see, rather than your surmises and summaries. Show us. Describe your problem's symptoms in chronological order [...] Users, even people familiar with the essay, kept posting their guesses and not raw diagnostic data. Why? I figured it out: Because the raw data scrolled off the screen and into fading memory, and the user wasn't smart enough to go re-acquire it. If I'd been in the room with that user, I'd have said 'What? Wait, you _didn't_ go back and reproduce the symptom a second time so you can take accurate notes? What sort of crazy approach is that? Why the hell not?' But they don't know -- and, being remote from them across the Internet, we can't see them screwing it up, and are unaware of them flubbing the ground-level basics. My real epiphany involved the least competent poster to the OCLUG (Orange County LUG) mailing list, a guy who's always posting vague requests for help and supplies about 70% of the mailing list's traffic. At one point, he provided a supposed diagnostic message that was _obviously_ grossly inaccurate for reasons including misspellings, and, suddenly realising the key problem, I asked 'You typed that from memory, didn't you?' He was a little cagey, but the answer was yes. I patiently pointed out that helpers would be attempting to Web-search the diagnostics, so inaccurate transcription was fatal. 'Oh.' And _why_ did he type it from memory? Because it just never occurred to him to reproduce the problem (taking accurate notes, this time) _before_ asking for help. Remember: They don't 'get' these rock-bottom basics. Just not. If they did, they wouldn't be in endless trouble. And frankly, anyone who cannot figure out how to unsubscribe given help in every posting footer and bountiful help on the Web is self-selected in advance for exactly that kind of haplessness. ----- End forwarded message -----

1 0

BALUG: June meeting: DC/OS; May meeting (perhaps) general discussion with topic: Security for Developers from a Sysadmin Perspective
by Michael Paoli 06 May '18

06 May '18

More to be on web site soon, and then announcements ... We've recently confirmed Elizabeth Krumbach Joseph for 2018-06-19: the open source version: DC/OS (the datacenter operating system) description and "slides" from earlier similar: http://lists.netisland.net/archives/plug/plug-2017-08/msg00038.html https://princessleia.com/presentations/2017/Introduction_to_DCOS_PLUG_West_… And this month - 2018-05-15 - don't have a speaker/presentation lined up or confirmed, but I was thinking possibly, if we don't come up with something else soon, perhaps discussion topic: Security for Developers from a Sysadmin Perspective (notably including: least privilege, permissions, users/groups, isolation/containment, architecture, trust relationships, etc.) ... or how to tell developers & architects to plan/do accordingly to avoid security pitfalls (other than the typical code booboos and weaknesses that they're often relatively well aware of ... thinking more the "everything else" - notably in the context of Linux - that they often don't think quite as much about but ought more fully consider and be aware of).

1 0

Open Hack 2018
by Sameer Verma 27 Apr '18

27 Apr '18

Greetings! You may remember our OLPC San Francisco Community Summit from a few years ago. We ran the summit 2009 thru 2016. We didn't host one last year due to logistical challenges and such, but we are getting ready to host one next weekend! We have joined forces with FOSS, open data, and open education communities at San Francisco State University to organize a weekend hackathon. Details here: https://www.olpcsf.org/node/265 Registration: https://www.eventbrite.com/e/open-hack-sf-2018-san-francisco-state-universi… I hope to see you there. cheers, Sameer -- Sameer Verma, Ph.D. Professor, Information Systems San Francisco State University http://verma.sfsu.edu/

1 1

(forw) Re: [conspire] Servers and security
by Rick Moen 30 Mar '18

30 Mar '18

Lobbing over a copy of what I posted on the _other_ mailing list Kim posted to (CABAL's Conspire mailing list). On reflection, I really do (even though I'm promoting something *I* wrote, so dismiss this as megalomania if you wish) recommend the summary I wrote at the bottom of 'Security Snake Oil' on http://linuxmafia.com/kb/Essays/ . Quoting: Looking from the open source Linux/BSD community perspective, the entire commercial anti-malware / computer security industry is basically founded on intellectual fraud, and its recommendations are absurd. Real security rests on these principles: 1. You, the user, are responsible for what processes you choose to run. Therefore: 2. Don't download and run processes off the Internet you have no reason to trust, including "postcards", supposed video codecs, games, antivirus software from firms you've never heard of, "Internet accelerators" from firms you've never heard of, and so on. 3. Try not to run avoidable software that is known to be badly written and have ongoing security problems. (This is a central point of several of Marcus Ranum's security essays.) 4. Use only maintained operating systems and applications (i.e., ones for which you get and apply security updates). 5. Don't do stupid chump moves just because a piece of software that you have no reason to trust asks you to (including providing your root-user access credentials). 6. If something seems not quite right, e.g., a request to accept a file via Bluetooth pops up that you weren't expecting, assume that it's against your interests. 7. Subscribe to the security alert announcements mailing list for your operating system / distribution, and skim-read for any relevant to your situation. Really, item #1 actually covers the subject: The others just elaborate further on that concept, and are ramifications of it. I immodestly aver that a lot of the rest of what follows is also userful, to the best of my ability. ;-> ----- Forwarded message from Rick Moen <rick(a)linuxmafia.com> ----- Date: Thu, 29 Mar 2018 15:41:31 -0700 From: Rick Moen <rick(a)linuxmafia.com> To: conspire(a)linuxmafia.com Subject: Re: [conspire] Servers and security Organization: If you lived here, you'd be $HOME already. Quoting Kim Davalos (kdavalos(a)sonic.net): > Curious about what folks due to harden/secure their servers. > Specifically I am NOT asking to be told what to do/how to do it. > > More interested in hearing about different practices and approaches, > e.g., firewall management - iptables/nftables vs something like > Check Point, limiting installed packages to what is necessary, > closing unused ports, access restrictions, etc. > > Best would be vigorous debate and disagreement. A friendly thanks to Carl Myers and Mark Weisler for their comments about threat models and assessing what is at risk. I recommend a couple of items to you as background reading, to get a good perspective on how to think about these matters and decide what is sensible and what is not. 1. First edition of Bill Cheswick and Steve Bellovin's classic text _Firewalls and Internet Security: Repelling the Wily Hacker_, which the authors make freely available on the Web. (The 2nd edition is available for sale.) http://wilyhacker.com/1e/ This book made a big impression on me as a larval-stage sysadmin, not because I was constructing firewalls but rather because it taught me how to think usefully in this area (security) and cultivate the right habits. Cheswick and Bellovin stress along the way that, to do security right, you need to understand the fundamentals of whatever thing you're concerned about, understand the mechanisms involved, understand the components. Without to the best of my recollection needing to explicitly belabour the point, they taught me the concept of 'attack surface' and that simple code with only the minimum functionality is much less of a problem than the alternative. Most particularly, reading Cheswich and Bellovin, and learning their way of thinking, will protect you against the lure of gadget-freakery, e.g., 'I run a lot of overfeatured and vulnerable network-facing software and aren't even certain what ports software listens on, but I'll paper over any problems with more layers of software such as iptables rulesets.' Instead, you'll think 'I have a better idea. I'll not expose vulnerable software to public attack (switch it out for better-designed software), and I'll know what ports accept connections. If I do that, then port-blocking incoming connection attempts to ports where there's no network listener is pointless.' You'll hear from slightly smarter gadget-freaks 'I'm nervous about ongoing attempts from random Internet locations to guess weak username/password combinations during connections to my ssh daemon, so I'm going to allow only connections from a single outside IP (or use complicated schemes like port-knocking, or crazy evasion like moving the sshd to a non-standard port).' Having read Cheswick and Bellovin, you'll think 'Wait, if my system disallows weak passwords, attempting to guess into my sshd is going to take longer than the heat death of the universe. And if I haven't yet disallowed weak passwords, that's the actual problem to solve. And if weak passwords _do_ exist, they're just as weak on a non-standard port, so again, that's solving the wrong problem.' With the right soft of thinking, you'll not only install only packages that are necessary but also carefully control the configured functionality of installed packages, keeping it down to only what's needed. (This of course is most crucial for software that is public-facing or runs with elevated privilege.) Additionally, you will cast a skeptical eye on _choice_ of software packages. E.g., if you need a public-facing host to do authoritative DNS nameservice but don't need it to also do recursive service (e.g., because you have wisely located recursive service you need onto a protected inside machine), then you won't deploy the ridiculously overfeatured BIND9 software on the public-facing host but rather a modern, spare, authoritative-only daemon such as NSD. 2. A bunch of the writings of mordantly funny BSD and security guy Marcus J. Ranum making much of the same points, and similar ones. E.g.: http://www.ranum.com/security/computer_security/editorials/master-tzu/ http://www.ranum.com/security/computer_security/editorials/dumb/ http://www.ranum.com/editorials/must-read/ (concerning Feynman) Reading Cheswick & Bellovin, and reading Ranum, will also appeal over time as you find out what utter bullshit about 75% of what you read about security is, because going back to them will seem refreshing. Some of that security foolishness is native-grown within the Linux community, but a lot of it is from commercial security / antimalware firms accustomed to bullshitting and stampeding the public. Case study: 'Security Snake Oil' on http://linuxmafia.com/kb/Essays/ I will also, in a possible violation of modesty, recommend the Linuxmafia.com Knowledgebase's Security category as a decent starting place: http://linuxmafia.com/kb/Security/ There are even a few articles by that Moen guy listed, such as the 'Attacking Linux' one, that you might find useful. ----- End forwarded message -----

1 1

Servers and security + Pen-testing(?)
by acohen36 30 Mar '18

30 Mar '18

Kim Davalos <kdavalos(a)sonic.net> wrote: > > Curious about what folks due to harden/secure their servers. > Specifically I am NOT asking to be told what to do/how to do it. > > More interested in hearing about different practices and approaches, > e.g., firewall management - iptables/nftables vs something like Check > Point, limiting installed packages to what is necessary, closing unused > ports, access restrictions, etc. *Some* of what Michael P previously wrote at much further length regarding the above are also mentioned at nixCraft's ''40 Linux Server Hardening Security Tips [2017 edition]'', https://www.cyberciti.biz/tips/linux-security.html IMHO, I think that the nixCraft article is less complete but better organized than Michael P's extensive prose. Also, security expert Bruce Schneier has excellent Security writings on his ''Schneier on Security'' blog and essays websites; https://www.schneier.com/ and https://www.schneier.com/essays/ respectively. AAMOF, I found Schneier's blogpost ''Choosing Secure Passwords'' at https://www.schneier.com/blog/archives/2014/03/choosing_secure_1.html extremely relevant and even _better_ than tips #8 thru #10 at nixCraft's ''40 Linux Server Hardening Security Tips [2017 edition]'' There are Linux distros specifically designed to Penetration Test ("pen-test") how efficient your/one's Server Security setup really is after-the-fact. Two such pen-testing distros I'm distinctly aware of from previous discussions at SF-LUG.com are Kali Linux -- https://www.kali.org/ -- and The Parrot System -- https://www.parrotsec.org/. Another distro invariably mentioned by others is The Amnesic Incognito Linux System a.k.a., TAILS (https://tails.boum.org/ ), but I get the distinct impression that TAILS (as great as it is) is more for Privacy than it is for Security and Pen-testing. BTW, SF-LUG is having their next live meeting at SF's Cafe Enchante this Easter Sunday April 1st, from 11am to 1pm; see http://linuxmafia.com/pipermail/sf-lug/2018q1/013112.html Well, that's my even-briefer two cents. -A acohen36(a)sdf.org SDF Public Access UNIX System - http://sdf.org

1 0

Servers and security
by Kim Davalos 29 Mar '18

29 Mar '18

Curious about what folks due to harden/secure their servers. Specifically I am NOT asking to be told what to do/how to do it. More interested in hearing about different practices and approaches, e.g., firewall management - iptables/nftables vs something like Check Point, limiting installed packages to what is necessary, closing unused ports, access restrictions, etc. Best would be vigorous debate and disagreement.

2 1

letsencrypt.org wildcard SSL/TLS certs available, now covering balug.org, ... :-)
by Michael Paoli 17 Mar '18

17 Mar '18

Letsencrypt.org recently started making production wildcard certs available. https://community.letsencrypt.org/t/acme-v2-production-environment-wildcard… Now also covering balug.org :-) (and sf-lug.org, sf-lug.com) $ TZ=GMT0 nmap -6 -Pn -r -sT -p 443 --script=ssl-cert www.balug.org | egrep -e '^(Nmap scan report for |Other addresses for |\| (ssl-cert: Subj|Subject Alt|Not valid a))' Nmap scan report for www.balug.org (2001:470:1f05:19e::2) Other addresses for www.balug.org (not scanned): 198.144.194.238 | ssl-cert: Subject: commonName=*.balug.org | Subject Alternative Name: DNS:*.archive.balug.org, DNS:*.balug.org, DNS:*.beta.balug.org, DNS:*.ipv4.balug.org, DNS:*.ipv6.balug.org, DNS:*.new.balug.org, DNS:*.php.test.balug.org, DNS:*.secure.balug.org, DNS:*.test.balug.org, DNS:*.wiki.balug.org, DNS:balug.org | Not valid after: 2018-06-15T07:39:09 $

1 0

Last month's meeting: Perky Planck Prototype (PPLP) - home-brew implementation of the Perky Planck, an open source, blind-optimized portable computer, ...
by Michael Paoli 19 Feb '18

19 Feb '18

Last month's meeting was well attended, many interesting discussions, and we also had developer of the Perky Planck Prototype (PPLP) - home-brew implementation of the Perky Planck, an open source, blind-optimized portable computer, complete with prototype at the meeting, etc. http://wiki.cfcl.com/Projects/Perky/PPLP

1 1

BIOS zapping bug: Ubuntu 17.10 / *buntu 17.10
by Michael Paoli 22 Dec '17

22 Dec '17

Generally not advised to install Ubuntu 17.10 presently, at least on certain hardware. There's a nasty bug that causes serious problems with BIOS (as in prevents ability to boot from USB or alter BIOS settings). https://www.theregister.co.uk/2017/12/21/ubuntu_lenovo_bios/ https://linux.slashdot.org/story/17/12/20/1724244/ubuntu-1710-temporarily-p… etc. Canonical apparently plans to re-release 17.10 (hopefully with a distinguishing point version number?) after this issue is corrected.

3 2

BALUG email is up again (was down 2017-11-30), balug VM updated, ...
by Michael Paoli 02 Dec '17

02 Dec '17

BALUG email was down on 2017-11-30, it's back up again. Sorry for any inconvenience. I may put more details on relevant BALUG list(s) sometime later. In the meantime, for the interested/curious, see: http://linuxmafia.com/pipermail/sf-lug/2017q4/013009.html And as for the balug VM (which hosts most everything BALUG), on 2017-11-30 it was updated from: Debian GNU/Linux 8.9 (jessie) x86_64 (oldstable) to: Debian GNU/Linux 9.2 (stretch) x86_64 (stable) excepting for the (non-Debian caused) email glitch, all went quite smoothly and service interruption was quite minimal. Key among minimizing service downtime in general, under: https://www.debian.org/releases/stretch/amd64/release-notes/ch-upgrading.en… followed the procedures for: "If the system being upgraded provides critical services for your users or the network[2], you can reduce the downtime if you" ... and additionally, obtained/downloaded all needed packages in advance. E.g.: # apt-get -y -d upgrade; apt-get -y -d dist-upgrade ... and that was after pre-filling cache (/var/cache/apt/archives/) with .deb packages I already had (from earlier downloads of package(s) and/or on Debian ISO(s)).

1 0

← Newer
1
...
4
5
6
7
8
9
10
...
16
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

BALUG-Talk