Tag Archives: general advice

May 21 2013
4 Comments
Blog Posts

Handling terminal color escape sequences in less

This post is a quick one but I wanted to share it since I taught it to someone new today. When you have bash output with colors, less doesn’t handle the color codes properly by default:

$ colordiff chunk/functions.php chunk-old/functions.php | less
ESC[0;32m22a23,27ESC[0;0m
ESC[0;34m>       * Load up our functions for grabbing content from postsESC[0;0m
ESC[0;34m>       */ESC[0;0m
ESC[0;34m>      require( get_template_directory() . '/content-grabbers.php' );ESC[0;0m
ESC[0;34m> ESC[0;0m

Toss in the -R flag and you’ll be able to see the colors properly (no colors to see here, but use your imagination):

$ colordiff chunk/functions.php chunk-old/functions.php | less -R
22a23,27
>        * Load up our functions for grabbing content from posts
>        */
>       require( get_template_directory() . '/content-grabbers.php' );
> 
>       /**

The man page for less explains the feature in greater detail:

-R or --RAW-CONTROL-CHARS
       Like -r, but only ANSI "color" escape sequences are output in "raw" form.  Unlike -r, the screen appear-
       ance is maintained correctly in most cases.  ANSI "color" escape sequences are sequences of the form:
            ESC [ ... m
       where the "..." is zero or more color specification characters For  the  purpose  of  keeping  track  of
       screen  appearance,  ANSI  color escape sequences are assumed to not move the cursor.  You can make less
       think that characters other than "m" can end ANSI color escape  sequences  by  setting  the  environment
       variable  LESSANSIENDCHARS to the list of characters which can end a color escape sequence.  And you can
       make less think that characters other than the standard ones may appear between the ESC  and  the  m  by
       setting the environment variable LESSANSIMIDCHARS to the list of characters which can appear.
Tagged , , , , , ,
May 14 2013
10 Comments
Blog Posts

Changing your ssh server’s port from the default: Is it worth it?

Changing my ssh port from the default port (22) has been one of my standard processes for quite some time when I build new servers or virtual machines. However, I see arguments crop up regularly about it (like this reddit thread or this other one).

Before I go any further, let’s settle the “security through obscurity” argument. (This could probably turn into its own post but I’ll be brief for now.) Security should always be applied in layers. This provides multiple levels of protection from initial attacks, like information gathering attempts or casual threats against known vulnerabilities. In addition, these layers of security should be applied within the environment so that breaking into one server after getting a pivot point in the environment should be just as difficult (if not more difficult) than the original attack that created the pivot point. If “security through obscurity” tactics make up one layer of a multi-layered solution, I’d encourage you to obscure your environment as long as it doesn’t affect your availability.

The key takeaway is:

Security through obscurity is effective if it’s one layer in a multi-layer security solution

Let’s get back to the original purpose of the post.

The biggest benefit to changing the port is to avoid being seen by casual scans. The vast majority of people hunting for any open ssh servers will look for port 22. Some will try the usual variants, like 222 and 2222, but those are few and far between. I ran an experiment with a virtual machine exposed to the internet which had sshd listening on port 22. The server stayed online for one week and then I changed the ssh port to 222. The number of attacks dropped by 98%. Even though this is solely empirical evidence, it’s clear that moving off the standard ssh port reduces your server’s profile.

If it’s more difficult to scan for your ssh server, your chances of being attacked with an ssh server exploit are reduced. A determined attacker can still find the port if they know your server’s IP address via another means (perhaps via a website you host) and they can launch attacks once they find it. Paranoid server administrators might want to check into port knocking to reduce that probability even further.

Remembering the non-standard ssh port can be annoying, but if you have a standard set of workstations that you use for access your servers, just utilize your ~/.ssh/config file to specify certain ports for certain servers. For example:

Host *.mycompany.com
  Port 4321
 
Host nonstandard.mypersonalstuff.com
  Port 2345
 
Host *.mypersonalstuff.com
  Port 5432

If you run into SELinux problems with a non-standard ssh port, there are plenty of guides on this topic.. The setroubleshoot-server package helps out with this as well.

# semanage port -a -t ssh_port_t -p tcp 4321
# semanage port -l | grep ssh
ssh_port_t                     tcp      4321,22

Here is my list of ssh lockdown practices when I build a new server:

  • Update the ssh server package and ensure that automatic updates are configured
  • Enable SELinux and allow a non-standard ssh port
  • Add my ssh public key to the server
  • Disable password logins for ssh
  • Adjust my AllowUsers setting in sshd_config to only allow my user
  • Disable root logins
  • For servers with sensitive data, I install fail2ban
Tagged , , , , , , , , , , ,
Apr 19 2013
5 Comments
Blog Posts

Reprint: Stop Disabling SELinux!

This article appeared in SC Magazine and I’ve posted it here as well. For those of you who were left wanting more from my previous SELinux post, this should help. If it doesn’t help, leave a comment. ;)

The push to cloud transforms the way we apply information security principles to systems and applications. Perimeters of the past, secured heavily with traditional network devices in the outermost ring, lose effectiveness day by day. Shifting the focus to “defense in depth” brings the perimeter down to the individual cloud instances running your application. Security-Enhanced Linux, or SELinux, forms an effective part of that perimeter.

SELinux operates in the realm of mandatory access control, or MAC. The design of MAC involves placing constraints on what a user (a subject) can do to a particular object (a target) on the system. In contrast, discretionary access control, or DAC, allows a user with certain access to use discretion to limit or allow access to certain files, directories, or devices. You can set any file system permissions that you want but SELinux can override them with ease at the operating system level.

Consider a typical server running a web application. An attacker compromises the web application and executes malicious code via the web server daemon itself. SELinux has default policies that prevent the daemon from initiating communication on the network. That limits the attacker’s options to attack other services or servers.

In addition, SELinux sets policies on which files and directories the web server can access, regardless of any file system permissions. This protection limits the attacker’s access to other sensitive parts of the file system even if the administrator set the files to be readable to the world.

This is where SELinux shines. Oddly enough, this is the point where many system administrators actually disable SELinux on their systems.

Troubleshooting these events, called AVC denials, without some helpful tools is challenging and frustrating. Each denial flows into to your audit log as a cryptic message. Most administrators will check the usual suspects, like firewall rules and file system permissions. As frustration builds, they disable SELinux and notice that their application begins working as expected. SELinux remains disabled and hundreds of helpful policies lie dormant solely because one policy caused a problem.

Disabling SELinux without investigation frustrated me to the point where I started a site at stopdisablingselinux.com. The site is a snarky response to Linux administrators who reach for the disable switch as soon as SELinux gets in their way.

All jokes aside, here are some helpful tips to use SELinux effectively:

Use the setroubleshoot helpers to understand denials
Working through denials is easy with the setroubleshoot-server package. When a denial occurs, you still receive a cryptic log message in your audit logs. However, you also receive a message via syslog that is very easy to read. Your server can email you these messages as well. The message contains guidance about adjusting SELinux booleans, setting contexts, or generating new SELinux policies to work around a really unusual problem. When I say guidance, I mean that the tools give you commands to copy and paste to adjust your policies, booleans and contexts.

Review SELinux booleans for quick adjustments
Although the myriad of SELinux user-space tools isn’t within the scope of this article, getsebool and togglesebool deserve a mention. Frequently adjusted policies are controlled by booleans that are toggled on and off with togglesebool. Start with getsebool –a for a full list of booleans and then use togglesebool to enable or disable the policy.

Quickly restore file or directory contexts
Shuffling files or directories around a server can cause SELinux denials due to contexts not matching their original values. This happens to me frequently if I move a configuration file from one system to another. Correcting the context problem involves one of two simple commands. The restorecon command applies the default contexts specific to the file or directory. If you have a file in the directory with the correct context, use chcon to fix the context on the wrong file by giving it the path to the file with the correct context.

Here are some additional links with helpful SELinux documentation:

Tagged , , , , , ,
Apr 15 2013
24 Comments
Blog Posts

Seriously, stop disabling SELinux

After many discussions with fellow Linux users, I’ve come to realize that most seem to disable SELinux rather than understand why it’s denying access. In an effort to turn the tide, I’ve created a new site as a public service to SELinux cowards everywhere: stopdisablingselinux.com.

Here are some relatively useful SELinux posts from the blog:

Edit: The goal of the post was to poke some fun at system administrators who disable SELinux immediately without learning how it works or why they’re seeing certain operations being denied. Obviously, if your particular workload or demands don’t allow for the use of SELinux, then I’m going to be the last person to encourage you to use it. Many system administrators have found that it doesn’t provide a good ratio of work required to benefit gained, which I totally understand.

Tagged , , , , , ,
Mar 17 2013
2 Comments
Blog Posts

Survive the Google Reader exodus with Tiny Tiny RSS

Tiny Tiny RSSIt’s no secret that Google Reader is a popular way to keep up with your RSS feeds, but it’s getting shelved later this year. Most folks suggested Feedly as a replacement but I found the UI quite clunky in a browser and on Android devices.

Then someone suggested Tiny Tiny RSS. I couldn’t learn more about it on the day Google Reader’s shutdown was announced because the site was slammed. In a nutshell, Tiny Tiny RSS is a well-written web UI for managing feeds and a handy API for using it with mobile applications. The backend code is written in PHP and it supports MySQL and Postgres.

There’s also an Android application that gives you a seven day trial once you install it. The pro key costs $1.99.

The installation took me a few minutes and then I was off to the races. I’d recommend implementing SSL for accessing your installation (unless you like passing credentials in the clear) and enable keepalive connections in Apache. The UI in the application drags down a ton of javascript as it works and enabling keepalives will keep your page load times low.

If you want to get your Google Reader feeds moved over in bulk, just export them from Google Reader:

  1. Click the settings cog at the top right of Google Reader and choose Reader Settings
  2. Choose Import/Export from the menu
  3. Press Export, head over to Google Takeout and download your zip file

Unzip the file and find the .xml file. Open up a browser, access Tiny Tiny RSS and do this:

  1. Click Actions > Preferences
  2. Click the Feeds tab
  3. Click the OPML button at the bottom
  4. Import the xml file that was in the zip file from Google

From there, just choose a method for updating feeds and you should be all set!

Tagged , , , , , , ,
← Older posts