JDPFu.com 2025

EFF Security Starter Pak

Sections:

1. An Introduction to Threat Modeling
2. Communicating with Others
3. Creating Strong Passwords
4. What Is Encryption?
5. Keeping Your Data Safe
6. Protecting Yourself on Social Networks
7. Choosing Your Tools

Lots of great tips and techniques in that article.

LXC is getting easier and easier to use.
Flockport seems to be the easiest way to stay mostly standard, yet still be LXC-based.

It doesn’t seem to be as flexible or complex as Canonical’s Juju’s or Docker’s highly advertised stuff. Docker is great at advertising, just sayin’.

Flockport seems to be exactly what I needed – mostly standard, easy to use, LXC deployments for development and testing. Not planning to use any for internet-facing needs. Just too new with LXC to be comfortable trusting the security and my skill to know about the unpublished issues (security and others) with containers. For spinning up a quick internal web-app instance … perfect.

Sometimes you just need a simple DLNA server.
Rygel is just that. Easier than miniDLNA, lighter than all the others like Plex Server.

I didn’t have to configure anything – it sorta just worked.

It works with the BubbleUPnP Android DLNA server/client/renderer and with every other DLNA client that I’ve tried – though we use a plex server most of the time.

Every time I read the ssh manpage, I learn something new. This is after over 15+ yrs of using ssh. It is an amazing tool. It is the sonic screwdriver for UNIX systems connectivity.

But ssh does more than just normal connectivity stuff. Much more.

Everyone could learn a little more about ssh and stop doing things the hard way – PLUS using ssh is likely more secure than whatever we are doing today. Win-Win. Both more efficient AND more secure. How often does that happen in the real world?

For example, did you know that vim supports remote editing of files through ssh and rsync?

$ vim rsync://dev/projects/gallery/src/templates/search.html.tt

Smylers’s article SSH Can Do That? Productivity Tips for Working with Remote Servers is a great resource for all these magical techniques. I won’t repeat it here – let’s just say that in 15+ yrs using ssh, I learned 4 new, useful, things from that article. Time to get modifying my ~/.ssh/config files now.

If you are completely new to ssh features, here’s a nice, short, article from diogemelo to get you started. These are fairly standard uses.

ssh is enough for

• secure remote access to files via sftp
• secure remote filesystem access via sshfs
• secure remote CLI/shell access to systems with plain ssh
• secure remote desktops via x2go/freenx
• secure remote file replication with rsync (ssh is the default rsync protocol)
• secure port forwarding of selected ports
• secure remote editing with vim/gvim and other editors
• pseudo-VPN with sshuttle <— this may be helpful.

ssh really is the toolbox for remote connectivity.
A good resource about all things ssh is the wikibooks OpenSSH Client Conf entry.

Of course, ssh security doesn’t start and stop with using keys. We need to do more.

Are there great ssh things that you know NOT in his article?

At CloudSlam’14, it has been presented that 1 of 3 companies experience data loss from their cloud providers. That’s 1/3rd of them!

• 64% is due to user error – we are our own worst enemy!
• 20% is due to malicious intent. Hackers, sometimes insiders are just being mean.
• 7% is due to application sync errors. These are integration providers that hook into other SaaS apps.

If you have an Acer C720 – GREAT! These are amazing systems. But some of the hardware support out-of-the-box from Linux isn’t perfect. What if running 1 little script can fix that?

Verified to work with Ubuntu 14.04 x64 on a C720.

I’ve been traveling overseas more and have discussed security issues with others in the IT security industry. Here is what I’ve decided.

With the recent HeartBleed issue in the openSSL libraries that impacted 80% of websites and the GnuTLS issue from last month, what should we do when security is needed most?

BTW, the NSA admitted to using the HeartBleed bug for years. My 20 yrs of professional experience with software tells me that there are probably 50 other issues like this in the openssl and gnutls software libraries. They are the best options for HTTPS traffic, but really shouldn’t be trusted when real security is needed.

What do I do?

Scripting 101

• always fully specify paths to all programs and files (input/output) inside any script. NEVER trust the PATH.
• always set any environment variables necessary to the script. Don’t trust the userid environment to be available during cron. JAVA_HOME is an example, but there are thousands of others – most scripts need fewer than 5 environment variables.
• use the -x to see what a script does. bash -x
• use built-in “verbosity” settings for any specific command; often -v or -vvvv for more output.
• Unix uses file permissions to control if a script is "executable or not. Extensions mean ZERO. Is your script permissions set to allow the userid trying to run it to see “execute” permissions?
• check the log files – client-side AND server-side.
• break down the problem inside the script to the simplest command.
• do NOT use GUI programs inside any scripts that need to run automatically. Look for the CLI version of the tool and use that instead.
• For scripting used by the public – websites – always review the code against the OWASP checklist for that language. They have a nice Top 10 list too. Guides for C, C++, Perl, Bash, Php, Python, Ruby …. try to learn from
• For bash scripting, the ABSG covers almost everything possible. For other languages, there are many, many books, websites, webpages to help.

Update: Jump to the “Better Article” header below. My stuff here isn’t as helpful as his.

Picked up an Acer C720 (2G RAM version-bummer) yesterday. I had ZERO intention of running ChromeOS … ever. The machine has a fairly powerful CPU – an Intel Celeron 2955U. That CPU is like an Intel E6600 Core2Duo desktop – inside a NETBOOK with 8+ hrs of battery! With the SSD – it should be FAST, very FAST!

That Phoronix article says this C720 is faster than an old MacBook Pro with a Core i5 520m CPU! I have a Dell laptop with that same CPU and I don’t think this netbook is faster. Then again, the full laptop has 6G of RAM, 500G HDD, GigE wired networking, and discrete ATI Radeon GPU w/ 1080p local and both HDMI and VGA out (driving 2×24″ 1200p monitors) – 6lbs. Different machine for a different purpose.

So I needed to learn a few things to get Ubuntu on the machine. Below are my notes.

I will point out that I never connected any gmail account to use the C720 and barely used ChromeOS in guest mode.

The network here has been ready for Jumbo frames on our GigE connections for years – many years. Network performance was always fine, so I never bothered to configure jumbo sized ethernet frames.

Until last week.