BALUG-Talk

balug-talk@lists.balug.org

142 discussions

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

(forw) [svlug-announce] SVLUG Nov. 1st meeting: Rob Walker on MythTV and Kodi Lecture and Demo
by Rick Moen 31 Oct '17

31 Oct '17

Come if you can, as this should be a really good one. ----- Forwarded message from Rick Moen <rick(a)linuxmafia.com> ----- Date: Tue, 31 Oct 2017 14:20:59 -0700 From: Rick Moen <rick(a)linuxmafia.com> To: svlug-announce(a)lists.svlug.org Subject: [svlug-announce] SVLUG Nov. 1st meeting: Rob Walker on MythTV and Kodi Lecture and Demo WHEN: Wednesday, November 1st, 2017 7 - 8:30pm MAIN PRESENTATION TOPIC: MythTV and Kodi Lecture and Demo PRESENTED BY: Rob Walker TOPIC SUMMARY: MythTV (https://www.mythtv.org/) is a free and open source software digital video recorder (DVR) project, distributed under the terms of the GNU GPL. Kodi (https://kodi.tv/ , formerly XBMC) is a free and open source media player application developed by the XBMC/Kodi Foundation, a non-profit technology consortium. Rob will demonstrate his MythTV and Kodi setup, and show how he's been using it over the years. ABOUT THE PRESENTER: Rob Walker was introduced to Unix in 1995 has been using Linux since 1997. He has helped other people use Linux at companies like VA Research, Silver Spring Networks, and others. He has been using MythTV off and on since 2006, and Kodi since 2014. LOCATION: Cavium cafeteria 2315 N 1st St. (corner of Charcut Ave.) north San Jose Directions on how to get there are listed at: http://www.svlug.org/directions/cavium.php <--- maps here! We've tried our very best for these directions to be accurate. If you have any improvements to make, please let SVLUG's volunteers know! webmaster(a)svlug.org POST-MEETING GATHERING (if you want): La Victoria Taqueria, 1415 N 4th St. near Gish Road, San Jose. Go south 0.7 miles on N. 1st St. under US-101, then turn half-left onto Matrix Blvd., in 0.3 miles a slight right onto N. 4th Street, 0.5 miles to La Victoria on your right just before Gish Road. We look forward to seeing you there! _______________________________________________ svlug-announce mailing list svlug-announce(a)lists.svlug.org http://lists.svlug.org/lists/listinfo/svlug-announce ----- End forwarded message -----

1 0

operation appears to have been a success: hardware issues
by Michael Paoli 31 Oct '17

31 Oct '17

Ah, and appears the operation has been quite successful ... the "patient" got a body transplant, and is doing much better now. Essentially brain of patient (~150 GB SSD) was successfully transplanted out of ailing body (Zareason Strata 6880) into apparently good healthy donor body (Dell P10E001 Precision M6600). Also completed successful live migration of the balug VM back from physical host "vicki" ... which nominally resides under the brain of the patient, but was live-migrated away to "vicki" while the patient's brain was in suspended animation for a while during the patient's operation. More later, but thus far all looking quite well. :-) Also, before the operation, the donor body was well prepped, with a BIOS upgrade - notably covering some critical Intel vulnerabilities, and had been reasonably tested to apparently be suitably healthy donor. Some slight adjustments to /etc/udev/rules.d/70-persistent-net.rules were made to squash any transplant rejection symptoms, and all is looking quite well. > From: "Michael Paoli" <Michael.Paoli(a)cal.berkeley.edu> > To: "Rick Moen" <rick(a)linuxmafia.com> > Cc: BALUG-Admin <balug-admin(a)lists.balug.org> > Subject: Re: [BALUG-Admin] (forw) [Bug 1707447] Re: Roster should > not lowercase addresses > Date: Thu, 26 Oct 2017 22:34:36 -0700 > In the meantime ... I've also got some hardware issues pestering > me :-/ ... my primary personal laptop ... alas, my last response I > got from Zareason was essentially it's "too old" for them to get > parts (and it's not *all* that old) ... and also one significant > part of the (potential) repair ... well, if part can no longer > be had (GPU/video integrated onto mainboard) - that's effectively > irreparable - even if part was available, it's not economically > feasible. The *first* mainboard failed with GPU failure not long > after the 1 year warranty (at least I think it was before the 2 year > mark). I'm not sinkin' that kind'a money into it yet again if that > manufacturer's (it's an Intel OEM laptop) hardware - or at least for > that particular mainboard and compoenents thereupon, is that unreliable. > At the *moment* the video is working, ... but often when the laptop is > rebooted or powered up ... the video doesn't work (can only > barely/marginally make out / guess what's on the screen when it's > flaking out ... and not OS or the like - the problem even applies to > BIOS screens). So ... that issue bit me again this morning, and took > until many reboots this evening before the video is displaying again > properly ... for now. Not to mention ... keyboard ... both "N" and "O" > keys failed ... and that's 2nd keyboard on the laptop ... using external > USB keyboard on it now. But I did pick up for excellent price > (free, "miracle of the free curbside giveaway") a Dell P10E ... which > as far as I've seen thus far (still need to check it out further) appears > to be fine, and is a good approximate replacement (even better in several > ways - includes eSATA, 4 USB ports (1 more than existing laptop), supports > two internal regular laptop SATA drives (spinning rust and/or SSD) ... > anyway, I'll probably cover more of that else-thread (and/or else-list) > in fairly near future ... but if that hardware checks out good, I'm > exceedingly inclined to move over to that laptop. > But I digress (ah, topic drift) ...

2 4

← Newer
1
2
3
4
5
6
7
8
9
...
15
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

BALUG-Talk