vicidial.org

IF you have installed Vicibox Redux 2.0 or Vicibox Redux 3.0 and have not altered your firewall settings, the following commands will remove this entire subnet's ability to send any traffic to your server (no warranty of course, this is free stuff!):

Immediate (but temporary, will not survive a reboot) fix:

Code: Select all

iptables -I input_ext 2 -s 113.0.0.0/8 -p all -j DROP


I highly recommend that you use the above command to lock out IP address range 113.0.0.0 – 113.255.255.255 from all servers immediately.

This particular range is entirely located within China.

If you are curious to see whether you have had any of the same type of attacks ...

Code: Select all

mysql asterisk -p --execute="SELECT * FROM vicidial_did_log WHERE left( channel, 7 ) = 'SIP/113'"

Then look in the "Channel" column for the IP address immediately after "SIP/".

Do you have any calls from this IP range?

Handy Tool to view your IPtables:

Code: Select all

iptables -L -v --line-numbers

--REVISED-- Thanks Kumba for pointing out that "iptables-save" does not "save" LOL

Step By Step Process to add this specific "Bad Guy" to a permanent lockout (obviously this process will work for any IP address range! and YES if you put in more than one it should work fine, just put in multiples and change the IP address range to lock out some other IP range, and POST your results after a reboot so everyone knows it works and on which .iso installs!)

1) View your existing rules

Code: Select all

iptables -L -v --line-numbers

2) Verify they have these lines present:

Code: Select all

Chain input_ext (2 references)
target     prot opt source               destination
DROP       all  --  anywhere             anywhere            PKTTYPE = broadcast


3) Enable Custom Firewall Loader

Code: Select all

nano +874 /etc/sysconfig/SuSEfirewall2

change

Code: Select all

#FW_CUSTOMRULES="/etc/sysconfig/scripts/SuSEfirewall2-custom"
FW_CUSTOMRULES=""


to (just moved the "#" from one line to the other)

Code: Select all

FW_CUSTOMRULES="/etc/sysconfig/scripts/SuSEfirewall2-custom"
#FW_CUSTOMRULES=""


4) Disable this IP address range in custom rules

Code: Select all

nano +45 /etc/sysconfig/scripts/SuSEfirewall2-custom

Change

Code: Select all

fw_custom_before_port_handling() {
    # these rules will be loaded after the anti-spoofing and icmp handling
    # and after the input has been redirected to the input_XXX and
    # forward_XXX chains and some basic chain-specific anti-circumvention
    # rules have been set,
    # but before any IP protocol or TCP/UDP port allow/protection rules
    # will be set.
    # You can use this hook to allow/deny certain IP protocols or TCP/UDP
    # ports before the SuSEfirewall2 generated rules are hit.
 
    true
}


to (added the line above "true" which disabled that IP range)

Code: Select all

fw_custom_before_port_handling() {
    # these rules will be loaded after the anti-spoofing and icmp handling
    # and after the input has been redirected to the input_XXX and
    # forward_XXX chains and some basic chain-specific anti-circumvention
    # rules have been set,
    # but before any IP protocol or TCP/UDP port allow/protection rules
    # will be set.
    # You can use this hook to allow/deny certain IP protocols or TCP/UDP
    # ports before the SuSEfirewall2 generated rules are hit.
iptables -I input_ext 2 -s 113.0.0.0/8 -p all -j DROP
    true
}


5) Verify it worked! After a reboot run iptables -L again and verify that it now has this:

Code: Select all

Chain input_ext (2 references)
target     prot opt source               destination
DROP       all  --  anywhere             anywhere            PKTTYPE = broadcast
DROP       all  --  113.0.0.0/8          anywhere


Thank you very much for posting this William!

We will be building an iptables "friendly commands" firewall utility to make it "easy to add enemies", and then testing it. I'll be posting it as soon as we're done with testing. Goal, of course, being to make it simple to add an IP or IP range that should be LOCKED OUT.

Fail2Ban is nice, but seems like it has a tendency to "overcompensate". In most cases for clients I've dealt with, they find an entry in a log or recognize activity (registration, etc) from a "bad guy" and simply want to be able to be sure that IP address is locked out permanently.

So we'll start there and keep on movin. This was our first run with it utilizing the firewall setup that Kumba provided. It may be as simple as scripting additions for this setup of Kumbas ... but we may "rebuild" the entire iptables setup first. We'll see how testing goes.

Some things should be available purely for the safety of all these people who support this cool VICIdial frenzy (directly or indirectly, even lurkers are training their personnel in the USE of VICIdial, which will ultimately create more users! )

If you want to add another IP address (and another ... and another ...) you can simply recycle this command and substitute a single IP like this (replacing the xxx.xxx.xxx.xxx with a single ip address).

Code: Select all

iptables -I input_ext 2 -s xxx.xxx.xxx.xxx -p all -j DROP
iptables-save

This can be repeated as often as you like and will continually add "bad guys" to the top of the "bad guy" list.

For those of you nervous about the length of time it will ultimately take for IPtables to "approve" a packet: the system Kumba provided already accounted for "existing connections" to be immediately approved (so a phone call, once in progress, is immediately accepted without delay). We added the bad guy list AFTER this so the "bad guys" will be kicked out slowly but the GOOD GUYS will be approved immediately based on prior acceptance.

Instead of recreating the wheel, you can just make use of the SuSEfirewall2-custom file which will allow you to insert your own custom rules at varying points in the firewall init process.

That file can be found here: /etc/sysconfig/scripts/SuSEfirewall2-custom

And it needs to be enabled in here: /etc/sysconfig/SuSEfirewall2 (just search for 'custom' and you will find where to enable it)

That should pretty much give you everything you would want in order to further customize the firewall set-up. The other nice thing is it keeps it inline with the SuSEFirewall, meaning it won't have to be recreated everytime the update it. This file is also just a bash script, so you can have it run supplemental files which can just be a laundry list of rules.

Thanks. I was looking at the concept of redesigning it specifically to allow for adding/removing "good guys" and "bad guys" with a GUI interface easily.

The present system doesn't really appeal in that fashion, and most of my clients are NOT planning to use yast to modify their firewall settings to add/remove anything. (and let's be real: they would break something if they did!)

GUI only!

I will, however, look at the possibility of modifying the present version to "fit that in" before "full rework", of course.

My point for posting the custom firewall script was that you can have it then further call a script, like /root/some-firewall-rules.sh. This file can be nothing but iptables commands you want to run.

Then all your web gui has to do is write out the file at /root/some-firewall-rules.sh. So you accomplish what you want within the framework that is already there with as little recreation as possible. You also still maintain the ability to control the network environment within yast which gives you quite a lot of control for 90% of what you will ever need it for.

Not trying to talk you out of anything, just saying for what you want to do, this is how I would approach it.

Ohh, and as a side-note, that 'iptable-save' doesn't really work in OpenSuSE. As soon as you reboot the SuSEfirewall2 program nukes and creates it's own rules from it's own configs. Just something else for you to double check.

Thanks for the suggestions!

LOL: the save just dumps it to the screen (or stdout) so YOU can save the settings. cute. not entirely helpful, but cute.

so the first version will have to be your suggestion of simply "plugging it in" to the existing iptables, and we'll work on making it easy to add more and remove entries later.

I just wish more people would register their results from the 113.0.0.0 subnet search. I had a total of four completely unrelated clients on widely varied networks who had entries. It would be interesting to find out how widespread it was (so even a "no" vote is useful).

Revised the top entry with Step By Step (TESTED) procedure that survives a reboot. (It was late, ok?)

Later we'll add external database access to allow adding multiple entries into a table or some such, but then again This Works.

Anyone in need of "lock this guy out of my system right now!" can do so.

(Thanks again Kumba, I can't believe I "assumed" that save would save without checking it!)

Hi,

Thank you for this post I look forward to testing it out.

I currently use Fail2ban and get allot of attacks from Asian countries.

I found a website called find ip address it is a dot org address. (cant post the link as new to vicidial forums) But it gives the IP range of all countries.

I was thinking a good modification to your scripts would to be deny everything with iptables then only allow the Australian IP range. Was wondering if this would be possible?

Simpler solution; deny all addresses and then only allow the addresses of the agents and managers who should be able to access the system.

Good Guys Only (Is that a gender biased thing? Am I gonna get in trouble for that?)

Even though if you only use packet filter as security mesure you still not safe, at least this was not enough for me, with my SIP Trunks, the carrier provides me just bandwith necesary to my number of channels and no more .

2 months ago i was receiving attacks from Korea trying to log on 3 of my systems by bruteforce and they were flooding me with packages, i blocked them so my packet filter rejected the packets, but the packets was still going through my bandwidth, even when my system was blocking them. The quallity of the calls turns pretty bad because of the lack of bandwidth, i had to ask my ISP to block the traffic directly from their routers.

But if you have 100 Mb conection this will not be a problem =P, but here with that limited bandwidth was a real pain in the assassin .

We have found that the packet version will stop access and stop FUTURE attacks. Most brute force attacks rely on the first few packets getting a response of some sort ... then they Attack. If the iptables refuses the initial attempt, they never seem to brute force attack at all. (Understandable, since they cannot see the server and have no expectation of success.)

However, once an attack is "under way", you must "wait them out". And often they will repeat the attack a couple more times before giving up. (Automated attacks, of course.) OR change your IP address!

So far.

i decied to put those servers on paranoic mode and only allow traffic to and from the SIP Servers . If i need remote access i use the VPN instead n_n.