Securing Vicidial

[farmerjim]

I've installed several vicidial systems always using vicibox and E1 trunks. My next one however will use SIP trunks in a managed office. The server will have a public facing NIC and an internal NIC. The provider has given me an iptables script to secure the server but although I'm familiar with vicidial I'm still a Linux beginner!
The question is therefore how do I best go about installing the script and then ensuring the rules persist across reboots.
I intend to use the latest vicibox iso release on a Dell t110 server.
I know there have been some discussions about this before but as I said I'm a Linux beginner so may need walking through this from first principles so to speak.

[williamconley]

without knowing what "script" they gave you, that's impossible to answer. also, vicibox does not take well to "just add a script" to iptables, it has its own fairly well thought out iptables security module. But Vicibox comes pre-packaged with holes in that security package all over the place.

our solution: http://www.viciwiki.com/index.php/DGG

[farmerjim]

Thanks for that. I wasn't aware of viciwiki so grateful for the pointer

it has its own fairly well thought out iptables security module

Can you be more specific about this security module. I've not come across mention of it before

[williamconley]

If you have a stock vicidial server, it will install itself nicely. Requires root user install and root mysql user password during install to create the dgg table for storage of authorized IPs. Otherwise ... the best thing I can say if you are nervous about installing it is to install it in a virtual server for practice and to see the results. The rest is in the Wiki

[farmerjim]

I've been doing some research and it appears the script generates iptables rules to secure the server from external access. Now I can run the script to generate the rules and then

iptables-save

thus saving the current ip tables config to /etc/sysconfig/iptables.
Where I'm getting confused is that I've seen Opensuse specific guidance that suggests I should be running the script to generate the rules, run

iptables-save /etc/sysconfig/scripts/SuSEfirewall2-custom

then edit /etc/sysconfig/SuSEfirewall2 changing

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

to

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

whereupon the rules should survive a reboot.
What I'm trying to do is get it right! If I use their rules, install them correctly and it gets hacked then I'm OK. If I take another tack to achieve the same end and I get it wrong then I'm not.
Or am I worrying too much and over analysing things here!

[williamconley]

iptables-save does not "save" anything to a file. it merely spills it to a screen unless you supply it with some form of pipe where to store the files. but for that to work: the iptables-save must be generating the rules you want ... then storing them and executing them means you'll not be able to change them later because they are now "hard-coded". unless you have them auto-save which is dangerous (ie: if a hacker managed to get a new Ip added through any means, it would then be there forever ...).

our system is built to use the existing files with slight modifications to allow specific IPs in one timeand turn off ports to stay off the radar, never do it again ... so no likelihood someone will piggyback a future attempt, at least for the "hard-coded" stuff.

All other IPs are visible in the interface which would give you a visual cue that something is "up" when a new Ip appears which should not be there. And so far, nothing like this has ever happened.

Our instructions show how to do this, if you want to come up with your own method, please feel free. If you find a method that is an improvement, please post it after testing it and we'll look at incorporating your changes. What we know is that ours works and so far has not had a single attempt, much less a breach (with the sole exception of a user who was hacked from Inside, social hacking is not something one can fix with technology! LOL).