Security Suite

[wayhigh]

I've begun working on a Security Suite (cool name to follow) that I'm going to need some testers for in the near future.

Features of the Security Suite (will) include:

1. Distributed (DDoS safe) blocking of known attackers for all protocols (it uses the firewall rather than modifying application code).
2. Dynamic updating of block-list from all Security Suite users.
3. Whitelisting known good servers.
4. Configuration testing for security settings.
5. Customized HIDS (Host Intrusion Detection System) installation to heuristical detection and response.

My goal is to enable the PIAF (and Asterisk but mostly PIAF) community to fight back against attackers by pooling resources. This way their attacking one site gets them banned not only on that one but on ALL of them.

Some of the things like the configuration testing are just to find and fix things that are simple but constantly causing problems for those here. Things such as bad passwords used for extensions.

Other things I've thought about include:

1. Security notification system -- to broadcast messages when critical updates are needed or when critical breach elements are found.
2. Centralized shutdown of breached pbx's -- from HIDS backend correlation engine.

Current Status:

1. RBL backend is functional.
2. Whitelisting & Blacklisting works.
3. Test blocking of HTTP protocol function with apache module functional. (Decision to change to iptables means I have to write a daemon to query & update iptables.)

If you have anything you'd really like to see, now's a good time to suggest it...

Kevin

 

[jroper]

Hi

I'm not sure whether a centralised shutdown is a good idea, but, something that stops outbound calls would be better, maybe a lockdown of traffic leaving the PBX, such as VoIP, SMTP etc - or a recorded message - Your PBX may have been compromised, please contact your PBX administrator

You may also find this project interesting - http://www.ossec.net/

It does let you know if any vital files have been messed about with.

Joe

 

[wayhigh]

Joe,

I'm planning on using OSSEC for part of it actually and have it running on my systems already.

As for the centralized shutdown, I think the ossec correlation engine should be capable of shutting down servers that are obviously breached.

One option instead of a shutdown is to put a deny any any rule as the first iptable so that all traffic is blocked. That wont stop any calls currently queued up for dialing though which is the problem.

If we just made the deny any any rule, some attacker would get the idea to drop call files into the queue directory and then those rules would only stop them from going out voip trunks but not pstn.

It's a feature that I don't think should be mandatory but if people want it enabled it should exist.

 

[jroper]

Hi

I trying to think of it from the customer's point of view.

Even on a breached server, he should still be able to receive calls - he has a business to run after all, even if outgoing calls are blocked in someway - he can resort to a cell phone.

So if outbound calls can be halted, the system locked down in some way so nothing more bad can happen - e.g. with a reboot and coming back up in some sort of safe and secure mode, which can only be unlocked by being on site from the console, or access only allowed from a predetermined IP address.

Joe

 

[wayhigh]

I hear you. I have an idea about how to fix that but it has some risks because it would interface with the kernel itself.

2 ways of doing it would be selinux and/or kernel modules.

 

[wayhigh]

Just a quick update:

Got the packet sniffing daemon functional.
Got the iptables test code functional.
Currently adding RBL client support.

 

[wardmundy]

Design-wise, let's not repeat the mistakes of our Green Brethren. Ideally, it would be great to have a module that ran on the PIAF server and sent requests to a host which responded with answers. This could be as simple as HTTP requests. And the host still could build a repository of information based upon data provided by those issuing queries. With this design, the PIAF server module then could decide what to do with the information based upon switches set by the owner of the server. And, because it's open source on the PIAF server, everybody is free to examine the code to see what's going on.

Starting with SUSHI, we will have a way to uniquely identify each PIAF server. We'd be happy to share this. Then it would be a matter of setting up registrations to be sure some creep isn't polluting the data with crapola.

For obvious security reasons, we all get nervous when some external source is making operational decisions about our servers without any of us being able to actually look under the hood. Just my $.02.

 

[wayhigh]

Ward,

I'd very much appreciate seeing what ya'll have done with Sushi and how you're identifying the individual installations.

My plan is to have this be a distributed system similar to the way Dundi uses peers so that any DDoS is pretty much worthless as it wont even stop one site let alone all of them.

As for it being open source, I wouldn't think of putting something out there that wasn't open source unless it was peer reviewed by authoritative sources. As soon as I get it to a point that I'm OK with people looking at my code I'll be posting it up for comments and suggestions.

 

[wardmundy]

Sounds great! Can't wait!

 

[TDF]

Engineer Tim that used to work for Fonality was very keen on having a shared blocklist like you mention, if you need any help on this project it may be worth contacting him.

 

[wayhigh]

as it turns out, this blocklist wont strictly be limited to asterisk by the simple fact that it is firewall based and doesn't rely on modifying applications.

Since you specify which ports you want it to work on, and which of the rbl's to pull from, you could set it up for smtp, imap, or whatever protocol you want.

For example, it could be used by web hosts to block proxies--and I have probably the biggest list of known proxies in existence because I wrote software to track and block them which is how the first version of this RBL stuff came about.

 

[wayhigh]

Update (Shell Accounts Wanted)

I have the RBL functional now, banning hosts including in the RBL, doing the lookups, etc.

At this point I need to do a bunch of testing and to do that I need shell accounts so I can connect to various dest ip/port combinations on the server and check to see the iptables jump works.

The RBL is already working for me. It seems that some chinese sites have been doing a slow scan against me and it picked them off and blocked them! (One of the test RBL lists is ALL foreign ip addresses).

How sweet that is!

Thanks,
WH

 

[cosmicwombat]

Joe, what about your management software? Is that going to be part of SUSHI and possibly used in some fashion towards those (these) ends?

Robert

 

[wayhigh]

BTW.. alpha testers needed..

 

[cosmicwombat]

I'd be down... except this part:
"Centralized shutdown of breached pbx's -- from HIDS backend correlation engine."

To close a shade of green for me.

 

[wayhigh]

I think there's a misconception about what I mean by that.

OSSEC works via a collector (backend) and agents. The agents feed the backend but the backend still resides on your system(s) and is controlled by you.

That feature is really for larger voip networks so that they can trigger an action to be performed when a problem is sensed.

I'd be down... except this part:
"Centralized shutdown of breached pbx's -- from HIDS backend correlation engine."

To close a shade of green for me.

 

[cosmicwombat]

Ah, well I am running OSSEC now.

Have you considered contributing to the project at:

http://www.securecentos.com/

?

I would think throwing some efforts ( with an Asterisk slant ) might be a really good thing.

 

[wayhigh]

Check this out.. 48 hours of running the RBL and here's what it caught already!

Chain CUSTOMRBL (1 references)
target prot opt source destination
DROP all -- 221.224.78.249 asterhome
DROP all -- 221.224.78.248 asterhome
DROP all -- 221.224.78.252 asterhome
DROP all -- 221.224.78.236 asterhome
DROP all -- 221.224.78.254 asterhome
DROP all -- 221.224.78.239 asterhome
DROP all -- 124.126.131.82 asterhome
DROP all -- 221.224.78.238 asterhome
DROP all -- 221.224.78.245 asterhome
DROP all -- 211.143.13.177 asterhome
DROP all -- 221.224.78.230 asterhome
DROP all -- 212-95-37-126.internetserviceteam.com asterhome
DROP all -- 221.224.78.253 asterhome
DROP all -- 221.224.78.234 asterhome
DROP all -- 93-97-194-193.zone5.bethere.co.uk asterhome
DROP all -- 221.224.78.244 asterhome
DROP all -- 221.224.78.237 asterhome
DROP all -- 221.224.78.241 asterhome
DROP all -- 221.224.78.240 asterhome
DROP all -- 221.224.78.235 asterhome
DROP all -- 58.208.244.145 asterhome
DROP all -- 221.224.78.246 asterhome
DROP all -- 221.224.78.226 asterhome
DROP all -- 211.147.250.145 asterhome
DROP all -- 221.224.78.247 asterhome
DROP all -- 222.187.220.162 asterhome
DROP all -- 222.187.221.88 asterhome
DROP all -- 58.253.67.58 asterhome
DROP all -- cpe-173-89-219-200.insight.res.rr.com asterhome
DROP all -- 87-126-31-177.btc-net.bg asterhome
DROP all -- 124.126.141.163 asterhome
DROP all -- 211.143.14.68 asterhome
DROP all -- 222.35.78.228 asterhome
DROP all -- 61.152.96.125 asterhome
DROP all -- 114.217.196.155 asterhome
DROP all -- 203.187.161.42 asterhome
DROP all -- 125.71.136.73 asterhome
DROP all -- bilbo.babinski.pl asterhome
DROP all -- 124.126.131.241 asterhome
DROP all -- 211.155.224.202 asterhome
DROP all -- 211.138.234.160 asterhome

I'm going to see if there's a way to get comments added so it lists the timestamp and reason for the add.

 

[wardmundy]

Yikes! :eekb:

 

[cosmicwombat]

From a deleted TB post by Ethan S (?):

Well, since this thread got deleted and it contained really good information and was linked from my blog, I thought I would re-post it.
This is in reference to the following news story: http://www.news.com.au/technology/story/0,28348,24939188-5014239,...
As a result of this article, I wrote a script that runs once a day and sends email alerts if call volume increases in any of the following 4 areas:
1.) Total outbound calls in the last 24 hours is higher than the threshold % versus average outbound calls per week day over the last 30 days
2.) Total international outbound calls in the last 24 hours is higher than the threshold % versus average outbound international calls per week day over the last 30 days
3.) Total outbound call duration over the last 24 hours is higher than the threshold % versus average daily outbound call duration per week day over the last 30 days
4.) Total international outbound call duration over the last 24 hours is higher than the threshold % versus average daily outbound international call duration per week day over the last 30 days
To download and install:

wget [URL]http://public.schmoozecom.com/AbnormalCallVolume-1.0-1.noarch.rpm[/URL]
rpm -Uvh AbnormalCallVolume-1.0-1.noarch.rpm
service crond restart
nano /usr/local/sbin/abnormal.php

Once editing the abnormal.php file, change the email address and if you would like daily reports regardless if thresholds were met, change $daily_report = false; to $daily_report = true; If you only want to receive reports if thresholds were reached, leave this as false. You can also change the threshold percentages if you so choose. By default an email alert gets triggered if any of the four areas described above increase by 20% or more in a day.
Update: And then the missing forum topics reappear...