My Asterisk PBX was hacked and someone in Moscow made $100 of calls before I caught them. I am in the process of changing passwords or locking down everything.

This is what I have done so far:

Disabled web access through the firewall to my PBX from outside of my network.

Changed all passwords on PBX users – root, maint on my PBX

Changed SSH port from 22 to 2222

Changed SIP password several times! This is more of an Asterisk issue.

My biggest concern right now is that the hackers were somehow able to get into my PBX and see the SIP changes I was making.

I do not see any accounts logged into my PBX except root when I log in. I have checked all users on the PBX and looked to see when their passwords were changed and the only user with a changed password in the last year is root (which I changed). So I don’t think they have created another user and given it root access.

I have the following ports open on my firewall for the PBX:

TCP Any -> 5004-5082
UDP Any -> 5004-5082
UDP Any -> 10000-10500
TCP Any -> 2222

Is there anything else that anyone can think of that I should check?

Also, is there a way to run a firewall on the PBX itself to restrict the incoming IP addresses (my firewall doesn't support this). This way I could limit incoming connections to my SIP provider and further reduce the ability for a hacker to use my SIP account. Thanks.

OK, locking things down at this point is relatively useless unless you know how they got in in the first place. The way this forum works is that we like to see people who think they've been cracked to do some basic forensics to develop some facts about the machine and try to discover how the intruders gained access. In that spirit, it would be very useful to understand more about this machine such as which version of Linux you're running, how recently it was patched, what kind of network environment it is in and any services besides Asterisk that are running. It would also be useful to start going through your log files and see if there are any clues to what happened. Going through root's .bash_history as well as those of any suspect accounts would be good. And any details about how you discovered the breach would be useful.

Are you able to physically access the machine or are you logging in as root over SSH? And why are you logging in as root in the first place? I will admit I know very little about Asterisk, but in general you should only log in as root when you absolutely need to, not as a matter of course. Also, do you know what account was used to make the unauthorized calls?

Thanks for the reply. The linux is part of the Asterisk distribution so I don't know much about it. Plus I am travelling right now, hence I am accessing via SSH.

I only opened up SSH when I started to resolve the issue so I don't think the compromise ocurred through a user login. According to the Asterisk forums it is possible to gain access through the open ports and force in through extensions on the PBX by guessing their passwords. So I am in the process of changing these!

What I want to do is set up a firewall that restricts access through the open ports to specific IP addresses. In this case I will limit access to the IP address of my VOIP provider. This will prevent the hackers from accessing. My current external firewall does not support this. Is it possible to run a firewall on the server itself that can do this? Thanks

In general, guessing about how intruders got in isn't a particularly safe way to go. If you're right, I would think there would be some logs showing which account made the unauthorized calls. Those logs would be a good starting place to investigate.

Also, if you're currently allowing root login via SSH you need to stop and establish better procedures. Now.

That is a fairly trivial thing to do in an iptables firewall. In the same lines you limit port access, you specify the IP address that is allowed. Are you at all familiar with writing iptables rules?

But again, since you have been compromised, it is unwise to trust this machine without doing further investigation into what happened. If the bad guys managed to install their own software, they may be able to evade your firewall. Also, normally we advise people who have compromised machines to take them off the net, or at least restrict access to SSH only and then only from trusted IP addresses.

I am reasonably confident that the attack took place through insecure passwords on extensions on the PBX. The log files of the PBX show the illegal calls coming from extensions within. It appears that they attempted to connect to standard extensions, 201,301, etc. and used some algorithm to guess passwords. Obviously these passwords are now more secure and so far there has been no further illegal activity.

However, in order to rule out an illegal login into the server itself. I would like to check all logins that occurred over the last 45 days since this started happening. I have looked through the forum and on the web, and cannot find a simple way to do this? Can anyone advise on this?

Also, I will install iptables as soon as I am back in front of the unit. I have not done this before but I will figure it out!

Thanks.

The 'w' and 'last' are some commands that could help with that. However, you can't "rule out an illegal login into the server itself" just by looking for suspicious logins because:

1. Attackers with sufficient access can either modify logs and/or install and use software that doesn't create log records.

2. If you've been compromised, there will almost always be more evidence of compromise than just suspicious login records.

If it had been me doing that hack-in, the useful commands would have been replaced with versions that hide the real infection vector, and just show you some fake one you can delete and think you are good.

So short of reinstalling the server, or cutting it off from the outside world, what is my best course of action to establish if I have been hacked?

FYI - I have had no illicit PBX activity for 36 hours - although this is not a conclusive outcome it does point to the fact that I have potentially closed the hole.

This coupled with the fact that I did not have SSH access turned on in my firewall lead me to believe (with some confidence) that I have been successful.

Since there hasn't really been any investigation, I'd say that talk of remedies is kind of premature.

Yes, that is one interpretation. However, you don't seem to have looked for evidence that might contradict your theory. I'm not saying your wrong by any means, but when you don't look for things that might contradict your thinking, things can seem rosier than they might be.

At very least I'd look to see what is currently running on the machine:

ps -afxwwwe
netstat -pane
lsof -Pwn

And again, knowing what distro you're running Asterisk on would help us give you a bit more specific advice.

Is this from the system logs or the Asterisk logs?

Iptables is part of the kernel, so there shouldn't be anything to install. This tutorial is worth a good read if you want to get going.

I have done quite a bit of research on the server - looking at the various userids, when they last logged in, etc. The biggest reason I think that the compromise didn't happen this way is because I didn't have the SSH port open to the outside world, still don't. Unless they were able to log in through one of the VOIP ports?

I am back home now - the server is CentOS Release 5, Kernel 2.6.18-53.1.4.el5.

I am going through the IP Tables tutorial now. Thanks for the link

Well, ssh is merely one way in. From what you posted, the bad guys did gain some level of access. All I'm trying to get across is that since you were compromised, it is usually worth the time to look and see if there is anything unusual going on. Ultimately it is your machine and your decision.

On another note, are you sure that the PBX is actually configured correctly? For example, have you made sure that callers cannot pick up an outside line when they dial in - this is certainly possible on misconfigured PBXs and an old trick but most modern PBXs disable this sort of 'feature' by default these days!

Cheers,
Steve

Pretty sure that is an under-patched kernel. I believe the current level is 194? You may want to try running an update on your system just to make sure you have all of the latest patches.

nomb