Monthly Archives: May 2017

Oh the Tangled Web…

Regarding security failings…

The long and the short… the vast majority of security failings fall into these general categories… both behavioral and technical.

  1. Slow, Bad or Non-existent Patch Cycle
  2. Poor CONFIGURATION decisions
  3. Installing to much software of debatable value (and forgetting about it).
  4. The required use of legacy systems with ZERO compensating controls
  5. Fire-and-forget mentality (i.e. long term complacency or laziness)
  6. Not knowing your limits, unwilling to accept limits, being too cheap or not having enough funding (which all has to do with heeding your local professionals, paying for some or living with centralized services which might not be as flexible [for similar reasons]).
  7. No situational awareness of the current network’s configuration or defenses, again, an assumption of defacto protection when there is generally near zero protection. This also falls under the category of assuming someone else is defending you (that always makes me smile because it’s just… soooo wrong…).
  8. Being unware that some of your habits/behaviors, for good or ill, contribute deeply to your susceptibility (poor passwords, never changing them, having accounts on every website or service under the sun with the same passwords, etc).
  9. The very wrong assumption that no one wants to hack your machine (hint: they couldn’t give a rats-*ss about you or your unimportant data [selfies, cat pictures, great American Novel, etc]… it’s the equipment they want access too, you are barely part of the equation).

In all cases… bad decisions, foolish assumptions and fatal mistakes.

Make noooo mistake on this… your devices are targets, mainly because they are a working piece of equipment built on a lot of risky decisions and false assumptions.

In the end, I would say, heed experts. But this is not enough, you have to be able to think a little too and live within your limits. Technology is not perfect… precisely because people are not perfect (scary thought eh?) So you have to assume all your technology can betray you at some point (and someone else’s as well); so it’s best not to have blind faith in your device’s ability to protect you if you are not also an active part of it’s defense.

Alternatives to FTP (or How I Stopped Worrying and Loved The SSH)

Forgive the Dr. Strangelove reference, but sometimes life around here is just as bizarre as the world of that movie.

With the final closing of the second of the 4 fatal protocols, namely FTP (and formerly Telnet, can you guess the 3rd & 4th?) Here is a quick meditation on how FTP is just no longer required and there is an AWESOME alternative… if you are just willing to open your mind a bit.

Since SSH provides three major features, encrypted communications, encrypted sign-in and built-in second factor authentication, what is there NOT to love about SSH?

The direct replacement for FTP via SSH is of course, SFTP. Certainly you can use SCP to, but for the moment, lets stick with SFTP as we are really talking about replacing FTP here. Also, this discussion focuses on Unix/Linux and even MacOS X. Windows on the other hand, is a separate story.

Your first response might be, “but allowing SFTP gives people implicit access to the SHELL”. I am sorry to tell you this… but horse-dinky. At least, horse-dinky for OpenSSH 4.9 and up (7.2 is the current stable release). Other SSHD server’s your mileage may vary.

A side note, as some will note, years ago, I said of OpenSSH, “…I wouldn’t give it to my worst enemy… well… maybe my worst enemy, but no one else.” Back in the day, OpenSSH was a total wreck, but after some soul searching… and the fact that the majority of the flaws came from one programmer and OpenSSH itself went full hog into auditing this guy’s code… it’s been pretty stable since.

Having said that, don’t download, compile and install SSHD on your own. Get it from a Package Manager or at least use one supported by whoever your vendor is. Why? Well, given OpenSSH’s track record and continued footprint around the world, it will always be under attack and you want to be sure your updates to it are automated and not have to think about it.

For SSHD implementations that do not have the correct feature set, there is “scponly”, But I wouldn’t recommend it if you can avoid it.

Ok, the meat… SSHD has two wonderful features that many people are not aware of.

  1. A flag called “ForceCommand”
  2. Pattern Matching and Conditional Processing in sshd_config

With these two features, you can limit users or groups to SFTP only and deny them access to the shell. A pro tip though, I would still also set the user’s account to “noshell” or “/bin/false” just for safe measure (see “man chsh” on your computer of choice for that). If you have other protocols enabled like… gack… telnet, rlogin, rsh or any other one that requires a user account but no shell access, then do this anyway. (btw, Friends don’t let friends deploy telnet, rlogin or rsh and if you do use them… shame on you…)

The totally cool part is, not only can you limit an individual user or group, the matching and conditional processing in sshd_config allows you to limit where they come from, what commands they use, Change their root and set a whole lot of SSH settings just for them.

Ok, here are a few examples… Let’s limit the user “bob” to SFTP only, in /etc/ssh/sshd_config (or wherever your SSHD config is located), I would append the following..

Match User bob
ChrootDirectory %h
ForceCommand internal-sftp
AllowTcpForwarding no

In this example, conditional processing will match Bob’s username and execute the commands under the match statement. In this case, we Chroot to Bob’s “%h” (aka Home directory), so he can only save to his home folder. We also here, limit him to SFTP and we limit his ability to use SSH to forward himself around to other places or create tunnels. Literally, we tell SSHD, SFTP to this folder ONLY.

Let’s say Prof. Rob has students that need to submit homework assignments. Yes, Prof. Rob could use one account, a service account, for this… while this is very much like anonymous FTP, it is highly not recommended. Instead, we create a user for each student, student1 through student230 (it’s a big class). We create a group, “PHY222” and add all the users to this group.

Then we create a folder in Prof. Rob’s home (or anywhere else to be honest), called, “Phy222Homework”. Chown it to “chown rob:PHY222 Phy222Homework”, then Chmod it to “chmod u=rwx,g=rws,o-rwx Phy222Homework”. Finally, create folders under “Phy222Homework” named after the users.

Again, add to the bottom of /etc/ssh/sshd_config…

Match Group PHY222
ChrootDirectory /home/rob/Phy222Homework/%u
ForceCommand internal-sftp
AllowTcpForwarding no

Effectively, each user can place files only in his/her sub folder in Prof. Rob’s Phy222Homework folder and has no shell access.

You can do this as outlined, for letting people place webpages in folders under a webserver, skies the limit here.

Now…, do you want to turn it up to “11”.

SSH has built-in two factor authentication… sort of… but still, awesome despite it being “sort of”. SSHD allows the use of self-generated keys. Basically, you (or the admin for your server) generates a key and then places a checksum of the key in file named “authorized_keys” in the “.ssh” folder in your home directory. You can also place the key there so that you can use it to access other systems, but that is a post for another time. The key, can either have a password… or not.

As matter of policy, your keys should have passwords, I can’t stress that enough. I won’t even address having keys with no password here.

The beauty of a key with a password is this, when you type in the password to authenticate, it unlocks the key. The key, then becomes your password effectively. So when you log into an SSH server, the password used to unlock the key never travels across the network. This… is… huge… because there is now, no password moving across the network that can be captured and the key itself is never revealed because anything encrypted with it, is decrypted at the other end using the hash in the “authorized_keys” file or via a negotiated key using the hash as a key.

Which, I should mention, never never never ever, exchange a key or key-hash with a user via email or any other insecure method that could be intercepted. If you do, consider the key worthless. I would recommend that keys are either distributed over authenticated and encrypted channels or in person via a portable media (like a flash drive).

You can generate OpenSSH keys on a Unix/Linux/MacOS X systems with ssh-keygen (see the man pages) and on Windows PC’s using PuTTY’s puttygen.

The key thing to remember with “puttygen” is that it saves the hash (and key) in a PuTTY format. You must use the export menu option to export it to an OpenSSH recognized format. The hash, can be lifted from the main window. The output window visible when you generate a key contains the hash in a format that you can place directly into an “authorized_keys” file.

Always use SSH-2 or newer, prefer RSA over DSA when selecting a key and lastly, pick a decent key size. These days, 2048 for key size should be considered a minimum, however, 4069 or 8192 are better. The number, in case you were wondering, is a power of 2 (or a multiple of 512 or 1024, i.e. 1024 & 2048 divides evenly by both 512 or 1024; and represents the number of bits in the key.

You might think the larger the bit size, the slower your connection, this is not true. This is because, the key is only used to encrypt a session key and is used infrequently during the course of the connection, the session key itself is used for the majority of the connection. While the key size may effect the time for build up and teardown of the session, you probably won’t even notice that. So 8192, or 16K keys… not a problem. Larger key size will give your key more life as advances in computing power are prone to reduce the life span of encryption techniques. So don’t be chintzy with the key size.