Changing the SSH Port for IPTables

Gary Schafer, 15 December 2010

When I installed my own web server, I also did my best to ensure it was secure. I installed OpenSSH. I required a RSA key to access it remotely and removed the ability to access it remotely with just a password. And even if you could get to it physically, the password was quite long (though if you could get to it remotely, I have greater worries than just accessing the site). It wasn't that I was worried about the site itself. There's nothing sensitive here. But I didn't want my little server to serve someone else's nefarious purposes.

As part of my efforts, I wanted to change the default port through which SSH accessed the server. For a server running Ubuntu, this is a two step process. First step is to change the port setting in the /etc/ssh/sshd_config file. The second step is to change the iptables file.

First, let's change the port setting in the sshd_config file. I was already logged in (using SSH under the default port, which is port 22). I issued the following command:

That opened the text editor. Then I looked for the following line (which is shown in bold font below):

I changed this from the default port 22 to 2022, as shown below (again with bold font):

I'm not going to re-start the SSH server yet! The reason is that, if I lose my connection and try to get back in, I won't be able to because I've not changed the iptables file yet. I saved the file and exited the text editor.

The next step was the change the iptables. The problem here is that iptables is not a simple text file that can be changed. This is a bit more complicated. Still, it's straightforward. Start this step by saving the iptables as a text file. To do so, issue the following command:

What that command does is to create a text file that you can edit, then use that to set the desired port. Now we're ready to edit the text file. Issue the following command to open it using the "nano" text editor:

With the text editor open, look for a line (highlighted in bold font below) that has "SSH" in it. Note that this is only a small portion of the total file:

Now, change the "22" into the new port number, which in my case is "2022", as shown below:

Save the file and exit the editor. That part is done. Now, we need to make it so that iptables uses this new rule when it starts up. To do so, we're going to make a change to our interfaces configuration file. To do that, we need to do the following:

This opens the interfaces configuration file. Mine appeared as follows:

All I need to do now is to add one line to the end of this file, as shown below (with the appropriate line highlighted in bold font):

Finish this up by saving the file and exiting the text editor. All that's left to do (and cross your fingers) is to try this out. You can either restart both the SSH server and reload the iptables settings, or you can just re-boot the server. Your choice. I'm going to do both here. To restart both the SSH server and the iptables, I issued the following commands:

When I exited the remote connection, I tried to get back in by issuing the appropriate SSH command (NOTE: I'm on the local network.):

It worked! Okay, now to give it the ultimate test. Time to re-boot the server:

As soon as I issued the command, I was kicked off my remote connection. No worries. I waited 30 seconds and retried the connection. Again, it worked.

While I was figuring this out, I noted a lot of people with problems related to SSH and changing the ports. If you are trying to log in and receive a "connection refused" error message, that tells you that iptables is not the problem. At least, not yet. A "connection refused" message means that you're not using the port number that is the sshd_config file. However, if you instead try to log in and wait... and wait... and wait, then get a "connection timed out" error message, the problem is somewhere else. I'd suspect the iptables. The reason I got the "connection timed out" error was that iptables was not set up to allow the connection to this strange port number. Its rules were set up to simply drop such connection requests without telling the requester why. That's the best security. It's not in the rules, so sorry. Just drop it. Once I figured out that iptables was the problem, I took the steps outlined above and fixed the problem. If you're having problems with SSH, add the "-v" option so that it will give you an idea of what might be happening. The command will look like this:

There you are. I hope this helps someone.

Another Malware Infection Report

Gary Schafer, 12 December 2010

My next door neighbor's youngest son stopped over last Wednesday. Their primary desktop computer was having problems, he said. They keep getting a pop-up that won't go away.

Oh, boy, I thought. Here we go again.

I walked over and found the father sitting at the computer swearing at it. Not that that is abnormal. I've been known to swear all kinds of deprecations against my various computers. Still, he was swearing at it for a particular reason. Those popups. There they were. Your computer is infected!, it said. Click here to fix the problem. Clicking here didn't do anything but pop up another window that asked for money to get rid of the problem. Well, I'm not about that at all. After a bit of clicking around, I decided that it was, most likely, infected with some kind of malware. With his permission, I pulled the computer out, unplugged the dozen or so cables, and brought it home.

Here were the symptoms.

1. Those pop-up ads.
2. The "Task Manager" option was missing when I hit "Ctrl+Alt+Del".
3. Their anti-virus (McAfee) was not working properly and any attempt to run "Spybot S&D" also did not work.
4. Windows Updates would not install any security updates.

First things first. I set up a Ethernet hub (an actual hub, not a switch) so that I could monitor the computer's network packets. I connected both the desktop and my laptop. My laptop is running Ubuntu 10.10 as the OS, and I used Wireshark to capture the packets. Once my laptop was running with Wireshark operating, I booted up the computer. Sure enough, there were the pop up ads. I ignored those and concentrated on the Wireshark captures. I started looking through every IP address it listed. I hoped that one of them would give me some clues. I hit paydirt on about the sixth one. It listed an IP address of 69.197.158.250. A quick peek inside the packet showed a URL (universal resource locator) of "http://go-thailand-now.com". A Google search of that URL showed several hits related to "malware". I also found an excellent analysis of what was probably happening in this desktop. Short answer was that somehow the computer became infected and became part of a spam botnet. The connection to the go-thailand-now.com URL was part of its coding to get more data. Probably download more spam and then begin sending it out.

I setup a display filter in Wireshark as follows:

That showed every packet containing the URL. It also provided several other IP addresses. Along with the original one of 69.197.158.250, I also found 204.45.119.10, 204.45.119.42, 204.45.119.50, and 204.45.121.42. Hmmm. Sensing a pattern here. They seem to have a block in the 204.45.x.x domain and perhaps another in the 69.197.x.x domain.

I performed a "whois" on these IP addresses. The 204.45.x.x addresses are registered to "FDCservers.net", a company (allegedly?) based in Chicago, Illinois (USA). The entire /16 block, meaning from 204.45.0.0 - 204.45.255.255, belongs to them. They have a very professional looking web page, complete with all kinds of details on how anyone can use their "unmetered bandwidth". Apparently, that's not a lie. The 69.197.x.x addresses belong to Wholesale Internet based out of Kansas City, Missouri. From the ARIN (American Registry for Internet Numbers) report, Wholesale Internet controls a /18 block from 69.197.128.0 - 69.197.191.255.

One thing that was interesting, though, was that there was no DNS call to the go-thailand-now.com URL. That meant that it had to be hard-coded into the malware. To me, that means that the people responsible for this malware are in it for the long-term. Plus they are not worried about getting caught. If they were, they would have hidden their tracks better. But they didn't.

Another interesting aspect was the fact that all of the communication I saw was standard HTTP (hypertext transfer protocol) over port 80. As mentioned in a book I read called "Crimeware: Understanding New Attacks and Defenses", the malware people are using this method for communication more and more because almost every firewall is open to this particular port. They have no problem getting through, in other words.

Time to get rid of this sucker. I started by removing the infected hard drive, putting the hard drive into an external case, connected it to my Linux computer, and backing up all of their data. I then connected used an XP machine running under VMWare to run Norton Internet Security 360. Norton reported a total of 9 infected files. I let Norton clean those up, then I put the hard drive back into the its own shell. When the computer came up, I noted that it seemed to be working faster. I then ran Malwarebytes from the computer itself. It found and fixed 245 infected files and registry entries. So much for Norton. However, at this point, I noted that the "Task Manager" was back. There was still a problem, however. It was still calling home.

Since I'm such an idiot, I didn't think to block the connections back to "the mothership". I accessed my firewall and set it to block all connections to those two IP ranges (204.45.x.x and 69.197.x.x). From that point on, I could see the computer trying to access those IP addresses, all to no avail. Still, the sucker was still there. I pulled the hard drive out again, put it back into the external shell, then ran Norton, Malwarebytes (externally this time), Avast, McAfee and Kaspersky. All of them except Malwarebytes found problems. The rest claimed to have fixed their problems.

One last time. I put the hard drive back into its original system and started it up. I kept an eye on the Wireshark, though. No attempts to connect to the mothership. Also, Windows Updates were back, McAfee was working again (no reported problems when I did a full scan), and Spybot was working again. I let it run for an hour and a half, all with no bad connection attempts. The sucker was dead. Finally.

The nice thing to know would be "How did it happen?" I wish I knew. The computer is used by both parents and the youngest son. But the father said that it started when he was on the computer. So, it may have been a "drive-by" infection. Hopefully, it won't happen again.

Here's a Random Fact...

The 9/11 Count: