Windows Server 2008 Unable to break out of boot loop


With a server 2008 installation, I wanted to reboot into safe mode. Msconfig was used to allow restart in safe mode. However, on reboot, it gets to the log on screen then reboots again very quickly. I've tried frantically typing the password, but the reboot is too quick and loops incessantly. This is not a boot loop linked to an OS update which I've come across in researching an answer.

I tried putting the installation disk in and chose the repair (rescue?) option. This resulted in a message box saying it was the wrong version of windows. Not sure what is going on as it was the right version as far as I could tell. I want to avoid reinstalling Windows Server if at all possible.

The machine is dual boot with linux so if there's a solution involving manually editing appropriate files this would be no problem.

Why Linux is a perfect fit for charities and non-profits


I have a friend who works for an art therapy institute that is run by the city I live in. That foundation has taken donations for quite some time, is (obviously) not for profit, and all of their computers are Linux computers. Why? It doesn’t hurt that their sole IT staff member is a big Linux fan (and understands how the FOSS operating system can help the organization in more ways than just budgetary). But after chatting with this friend for a while about his job, I understand very clearly how Linux and open source can really benefit charities and non-profit organizations.

It all begins with cost. Okay, yes Microsoft will give their operating system away once you’ve taken the time to prove you are who you are and you meet the right status (according to their guidelines). But once you get beyond the operating system, you then have to consider all of the other applications that must be put in place:

  • Anti-virus
  • Anti-malware
  • Office suite
  • Financial tools
  • Monitoring and/or NAC tools

And much more. And again, charities can more than likely score software titles to aid in the above tasks, but are they going to, yet again, have to prove who they are, fill out the right forms, and do the right dances? Probably (unless they are downloading the free version of said software that doesn’t have all the features the paid version has). And what about the hardware? You know most charities aren’t running the latest greatest. In fact, most of the charities I come across are running white-box machines that couldn’t run Windows 7 if their electronic lives depended upon it.

So…what should charities do? Those organizations that are so budget-strapped that they aren’t sure if their doors will remain open if they have to divert a single penny in the wrong direction? They should turn to Linux. And, like my friend in the art therapy organization, many of these organizations (from churches, to missions, to animal rescues. and more) are feeling the belt-tightening more than most in this economy, and they need to find relief somehow. One of the easiest forms of relief is turning to FOSS. Outside of the financial issues, there is one issue that you can not overlook when it comes to charities and Linux:

Linux cares.

Is that such a crazy statement? In the world of heartless IT where it all boils down to whether or not the servers have backed up, if the TCO is low enough, if the employees can do their jobs efficiently…does it count to have a heart? Take a look at this site: Linux Against Poverty. LAP is an annual computer drive/install fest that aims to provide Linux-based PCs for impoverished children in Texas. Charitable organizations like these are all over the place. And you can find Linux (or FOSS) at their hearts.

This only makes sense. Linux relies upon the charity of developers across the globe. Yes, there are developers out there getting paid to code for the open source champion, but the vast majority of development done for Linux is done via charitable contributions. So Linux, as a whole, has a fundamental understanding and strong kinship with charities. So Linux gets “need”.

But why would a charity want to migrate from a known to an unknown entity? How would they benefit? Well, they would benefit in the same way users would:

  1. Zero cost of ownership.
  2. No third-party software (such as anti-virus or anti-malware) required to protect machines.
  3. Stable, secure platform.
  4. Lesser hardware requirements.

To name a few.

Think about it this way:

Soon Windows XP is going to go the way of Windows 98. When that happens it is going to become a challenge for charity-based, non-profit organizations to find willing donations of hardware that will run the current iteration of the Windows operating system. Without having Windows XP to fall back on, what choice do they have? How can they resurrect that hardware given to them by an individual (or company) when it doesn’t meet the minimum requirements for Windows? Simple: They turn to Linux.

And for anyone that is going to chime in and say those organizations will not be able to make use of this “unknown entity,” I say to you, use a modern release of Linux and tell me just how steep the learning curve is? It’s not. We have finally reached the point where, to be quite frank, an operating system is an operating system is an operating system. They work very similarly: You point, you click, you work. Sure some of the names are different and the GUIs are built a bit differently…but the fundamentals are fairly standard throughout.

What you need to know about OpenSSH key management


OpenSSH is one of my favourite tools, and one I take for granted because I use it all day, every day. OpenSSH is a Swiss Army-knife of coolness that can be used to provide secure connections to insecure sites in insecure places like free Wi-Fi-offering coffee shops. It can be used to remotely administer systems, provide encrypted file sharing via sshfs, bypass draconian corporate firewall policies (okay, maybe that isn’t the best example of OpenSSH coolness), and a whole lot more.

Before you’re really able to appreciate all that OpenSSH has to offer, you have to learn the basics, and that means key management. So we’re going to look at how to manage and use OpenSSH public/private keypairs.

Generating OpenSSH keys is easy, and doing so allows for passphrase-based keys to be used for login authentication instead of providing your password. This means you have the private key stored locally, and the public key is stored remotely. The two keys together form a cryptographically secure keypair used to perform authentication, without sending a password over the network.

To generate an RSA2 key (default 2048 bits) with a special comment to identify its use and saved to ~/.ssh/server1_rsa and ~/.ssh/server1_rsa.pub, use:

$ ssh-keygen -C "special key for server foo" -t rsa -f ~/.ssh/server1_rsa
Generating public/private rsa key pair.

Enter passphrase (empty for no passphrase):

Enter same passphrase again:
Your identification has been saved in /home/joe/.ssh/server1_rsa.
Your public key has been saved in /home/joe/.ssh/server1_rsa.pub.
The key fingerprint is:
fb:8a:23:82:b9:96:a1:9c:d5:62:58:15:9a:8f:f9:ed special key for server1
The key's randomart image is:

+--[ RSA 2048]----+
|     ..          |
|    o.           |
|   o.            |
|   .+            |
|  oo..  S        |
| o +...  .       |
|oo* .. ..        |
|+=. . o. .       |
|o. . ..E...      |
+-----------------+

Keeping this key to yourself isn’t useful, so it needs to be copied to a remote server where it will be used. You can do this manually by copying it over and then moving it into place, or you can use the ssh-copy-id command:

$ ssh-copy-id -i ~/.ssh/server1_rsa joe@server1.domain.com

Once you provide the account password, the ~/.ssh/server1_rsa’s public key will be copied to the remote server and placed into ~/.ssh/authorized_keys. You should then be able to log in using the key, and its passphrase, from that point forward.

Using the ~/.ssh/config file can really make life easier. With that configuration file, you can easily setup various options for different hosts. If you wanted to have multiple SSH public/private keypairs, and want to use a specific keypair for a specific host, using ~/.ssh/config to define it will save some typing. For instance:

Host server1 server1.domain.com
  Hostname server1.domain.com
  User joe
  IdentityFile ~/.ssh/server1_rsa
Host server2 server2.domain.com
  Hostname server2.domain.com
  User root
  IdentityFile ~/.ssh/server2_rsa

In this example, when you do ssh server1, it will connect to server1.domain.com using the private key in ~/.ssh/server1_rsa, logging in as “joe”. Likewise, when connecting to server2.domain.com, the ~/.ssh/server2_rsa key is used and you will connect as the root user.

If you have changed the remote server’s SSH key (either by installing a new operating system, re-using an old IP address, changing the server keys, whatever), and you have strict key checking enabled (usually a default), you may see a message like this:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!

Warnings like this should be taken seriously. If you don’t know why the key has changed, before making any changes and assuming it’s benign, or even completing the login, find out from the administrator of the box. If you know this is an expected change, then use the ssh-keygen tool to remove all keys that belong to that particular host from the known_hosts file (as there may be more than one entry for the host):

$ ssh-keygen -R server1.domain.com

This is especially useful if you are using hashed hostnames. What are hashed hostnames, you ask? Hashed hostnames are a way to make the known_hosts file not store any identifying information on the host. So in the event of a compromise, an attacker would be able to obtain very little information from the hashed file. If you had an entry like this in your ~/.ssh/known_hosts file:

server4,10.10.10.43 ssh-rsa

AAAAB3NzaC1yc2EAAAABIwAAAIEAtNuBVGgUhMchJoQiDTZ+Nu1jzJOXxG9vo5pVWSbbic4kdAMggWrdhXBU6K3RFIEwxx9MQKR81g6F8shV7us0cc0qnBQxmlAItNRbJI8yA4Ur+2ggFPFteqUEvOhA+I7E8REcPX87urxejWK3W11UqOXyjs7cCjoqdps8fEqBT3c=

This clearly identifies that you have at some point connected to “server4″, which has an IP address of 10.10.10.43. To make this information unidentifiable, you can hash the known_hosts file to make the above look like this instead:

|1|sPWy3K2SFjtGy0jPTGmbOuXb3js=|maUi1uexwObad7fgjp4/TnTvpMI= ssh-rsa

AAAAB3NzaC1yc2EAAAABIwAAAIEAtNuBVGgUhMchJoQiDTZ+Nu1jzJOXxG9vo5pVWSbbic4kdAMggWrdhXBU6K3RFIEwxx9MQKR81g6F8shV7us0cc0qnBQxmlAItNRbJI8yA4Ur+2ggFPFteqUEvOhA+I7E8REcPX87urxejWK3W11UqOXyjs7cCjoqdps8fEqBT3c=

It’s the same host, but now in a format that only ssh and sshd will understand. This is where the ssh-keygen -R command is so necessary, since trying to find the entry for host “foo.domain.com” in a hashed file would be impossible. To hash your known_hosts file, use:

$ ssh-keygen -H

There is so much that can be done with OpenSSH, and this tip mostly dealt with key management. Next, we will look at some quick one-liner commands to help accomplish some basic, and some not-so-basic, tasks with OpenSSH. 

Use Hamachi VPN on your Linux clients


If you’ve used Linux in a business environment, you know there are times when you might need to host a VPN on that Linux machine in order to access said machine from other locations. If you need such a service, you could go through the steps of installing a tool like OpenVPN (which is, of course, an outstanding open source VPN solution) or, you can do this the easy way and install the Hamachi VPN GUI for a very easy VPN setup.

I want to demonstrate how to install Hamachi and Haguichi on a Ubuntu desktop installation so you can see how easy it can be to add your Linux desktop to a VPN.

What you need

There are two pieces to this puzzle:

  • Logmein Hamachi
  • Haguachi

There are a few different GUI options that you may come across for Linux: Hamachi GUI and Haguichi. Hamachi GUI seems to be outdated and not terribly reliable. Haguichi, on the other hand, is quite reliable. We’ll install that tool to use as a GUI front-end, but before you install that, you must install Hamachi2.

Installation

First, download the Hamachi2 deb from the Logmein download page. Once you have that downloaded, do the following:

  1. Open up a terminal window.
  2. Change to the directory housing the newly downloaded .deb file.
  3. Issue the command sudo dpkg -i logmein-hamachi_XXX_xxx.deb (Where XXX is the release number and xxx is the architecture for your hardware). NOTE: If your installation doesn’t complete, you might need to open up Synaptic to “fix” the broken packages. This is an easy way to catch all of the dependencies.
  4. Type your sudo password and hit Enter.
  5. Allow the installation to complete.

With that piece installed, you are ready to install the GUI. Instead of downloading a .deb file, we are going to add the PPA for Haguichi to our system. Once the PPA is added, Haguichi can be installed using apt-get. Here are the steps:

  1. Open up a terminal.
  2. Issue the command sudo add-apt-repository ppa:webupd8team/haguichi.
  3. Issue the command sudo apt-get update.
  4. Issue the command sudo apt-get install haguichi.

I will say the Haguichi client does seem to be a bit more reliable than Hamachi GUI.

Connect to, or create a VPN network



Now that you have everything installed, click Applications | Internet | Haguichi. When the Haguichi window opens (at left), click Client | Join Network. A new window will open where you can enter the credentials for the VPN you want to join. You can also create a new network by clicking Client | Create Network. You will have to enter a name and a password for that network. This should go without saying, but make sure your password follows standard strong password practices. Do NOT create a week password for a VPN network connection.

Once you are joined to a VPN network you can browse other machines on the network by double-clicking the listed machine, which will open up a file browser window for all available shares on that machine. NOTE: If the target machine has no shares, you will not be able to browse the machine.

You can also change the nickname of the machine you are working on. This is handy when the hostnames of the various machines on your network are similar. To change the nickname click Client | Change Nickname and then enter the new information.

Final thoughts

If you need to connect a Linux machine to an Hamachi VPN (or need to quickly create a VPN network) you can’t go wrong with Hamachi2 and either Hamachi GUI or Haguichi. The setup time is fast, the tools are user-friendly, and it beats having to walk through the more complex configuration of OpenVPN. The downside? Although the source code of the Haugichi software is 100% open source, it does rely on the Hamachi service which uses non-open source software. That’s picking at nits, but some open source users are purists.

Use Fail2ban to blacklist IP addresses and alert you to attacks


One indication of whether anyone is taking undue interest in a system is to keep an eye on failed login attempts. Of course, depending on what services you’re running, and how much time you can devote to the task, this is easier said than done.

The problem is not only what files to watch, but how often you can watch them. Certain log analysis programs can give you a report of the previous day, such as logwatch, but by this time it could be too late. Reactive reports don’t help stop attempts, they just alert you of historical data.

One program that can help is Fail2ban, which monitors log files every second. If there are too many authentication failures, it can alert you via email so you have instant notification of what is going on, as it happens. But that isn’t all that Fail2ban can do — it can also modify firewall rules to block any subsequent access to the system from the attacking IP address. This makes Fail2ban a very interesting utility as, while it makes a good reporting system, it makes a much better proactive protection system. Fail2ban accomplishes this by adding iptables rules, shorewall rules, or tcp_wrappers rules, and these can differ per service.

Unlike some tools, Fail2ban works for more than just SSH: it can monitor logs for failed login attempts in Apache, Postfix, vsftpd, and more. In fact, Fail2ban allows you to write custom regular expressions so you can create filters for any other service you may be writing. Filters have been written to block attackers of WordPress blogs and other web applications as well.

Most Linux distributions provide Fail2ban, so it is usually an apt-get or yum command away. Once it is installed, the various configuration files are typically located in /etc/fail2ban/.

The primary configuration file is the jail.conf file. This is where you define the configurations for different services. There are different contexts here; the “[DEFAULT]” context applies to all services:

[DEFAULT]
ignoreip = 127.0.0.1
bantime  = 600
findtime  = 600
maxretry = 3
backend = auto

The ignoreip entry tells Fail2ban which IP addresses to ignore for failed login attempts. The default is for the localhost, and other IPs can be added here, each one separated by a space. The maxretry entry tells Fail2ban how many failures must be made by a host before it gets banned, and the bantime entry tells Fail2ban for how long to ban the host, in seconds (so 600 would be ten minutes).

After this, you can define per-service jails. The following is the SSH entry, which manipulates iptables rules to ban a host:

[ssh-iptables]
enabled  = true
filter   = sshd
action   = iptables[name=SSH, port=ssh, protocol=tcp]
           sendmail-whois[name=SSH, dest=root, sender=fail2ban@mail.com]
logpath  = /var/log/secure
maxretry = 5

Here, this jail specification tells Fail2ban to use the sshd filter (more on that below). The iptables action is used, specifying the name (”SSH”), the port to deny access to (”ssh”, or port 22), and what protocol to block on (”TCP”). It also specifies a second action, which tells Fail2ban to send an email to root noting that the IP has been blocked. Finally, this tells Fail2ban to watch the /var/log/secure file for authentication failures, and overrides the default of three failed attempts with five.

The filter is specified in /etc/fail2ban/filter.d/sshd.conf (which is what the “filter” keyword is pointing to). This file contains the regular expressions used to determine if a login has failed. Typically, you will not need to change anything here, but if you wish to add other regular expressions to this filter, you can do so by creating a file named /etc/fail2ban/filter.d/sshd.local and including them there.

Every .conf file that Fail2ban has can have a .local counterpart; the .local counterpart will override anything specified in the .conf file. This is to allow you to customize the configuration files and not worry about your changes being replaced when new versions of Fail2ban are installed. This guarantees that any custom configuration you specify will persist across upgrades.

Finally, the actions noted in the jail configurations are handled by configuration files in /etc/fail2ban/action.d/, so in our example above, the two action files being referenced would be /etc/fail2ban/action.d/iptables.conf and /etc/fail2ban/action.d/sendmail-whois.conf. This is where you can tweak the emails that get sent (by creating a sendmail-whois.local file, perhaps) and examine what iptables commands are being called. Here you can also see different action types; for instance the ipfw action would be used for operating systems such as OS X and FreeBSD, or the shorewall action if you use Shorewall to manage your firewall. Here is also where you would create any other custom actions, such as perhaps logging to an additional text file or database.

Fail2ban is a highly versatile tool to help prevent brute-force attacks as they occur. Rather than alerting an administrator after the damage may already be done, Fail2ban can alert immediately and take proactive steps in denying access to the host by the attacking IP address. It is quite straightforward to configure and very easy to install. If you are looking for a solution to help protect your systems and servers from unwanted attacks, Fail2ban is definitely worth looking into.

Take screenshots of your Android phone from Windows or Linux


Let’s say your client requires employees to have an Exchange account on their Android mobile devices. You decide to create user documentation with screenshots that help show how to add an Exchange account on Android. The bad news is taking screenshots of an Android mobile device is not a simple process. Instead of just loading an app on your phone and then taking the screenshots, you have to install the developer kit on your PC and snag the screenshots using that tool.

This tutorial shows how to take screenshots of an Android phone from the Windows and the Linux platform. I go into more detail on the Linux side because it’s more challenging.

Enable USB debugging


Before you can take screenshots from your Android phone, you have to enable USB debugging. To do this, tap your device’s Menu button and then tap Settings. From there, tap Applications | Development and make sure USB Debugging is checked.

Install the SDK


You need to install the Android SDK, which you can find on the Android Developer site. Choose the download for your platform and save it on your drive. After the SDK is downloaded, you need to extract the tool that will create a new directory ./android-sdk_XXX (XXX is the platform and/or the release number). Once the SDK is unpacked, you need to prepare your system for its use.

Install JDK


In order to use the Android SDK, you must install the Java Development Kit (JDK). If you’re using Ubuntu Linux, you open the Ubuntu Software Center, do a search for openjdk, and install the most recent version. If you’re using Windows, you download and install the JDK from the Oracle website.

Special instructions for Linux users


If you’re using Linux, the tool you must run to take screenshots is the ddms tool (Dalvik Debug Monitor). If you try to run the command ~/Downloads/android-sdk-XXX/tools/ddms (assuming you unpacked the SDK in ~/Downloads), you’ll notice three issues that need to be fixed.

1. You’re going to need sudo access, so the command must be run using sudo.

How to fix: use sudo when running the command.

2. The ddms tool doesn’t seem to be aware of everything it needs to run (especially adb).

How to fix: You have to instruct the SDK to run a full update. To do this, open a terminal window, change to the directory where the SDK was unpacked, change into the android-sdk-XXX/tools directory (where XXX is the platform and/or release number), and issue the command ./android update sdk. This will take some time because it has a lot of downloading to do.

3. Your phone cannot be recognized.

How to fix: The Linux system has no way of knowing how to recognize the make and model of the phone, so issue this command gksudo gedit /etc/udev/rules.d/90-android.rules, which will open up the Gedit text editor. You should add this line SUBSYSTEM==”usb”, ATTRS{idVendor}==”0bb4″, MODE=”0666″. Save that file and then restart your system. (Although someone might tell you that you can just restart the udev service with the command gksudo service udev restart, I have yet to see the command work with this particular process.)

Once the system has rebooted, log back in, open a terminal window, and issue the command to start the ddms. You should see your phone listed (Figure A). If you do, you’re ready to start snapping screenshots.

Figure A



Note: You can have more than one device here if you need. For that, you will have to create multiple udev rules if the devices are different.

Here is a list of popular vendor IDs. The vendor ID will differ for each model.

Acer
0502
Dell
413c
Foxconn
0489
Garmin-Asus
091E
HTC
0bb4
Huawei
12d1
Kyocera
0482
LG
1004
Motorola
22b8
Nvidia
0955
Pantech
10A9
Samsung
04e8
Sharp
04dd
Sony Ericsson
0fce
ZTE
19D2

 

Notes for Windows users


From the Windows side of things, you should only need to navigate to the directory you have unpacked the SDK into, change into the Tools directory, and then double click the ddms icon.

How to take the screenshots


Windows users and Linux users, follow these steps to take a screenshot:

1. Select the device from which you want to take a screenshot.
2. Click Device | Screen Capture.
3. When the new window opens (Figure B), click the Save button.
4. Navigate to where you want the image saved and give the image a name.

Figure B



If you change the screen on your Android device to save a new screenshot, click the Refresh button, and the new screen will appear.

Summary


Once you’re able to get screenshots of an Android phone, you’ll see that the ability to grab these images can go a long way to helping users learn how to use their tools.