BALUG-Talk March 2018

balug-talk@lists.balug.org

4 participants
4 discussions

(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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

BALUG-Talk March 2018