It allows Microsoft to control the computer remotely through a built-in backdoor. Keys to that backdoor are likely accessible to the NSA – and in an unintended ironic twist, perhaps even to the Chinese.
I originally really wanted to upgrade to Windows 8 because it looks sexy, but at this point I’m actually starting to plan a move to Linux. Most of the tools I use are now available on Linux (or function properly in WINE).
If you are a law office, or need to obey PIPEDA or other privacy laws or similar, Windows 8 is pretty much unusable by you. If there is a known backdoor in the system, it can be used by other individuals and since you are aware, you are knowingly breaking any confidentiality agreements you have with your clients.
In context, Panda Rose is pretty much forbidden to use any American servers for some of our government contracts because the data is considered confidential and the Canadian (and Ontario) governments do not believe that the data can be kept private on an American server.
With all of the NSA spying and privacy items out there, I thought I’d write a quick post on easy ways to lock down your SSH server for people who may want to make some tweaks to their sshd_config on their Ubuntu (or other Linux) installations. This article specifically covers opensshd_config settings. PAM settings and other SSH related settings will come later.
I have a series of bash scripts that generate these settings automatically. If you are interested, let me know and I will send you them. Note: everything in <<Code>> format references a line in your /etc/ssh/sshd_config. If you don’t see the line (or similar) anywhere, then you may need to add the line.
Some of the items below prevent information leakage, a determined adversary will be able to get around them, but it will prevent script kiddies and scanning attacks, easing the load on your server.
If possible, you should not use port 22 as the SSH port.
Instead you should choose another unused port randomly and set that as the SSH port. For example:
There are many circumstances, however, where a client’s IT will not permit a non-SSH port to be open on their firewall. In these circumstances, leave the port as port 22. This is not a high security change. This change avoids automated SSH attacks and allows the server to have a lower profile if the ports are scanned.
IP Listen Address
Try to avoid having ListenAddress set to 0.0.0.0 (All IPs). If there are multiple IPs available to the machine, a specific IP should be used for SSH and no other services. This will allow for easier auditing, as well as more difficult matching up specific websites to specific SSH servers.
This also allows you to set up very specific rules on the firewall for this machine. As well, it ensures that you know precisely where the SSH is open. If you are only to have it open on the internal network, this will naturally restrict it to that.
SSH protocol version 1 (SSH-1) has known man-in-the-middle attacks problems and myriad security vulnerabilities. SSH-1 is formally obsolete and should be avoided at all cost.
UsePrivilegeSeparatation sets up a child process to deal with any incoming traffic. Only after the user successfully authenticates will it give them the privilege of the authenticated user. This is so that if any of the incoming traffic corrupts the process, there will be no privilege escalation.
While this is usually by default “yes”, it should be listed as a line item in sshd_config to ensure that it is on.
Logging should be set to go to the /var/log/auth.log facility by using the SysLog AUTH parameter. This will ensure that any problems around invalid logins or the like are forwarded to a central security file for auditing purposes.
Allowed settings for LogLevel at Panda Rose are ERROR, INFO, VERBOSE. In general, LogLevel should be INFO if diskspace is not a concern, however it should not go to DEBUG levels as that will violate the privacy of users. If disk space is a concern, LogLevel should be at ERROR and it should be gzipped and stored on a regular basis for auditing purposes.. VERBOSE should be used for debugging purposes if necessary. However, it should not be on as the default LogLevel as the data it produces is far more difficult to audit than either ERROR or INFO.
This is the time allowed for a non-authenticated user to stay connected to the system. Commonly 120 seconds is the default. You can set this lower to avoid this being a DDOS vector, however 120 seems to work well for most circumstances.
There is no circumstance that this value should be anything other than no.
StrictModes specifies whether sshd checks to ensure a user did not make their .ssh directory and files writable by anyone other than its rightful owner. If the permissions are wrong, then the user cannot log in. As a security tool this prevents a hostile user or a hacked account from gaining access to other user accounts (and possibly administrative access) to the server.
Public Key Authentication is recommended for general use. This functionality allows users to create password-protected public/private keypairs using a facility like Puttygen or ssh-keygen and then connect securely using said private/public key pairing. Instructions for how to properly create one of these keys is explained in a later article on client security procedures.
This prevents issues around HostbasedAuthentication. While not likely a big issue, it should be set to ignore them.
In circumstances where the server is an independent, secure server, HostBasedAuthentication should be set to no. When there are multiple servers that are not all necessarily secure servers, and a need to have a centralized server handing HostbasedAuthentication, this can be set up. This will be discussed in further detail in a later article.
This one is just simple common sense one. No one should be able to login if they don’t have a password.
This is related to the PAM based authentication set up for root users to be explained in another article. This allows Google Authenticator or another token-based or biometric-based authentication system to be implemented to improve security security for administrative users.
UsePAM allows us to set up PAM to use these extra methods of authentication for logging in administrative users.
For the purposes of most installations, neither Kerberos nor GSSAPI-based systems will be used.
Unless absolutely needed, X11 shouldn’t be running on a Linux server open to the web. X11 Forwarding should be off. In circumstances where X11 Forwarding is on, treat the server as a secure Linux client and not a server.
In most cases individuals won’t be using your server as a gateway to other machines. Set GatewayPorts to no to ensure that any port forwarding is limited to the local machine. If this needs to be set to yes, make a note of it in that server’s details document for future audits.
While a message of the day seems useful, in many circumstances it gives away information to end users who may not be administrators that they should not be aware of. This setting is by default on for many Ubuntu installs, it should be turned off.
This will print the IP, date and time of the last user login for that user. This is useful information as it can give a user a hint if someone were to gain access to their account. Leave this one on.
To avoid infinitely hanging sessions, this should be left on. This will send TCP keepalive messages to determine if the client has gone down. If the client goes down or the connection is interrupted, it will be noticed and the server will end the session. To avoid consuming server resources with “ghost” users, this should be left on.
Some users may complain since it implies if the route goes down temporarily, the connection will die. In these circumstances, determine if their needs require this to be turned off. Turning this off has no security implications.
This will display a banner before a user logs into the server. For clients who have their own legal team, a proper banner should be requested from them for their servers. Panda Rose’s standard banner is as follows:
You are accessing a Panda Rose Consulting Studios (PRCS) managed
Information System (mIS) that is provided for authorized use only.
By using this mIS (which includes any device attached to this mIS),
you consent to the following conditions:
* PRCS routinely intercepts and monitors communications on this mIS.
* At any time, PRCS may inspect and seize data stored on this mIS.
* Communications using or data stored on this mIS are not private.
They are subject to routine monitoring, interception and search.
They may be disclosed or used for any PRCS authorized purpose.
* This mIS includes security measures (e.g., authentication and
access controls) to protect PRCS and our clients' interests --
not for your personal benefit or privacy.
Your IP has been logged.
Contact your lawyers, or make an adjusted version to fit your needs.
Restrict Ciphers and MACs to the best secure ciphers. While not a real issue, this shows attention to detail. HMAC-SHA1 is required since PuTTY does not support the other algorithms yet.
It is a good practice practice to limit the SSH to only users who should have access to it, this is done with an AllowUsers line at the end of the sshd_config listing the users who can log in with SSH.
The above are suggestions, and over time may change to fit the needs. At the end of the day, these settings are just a small piece of ensuring your server is secure. Most of the determined attacks on your server will be based on zero-day vulnerabilities or other security holes, many of which are not even related to SSH. Ensure your server is up to date regularly, and always audit your logs to detect break-ins. You can use a tool like logcheck or logwatch to aide you in this process.
This is the first article of what I hope to be a series of discussions on products that seem to have all the pieces in existence, but for some reason no organization with enough capital has invested in it. This doesn’t mean there aren’t technical challenges in implementing it, but rather I know of no company doing it, even though the tech exists.
I want an e-book, not an e-page
Today’s topic is real e-books, not the tablet style Kindle or Nook which are essentially glorified screens with the ability to read more than one article. Rather, a book with real pages that you can turn and update to have any content you want. While I like the fact we at least have the ability to read books digitally in a nice fashion, I still think we are falling short of the real capabilities of e-ink and digital technology.
To get the vision clear, please note that a book is not a single page. A single page is essentially a pamphlet or brochure. When I read a book, there is the physical enjoyment of turning the pages of the book, but even more so, the ability to position physically different parts of the book so I can flip back and forth to compare and contrast what I’m reading.
This is especially useful for text books. However, it is a real part of the book reading experience that is fundamentally lost with any of the existing e-book readers.
So, with that in mind, what am I envisioning? I’m envisioning a digital tool with multiple screens made up of e-ink, say 50 pages worth. With the front page I can load a book (or at least 100 pages of the book) into the reader and then I can start reading, flipping the pages myself rather than having to click on a next page/previous page set of buttons.
Pieces of the Puzzle
Bendable, think e-ink pages.
This technology has been kicking around for over a decade now. At the last CES, Sony, LG, and a variety of other providers were showing not only that it bends, but that it’s a lot more durable than ever. I don’t think it’s impossible to make one that would last a while now.
You don’t need a lot of power in a processor to generate a page that remains static on an e-ink screen. The arduino micro is an extreme example of how small you can get, but to be honest, the fact we can pack the equivalent to a computer I had 12 years ago into an iPhone demonstrates to me that this tech isn’t the hangup.
Small power source
Again, look at the kindle, it is lightweight and has a tiny battery with a good battery life. I don’t see how you could not resize this to fit into the binding of a book.
Why does this not exist?
This is the only hangup I can find. How can you manufacture these cheaply? My bet is that once you have a plan to sell enough of these, the price of the bendable e-ink screens drops. Similar to how the retina screens on the iPhones got cheaper suddenly once there was a demand for them. This is the biggest question mark in the “why does this not exist?” category. However, price, to me, always seems like something that is solvable given good quality industrial engineers.
Maybe I’m the only person who would love to have a digital book I can flip pages with.
Patents/Unknown tech restraints
I am unsure of the legal atmosphere around this technology. It could be that e-ink pages are patented by someone who wants too much money for the rights to use it.
I have been dreaming of making this for almost 10 years now, I just haven’t been able to build a functioning mock-up or prototype due to the fact I don’t know where to get e-ink screens that are bendable at a reasonable price. Arduinos and programming is easy, it’s the screens where I get stuck.
Hopefully someone out there is building this, because this would be a true e-book and replace my entire bookshelf with one, totally awesome, book.