The new Vicibox 8.1 integrated firewall

[dspaan]

Integrated Firewall - /usr/local/bin/VB-firewall.pl
- Run it with --debug to see it's flags and what-not
- the ACL is persistent across a cluster as it's stored in the DataBase
- By default only the voipbl.org black list is enabled
- You will need to enable IP Lists in ViciDial to edit the built in black/white list
- The white list is in an IP List in ViciDial called 'ViciWhite'
- You'll need to do a 'touch /etc/sysconfig/scripts/SuSEfirewall2-viciwhite' to enable loading the whitelisting rules
- The black list is in an IP List in ViciDial called 'ViciBlack'
- The white/black lists support CIDR notation as well as single IPs
- White/Dynamic lists are mutually exclusive from Black/VoIPBL/Geoblock, so one or the other
- /etc/sysconfig/scripts/SuSEfirewall2-custom can be modified to control IP ACL blocking I.E. block everything instead of just IAX/SIP/RTC, etc
- Uses IPSet rules which is dynamic and many orders of magnitude faster then individual iptables entries
- The White/Dynamic/Black IP ACL is persistent across a cluster, so all servers have the same IPs listed
- RFC1918 IP address' are added by default when whitelisting is enabled
- The Dynamic function searches for valid user LOGINs from vicidial_user_log for the last 14 days, and allows those IPs to get to SIP/IAX/RTC
- You'll need to do a 'touch /etc/sysconfig/scripts/SuSEfirewall2-vicidynamic' to enable loading the dynamiclist rules
- Firewall only applies to the 'External' zone, Internal zone is still unprotected
- Geoblock is just a call to /usr/local/bin/ipset-geoblock and works without internet connectivity
- VoIPBL black list is just a call to /usr/local/bin/ipset-voipbl but requires internet connectivity
- You'll want to change the crontab entry to run every minute for White/Dynamic/Black lists, I.E. * * * * * /usr/local/bin/VB-firewall.pl
- You only need to run the voipbl list every few hours, so create new crontab entries for the other stuff
- The white/black IP lists don't care if it's active in ViciDial, so it's recommended to leave them inactive to keep them from conflicting with other things in ViciDial

There's lots going on here with the Firewall, and modifying IPtables and firewall scripts has a high potential to block the network from the server. If you aren't super comfortable with that I would suggest you play with it on non-production servers or wait until I can make a more detailed manual for it.

I did a 'touch /etc/sysconfig/scripts/SuSEfirewall2-viciwhite'
And then did /usr/local/bin/VB-firewall.pl --debug
The whitelist in the manager interface has one entry and is set to inactive.

The debug output says:

/usr/local/bin/VB-firewall.pl --debug
ViciBox firewall white/dynamic/blacklist integration

----- DEBUG Enabled -----

ViciBox firewall integration

Database Host : localhost
Database Name : asterisk
Database User : cron
Database Pass : 1234
Database Port : 3306
White list : Disabled
Dynamic list : Disabled
Black list : Enabled
Vici Black List : viciblack
IPSet Black IPs : badips
IPSet Black Nets : badnets
VoIP Black List : Disabled
Geo Block list : Disabled


Generating Black List from IP List 'viciblack'...
Found 0 IPs to process
Writing IPSet rule files to /tmp//VB-BLACK-tmp and /tmp//VB-BLACKNET-tmp
Loading Black list IPSet rules into Kernel
Black List had been loaded!

Did i miss something?

Also, can i still use yast firewall or will that break stuff in combination with this new firewall?

[ccabrera]

I'm guessing you need to specify the --whitelist=ViciWhite option. There's more info by using the --help:

Code: Select all

/usr/local/bin/VB-firewall.pl --help
allowed run time options:
  [--noblack] Do not process the Black List, On by default
  [--white] Process the white list
  [--dynamic] Process the dynamic list
  [--voipbl] Download and Process the voipbl.org Black List
  [--whitelist=ViciWhite] ViciDial IP List for white list
  [--whiteips=whitelistips] IPSet name for white list IPs
  [--whitenets=whitelistnets] IPSet name for white list networks
  [--dynamicset=dynamiclist] IPSet name for dynamic list
  [--dynamicage=14] How long in days to look for valid agent logins
  [--blacklist=viciblack] ViciDial IP List for black list
  [--blackips=badips] IPSet name for black list IPs
  [--blacknets=badnets] IPSet name for black list networks
  [--flush] Flush all IPSets; May remove access if white list enabled!
  [--quiet] Be quiet and give no output
  [--norfc1918] Do not automatically add the RFC1918 IPs to whitelist
  [--test] = Test run, don't actually do anything but compile data

  * The white/dynamic options disable the black/geo/voipbl options. If you are
    only allowing certain IP's to connect in then it doesn't make sense to block
    anything since everything is blocked by default.


[dspaan]

I guess you're right. What's the best way to run this firewall with all the options on system boot?

/usr/local/bin/VB-firewall.pl --white --whitelist=ViciWhite
ViciBox firewall integration

Database Host : localhost
Database Name : asterisk
Database User : cron
Database Pass : 1234
Database Port : 3306
White list : Enabled
CLI White List : ViciWhite
IPSet White List IPs : whitelistips
IPSet White List Nets : whitelistnets
RFC1918 White List : YES
Dynamic list : Disabled
Black list : Disabled
VoIP Black List : Disabled
Geo Block list : Disabled


Generating White List from IP List 'ViciWhite'...
Found 2 entires to process
Adding RFC1918 IPs to white lists
Writing IPSet rule files to /tmp//VB-WHITE-tmp and /tmp//VB-WHITENET-tmp
Loading white list IPSet rules into Kernel
ipset v6.29: Error in line 1: Set cannot be created: set with the same name already exists
White List had been loaded!

I used another machine to connect to a VPN and then added that IP to the whitelist and ran the firewall again as you can see above but i still can't connect. Must be doing something wrong.

[Kumba]

You need to add the --white option to enable whitelist processing. The whitelist and dynamic list are mutually exclusive from the black lists and geoblocking and voipbl.org. Why do you need to block anything when everything is already blocked by default and only those on the whitelist or dynamic list are allowed in.

The other important thing to remember is that by default this is all only controlling access to SIP 5060, IAX 4569, and RTC 8088. The firewall out of the box doesn't block web connections.

So shooting from the hip, this is how you enable white lists:
1) Run 'touch /etc/sysconfig/scripts/SuSEfirewall2-viciwhite'
2) Run 'yast firewall' and remove UDP port 4569, 5060, and TCP port 8089 from the Advanced tab under Allowed Services
3) Comment out the two default VB-firewall entries
4) Add this to the crontab below the commented out entries in step 3 : * * * * * /usr/local/bin/VB-firewall.pl --white

When done, the only thing allowed to connect to SIP, IAX, or RTC will be what is in the whitelist. If you want to make whitelisting be everything or nothing then you need to edit /etc/sysconfig/scripts/SuSEfirewall2-viciwhite, find the whitelist rules, and remove the port matching stuff. It should go from 4 rules to just 2 if you do that. If you enable the whitelist for everything then that defeats how the dynamic list works.

The dynamic list searches vicidial_user_log for valid agent LOGIN events within the last 14 days. Those that it finds it then inserts into the dynamic IPset list to allow them to connect to SIP/IAX/RTC. Obviously if you block everything then no agent can LOGIN so no dynamic entries will ever be created.

[dspaan]

Ah i was wondering what that dynamic list function did, that's pretty cool!

So how secure is this new vicibox version compared to earlier versions and compared to DGG? We always used Dynamic Goodguys in the past and closed of ports 80 and 443 for the outside world and allowed at-home workers to connect through the goodguys port 81 setup. Since this firewall config will assume ports 80 and 443 are open won't this make vicibox servers more vulnarable to hackers?

As far as i know there still is no strong password policy and regular agents can't be forced to change their password upon login. Also some sort of alert email report about failed logins would be great so you can be alerted if your server is being brute force attacked.

[Kumba]

Any means that allows dynamic access is not secure. So if your worry is ultimate security then you need to stick only with a white list and have a different channel of authorizing/verifying IPs. But since no one wants to, or likely has the time, to maintain such a stringent security measure we have to compromise and allow some sort of dynamic IP authorization. DGG is one way to accomplish that through a third-party simplified portal unrelated to the application at hand. The VBF (ViciBox Firewall) approach is to have the application itself be the authentication portal and simplify the amount of setup/training involved. Both approaches have pluses and minuses so chose whichever you prefer.

The primary focus of VBF is to prevent toll fraud through SIP/IAX/RTC brute force attacks. For every one clasically compromised system (botnets, rootkits, DDoS zombie, etc), we have at least a hundred systems compromised from a SIP brute force attack with potentially thousands of dollars of toll fraud being created. Out of these hundred systems, maybe 2 or 3 were compromised by someone getting in through the ViciDial web interface. Those that did get exploited this way had weak passwords and a disgruntled employee involved in the mix. But everyone has differing opinions which is why I tried to make the VBF as flexible as possible.

But you can have a portal-based setup like DGG just insert it's IP's into the ViciWhite IP List in the vicidial database and VBF will take care of the rest across a cluster of dialers for you. The big problem is expiring IP's once they are put into the IP List. Since VBF works from database entries you have to be careful how you manage that.

[dspaan]

The hacked servers through http(s) you have seen, were those manager logins or agent logins? And if so what were they able to modify once they gained access? We have also been the victim of toll fraud, so i know what you mean.

In the releasenotes i saw you mentioned:

SNMP configs for network monitoring (Icinga2/Nagios/etc)

I'm running Nagios since a while now but haven't gotten to setting it up properly. Can you tell more about the SNMP configs? What's the best way to set up monitoring? I remember i installed NRPE but it still needed a lot of manual editing of config files before i could monitor anything. Is it possible to get an alert on Nagios when a server is getting brute forced?

[Kumba]

The hacked servers through http(s) you have seen, were those manager logins or agent logins? And if so what were they able to modify once they gained access? We have also been the victim of toll fraud, so i know what you mean.

The exploits were done through the Lead Loader or something else like phpMyAdmin not secured. The last one was a year or two ago and they've all been patched. We had one or two systems get attacked through heartbleed which just required any sort of SSL connection exposed to the internet. So if you have DGG with SSL on port 81 exposed to the internet you would have been vulnerable if you aren't patched up.

Compared to that we've had hundreds if not thousands of clients with toll fraud, asterisk stability and crashing issues, and bandwidth problems from SIP attackers hitting SIP on UDP port 5060. Most notably was Asterisk 11 and how frequently it would crash when a SIP brute force would hit it.

I'm running Nagios since a while now but haven't gotten to setting it up properly. Can you tell more about the SNMP configs? What's the best way to set up monitoring? I remember i installed NRPE but it still needed a lot of manual editing of config files before i could monitor anything. Is it possible to get an alert on Nagios when a server is getting brute forced?

The configs are to help prepare ViciBox v.8.1 for ViciNoc which I'm actively working on again. As far as Nagios goes I couldn't tell you. The whole nagios set-up and configuration just frustrates me. I moved to Icinga2 with IcingaWeb2 years ago and haven't looked back since. Icinga2 started as a fork of Nagios so it has excellent compatibility with all the Nagios modules but it's so much easier to get up and running. The IcingaWeb2 interface is also superior from what I've seen. As far as an email it's posisble you just need to find a plugin that can somehow get that data from the server. We use HOMER5 on our hosted to monitor SIP brute force attempts which is also in ViciNoc. We have it integrated into our hosted black list so that as it sees brute force attempts it adds the IP to the blacklist and within a few minutes all of our servers quit talking to that IP.

[williamconley]

The hacked servers through http(s) you have seen, were those manager logins or agent logins?

Ours have primarily been SIP or IAX accounts. This has gotten us a lot of business doing lockdowns (even after providing the DGG link, they don't want to risk any more damage so they have us do it). It's rare to have an actual agent or admin password hacked in the last few years.

This is part of the reason sip extensions should never be numeric but alphanumeric instead. Most brute force sip account attacks work from sip extension 100 to 10000 and then move on to the next prospect system (they'll rotate back around to you in a couple hours or days).

SIP/IAX removes the need to actually interact with apache or php or any other interface: guessing a sip account password allows making calls immediately. Then they just need to find the appropriate dial prefix.

Inbound also generates a problem if they are able to hit your system at all. They'll generate inbound calls with various patterns to see if "inbound" can become "outbound" if you've been bad and set a dial pattern up in this fashion.

[Kumba]

The other thing is the guys who are trying to exploit SSL's heartbleed or phpMyAdmin or something like that are likely going to set-up a program to mine bitcoins or make your system part of a botnet or DDOS zombie. Most of the time the only way someone finds out this has happened is when all their bandwidth disappears and they don't know why or the server is overloaded with almost nothing going on. Most of the time the system will sit there quietly for weeks or months until this happens.

Now the guys sniffing around port 5060/4569/8088/8089 are the ones that will brute force you, cause asterisk to crash half a dozen times a day, and if they get in spend thousands of dollars (or however much is on your prepaid carrier account) in toll fraud. Financially and to a degree functionally they are easily an order of magnitude worse then your classic hack like above.

See it's all about following the money. When they do a port scan they see UDP port 5060 open for SIP they know that there is money to be made if they can place outbound calls through that server. Other then that some random web server with a domain name of no real importance has no real value to anyone else other then as a cryptominer or a botnet zombie. The barrier to entry of doing a SIP brute force attack is also MUCH MUCH lower then anything else as well.

[williamconley]

Very true. Those botnet bastards are truly insidious, too. They plant enough viruses in enough places to make it easier to wipe and restart than it is too try to clean the system. Of course, it's kinda cool that reinstalling Vicidial with Vicibox is so damn easy. Tx Kumba.

[Kumba]

Very true. Those botnet bastards are truly insidious, too. They plant enough viruses in enough places to make it easier to wipe and restart than it is too try to clean the system. Of course, it's kinda cool that reinstalling Vicidial with Vicibox is so damn easy. Tx Kumba.

Just make sure you have working backups and it's a pretty simple fix.

[dspaan]

The configs are to help prepare ViciBox v.8.1 for ViciNoc which I'm actively working on again. As far as Nagios goes I couldn't tell you. The whole nagios set-up and configuration just frustrates me. I moved to Icinga2 with IcingaWeb2 years ago and haven't looked back since. Icinga2 started as a fork of Nagios so it has excellent compatibility with all the Nagios modules but it's so much easier to get up and running. The IcingaWeb2 interface is also superior from what I've seen. As far as an email it's posisble you just need to find a plugin that can somehow get that data from the server. We use HOMER5 on our hosted to monitor SIP brute force attempts which is also in ViciNoc. We have it integrated into our hosted black list so that as it sees brute force attempts it adds the IP to the blacklist and within a few minutes all of our servers quit talking to that IP.

And where can i find these SNMP configs? I know, Nagios is so frustrating indeed. I also tried NagiosQL but it was just as unhelpful setting things up. I'll try IcingaWeb2, thanks. So when do you thing ViciNoc will be ready? If you need a beta tester, let me know. HOMER5 looks great!

It's rare to have an actual agent or admin password hacked in the last few years.

But agents and even supervisors often have such simple passwords, how is it that they are not getting hacked? It's actually a concern that IT managers i run into have when i tell them there is no strong password enforcement in vicidial and agents can't even be forced to change their own password.

The other thing is the guys who are trying to exploit SSL's heartbleed or phpMyAdmin or something like that are likely going to set-up a program to mine bitcoins or make your system part of a botnet or DDOS zombie. Most of the time the only way someone finds out this has happened is when all their bandwidth disappears and they don't know why or the server is overloaded with almost nothing going on. Most of the time the system will sit there quietly for weeks or months until this happens.

This is actually the only time one of our vicidial servers got hacked and indeed it was turned into some bitcoin mining machine, we had accidentally left the firewall open in this case. Don't know how they got in.

Now the guys sniffing around port 5060/4569/8088/8089 are the ones that will brute force you, cause asterisk to crash half a dozen times a day, and if they get in spend thousands of dollars (or however much is on your prepaid carrier account) in toll fraud. Financially and to a degree functionally they are easily an order of magnitude worse then your classic hack like above.

Our provider had daily limits so a hacker can never spend more then the daily amount we specify in our provider panel and they also alert us when there is a suspicious increase of traffic.

Just make sure you have working backups and it's a pretty simple fix.

We run all our vicidial servers virtualized now since about 4 months and soon we will have automated snapshots so it's just a matter of 5 seconds or restoring the machine to an earlier state.

[williamconley]

But agents and even supervisors often have such simple passwords, how is it that they are not getting hacked?

Vicidial is a small pond. This isn't wordpress or a generic login page on an "index.php" or "index.html". Knowing the login page (so it can be used in a script for automated brute force) requires knowledge of Vicidial itself.

Agents can not log in to the Admin system so their user/pass being easy will still fail UNLESS the login attempt is for the agent login page (also not an index page). And the agent login page has NO monetary or hacking usefulness unless they want to try sql insertion or similar. The agent interface, for instance, can not be used to register to a SIP or IAX account.

All-in-all much easier and more profitable to go after some other system than to try to hack into a Vicidial server's web access. SIP, on the other hand, can be converted to cash instantly.

[Kumba]

Plus the only thing the agents can do is modify lead info. They can't upload files or modify anything in the back end from their side. So your attack vector is much much smaller.

[Kumba]

iptables -L

Code: Select all

Chain INPUT (policy DROP)
target     prot opt source               destination
DROP       all  --  anywhere             anywhere             match-set geoblock src
DROP       all  --  anywhere             anywhere             match-set geoblock src
DROP       tcp  --  anywhere             anywhere             match-set voipblnet src tcp dpt:8089
DROP       udp  --  anywhere             anywhere             match-set voipblnet src udp dpt:iax
DROP       udp  --  anywhere             anywhere             match-set voipblnet src udp dpt:sip
DROP       tcp  --  anywhere             anywhere             match-set voipblip src tcp dpt:8089
DROP       udp  --  anywhere             anywhere             match-set voipblip src udp dpt:iax
DROP       udp  --  anywhere             anywhere             match-set voipblip src udp dpt:sip
DROP       tcp  --  anywhere             anywhere             match-set badnets src tcp dpt:8089
DROP       udp  --  anywhere             anywhere             match-set badnets src udp dpt:iax
DROP       udp  --  anywhere             anywhere             match-set badnets src udp dpt:sip
DROP       tcp  --  anywhere             anywhere             match-set badips src tcp dpt:8089
DROP       udp  --  anywhere             anywhere             match-set badips src udp dpt:iax
DROP       udp  --  anywhere             anywhere             match-set badips src udp dpt:sip
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere             ctstate ESTABLISHED
ACCEPT     icmp --  anywhere             anywhere             ctstate RELATED
ACCEPT     udp  --  anywhere             anywhere             udp dpt:mdns PKTTYPE = multicast
input_ext  all  --  anywhere             anywhere
LOG        all  --  anywhere             anywhere             limit: avg 3/min burst 5 LOG level warning tcp-options ip-options prefix "SFW2-IN-ILL-TARGET "
DROP       all  --  anywhere             anywhere

Chain FORWARD (policy DROP)
target     prot opt source               destination
LOG        all  --  anywhere             anywhere             limit: avg 3/min burst 5 LOG level warning tcp-options ip-options prefix "SFW2-FWD-ILL-ROUTING "

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere

Chain forward_ext (0 references)
target     prot opt source               destination

Chain input_ext (1 references)
target     prot opt source               destination
DROP       all  --  anywhere             anywhere             PKTTYPE = broadcast
ACCEPT     icmp --  anywhere             anywhere             icmp source-quench
ACCEPT     icmp --  anywhere             anywhere             icmp echo-request
ACCEPT     udp  --  anywhere             anywhere             udp dpt:sip match-set whitelistips src
ACCEPT     udp  --  anywhere             anywhere             udp dpt:iax match-set whitelistips src
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:8089 match-set whitelistips src
ACCEPT     udp  --  anywhere             anywhere             udp dpt:sip match-set whitelistnets src
ACCEPT     udp  --  anywhere             anywhere             udp dpt:iax match-set whitelistnets src
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:8089 match-set whitelistnets src
LOG        tcp  --  anywhere             anywhere             limit: avg 3/min burst 5 tcp dpt:8089 flags:FIN,SYN,RST,ACK/SYN LOG level warning tcp-options ip-options prefix "SFW2-INext-ACC-TCP "
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:8089
LOG        tcp  --  *****************************  anywhere             tcp dpt:http ctstate NEW limit: avg 3/min burst 5 LOG level warning tcp-options ip-options prefix "SFW2-INext-ACC "
ACCEPT     tcp  --  *****************************  anywhere             tcp dpt:http
LOG        tcp  --  *****************************  anywhere             tcp dpt:ssh ctstate NEW limit: avg 3/min burst 5 LOG level warning tcp-options ip-options prefix "SFW2-INext-ACC "
ACCEPT     tcp  --  *****************************  anywhere             tcp dpt:ssh
LOG        udp  --  *****************************  anywhere             udp dpt:sip ctstate NEW limit: avg 3/min burst 5 LOG level warning tcp-options ip-options prefix "SFW2-INext-ACC "
ACCEPT     udp  --  ***************************** anywhere             udp dpt:sip
LOG        udp  --  *****************************  anywhere             udp dpts:ndmp:dnp ctstate NEW limit: avg 3/min burst 5 LOG level warning tcp-options ip-options prefix "SFW2-INext-ACC "
ACCEPT     udp  --  *****************************  anywhere             udp dpts:ndmp:dnp
LOG        tcp  --  *****************************  anywhere             tcp dpt:https ctstate NEW limit: avg 3/min burst 5 LOG level warning tcp-options ip-options prefix "SFW2-INext-ACC "
ACCEPT     tcp  --  *****************************  anywhere             tcp dpt:https
LOG        tcp  --  *****************************  anywhere             tcp dpt:radan-http ctstate NEW limit: avg 3/min burst 5 LOG level warning tcp-options ip-options prefix "SFW2-INext-ACC "
ACCEPT     tcp  --  *****************************  anywhere             tcp dpt:radan-http
LOG        tcp  -- *****************************  anywhere             tcp dpt:8089 ctstate NEW limit: avg 3/min burst 5 LOG level warning tcp-options ip-options prefix "SFW2-INext-ACC "
ACCEPT     tcp  --  *****************************  anywhere             tcp dpt:8089
DROP       all  --  anywhere             anywhere             /* sfw2.insert.pos */ PKTTYPE != unicast
LOG        tcp  --  anywhere             anywhere             limit: avg 3/min burst 5 tcp flags:FIN,SYN,RST,ACK/SYN LOG level warning tcp-options ip-options prefix "SFW2-INext-DROP-DEFLT "
LOG        icmp --  anywhere             anywhere             limit: avg 3/min burst 5 LOG level warning tcp-options ip-options prefix "SFW2-INext-DROP-DEFLT "
LOG        udp  --  anywhere             anywhere             limit: avg 3/min burst 5 ctstate NEW LOG level warning tcp-options ip-options prefix "SFW2-INext-DROP-DEFLT "
DROP       all  --  anywhere             anywhere

Chain reject_func (0 references)
target     prot opt source               destination
REJECT     tcp  --  anywhere             anywhere             reject-with tcp-reset
REJECT     udp  --  anywhere             anywhere             reject-with icmp-port-unreachable
REJECT     all  --  anywhere             anywhere             reject-with icmp-proto-unreachable


ipset -L whitelistips

Code: Select all

Name: whitelistips
Type: hash:ip
Revision: 4
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 264
References: 3
Number of entries: 3
Members:
*****************************
127.0.0.1
*****************************


ipset -L whitelistnets

Code: Select all

Name: whitelistnets
Type: hash:ip
Revision: 4
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 120
References: 3
Number of entries: 0
Members:


I have started the firewall with these options:
/usr/local/bin/VB-firewall.pl --white --whitelist=ViciWhite

Also,i cannot open https://mydomain.com:/ws in my browser, i read in this thread that it should display some page: https://github.com/chornyitaras/PBXWebP ... figuration

The only IP being put into the WhiteList is 127.0.0.1. What IP's do you have listed in the ViciWhite IP List in ViciDial? Can you show me the output of VB-firewall.pl --debug --white ?

[Kumba]

Try commenting out lines 541 and 542 in /usr/local/bin/VB-firewall.pl. Just put a # in front of the print. It should look like this:

#print WHITETMP "create $IPWHITE iphash -exist\n"; # Make sure we create the ipset just in case
#print WHITENETTMP "create $IPWHITENET nethash -exist\n"; # Same as above but for networks

Then re-run 'VB-firewall.pl --white' and show me the output as well as 'ipset -L whitelistnets' and 'ipset -L whitelistips'

From when you posted the run a few posts up it seems to be erroring out on the -exist option, which it shouldn't since it's valid. If it ran correctly you should have 127.0.0.1 in whitelistips and the RFC1918 subnets in whitelistnets plus whatever you have added in the ViciWhite IP List.

[dspaan]

The only IP being put into the WhiteList is 127.0.0.1. What IP's do you have listed in the ViciWhite IP List in ViciDial? Can you show me the output of VB-firewall.pl --debug --white ?

I replaced the IP's with ********* because i don't want my own IP to be listed in the forum. I've sent you a PM.

I didn't comment out those lines yet in the .pl file, you still want me to do this?

[williamconley]

He wanted it both ways to compare. So ...: Yes.

[Kumba]

The only IP being put into the WhiteList is 127.0.0.1. What IP's do you have listed in the ViciWhite IP List in ViciDial? Can you show me the output of VB-firewall.pl --debug --white ?

I replaced the IP's with ********* because i don't want my own IP to be listed in the forum. I've sent you a PM.

I didn't comment out those lines yet in the .pl file, you still want me to do this?

So I saw the stuff in PM, and the only thing not loading is the RFC1918 IPs into the whitelistnets. It looks like you've removed the regular 80/443 rules and put in IP specific IP allow rules. I don't think this is causing an issue though. I'll have to see if I can duplicate this issue on the bench with a real external IP. In testing on my local VM it seems to work just fine.

[Kumba]

whitelistnets was being generated incorrectly. It was being generated as an iphash instead of a nethash. I corrected it and posted the fix for that in the bugfix thread. I don't believe this is the cause of your issue though.

[Kumba]

Fixed a few things and reworked some of the firewall configs. I'm building a new version to test it.

[dspaan]

Thanks Kumba, let me know if i need to test anything. Indeed i had ports 80 and 443 closed. By the way, most callcenters have a fixed IP so they don't need port 80 and 443 to be open for the outside world but they do have the occasional at home working employee or travelling manager. That's what we used Goodguys for. But with this new firewall as far as i understand these 80 and 443 ports are always open and the dynamic part opens the SIP and IAX2 ports once an agent logs in, is that correct?

So i was thinking of closing the web ports for the outside world and instead making apache listen on an additional (high) port for at home workers. Wouldn't that improve security and at the same time provide an easy login for out-of-the-office agents/managers?

[williamconley]

Any open port with Apache on it is not good, and only slightly better than port 80. Script kiddies scan ports and if they bump into apache on a port, they have scripts in place to begin the barrage and log your IP/port for future attacks by friends. DDOS and Brute force attacks require a login page to attack. Once they find one, you'll be in line for that attack. If you lock out each user's IP as they fail, they'll eventually just rotate IPs for their attack. At the very least, do not allow any "known login pages" for any "known web services". phpMyAdmin ... any index.php/index.html pages ... all are invitations to attack.

As Kumba said: Use a different server to take the initial request, and have that server send a signal on a local network to open the server's web port for that already authenticated user.

Or use a system which exposes NOTHING to the world aside from the existence of apache itself (eg: DGG). The scripts will hit it once in a while, but there are NO page responses except 404 errors. No login page = nothing to brute force. they gotta have that link to attack, and it takes 300 years to guess it.

IMHO.

[Kumba]

Thanks Kumba, let me know if i need to test anything. Indeed i had ports 80 and 443 closed. By the way, most callcenters have a fixed IP so they don't need port 80 and 443 to be open for the outside world but they do have the occasional at home working employee or travelling manager. That's what we used Goodguys for. But with this new firewall as far as i understand these 80 and 443 ports are always open and the dynamic part opens the SIP and IAX2 ports once an agent logs in, is that correct?

Yes, that's how VBF's version of dynamic works. I've also added a full control option in v.8.1.1 which will also open up port 80/443 as well. That way you can block everything unless they are on the whitelist or dynamic list. You would need to do a 'touch /etc/sysconfig/scripts/SuSEfirewall2-vicifull' to enable this functionality.

As far as your other firewall issue, I've tried this in various ways and I can't duplicate the outage. Maybe it was related to something I fixed as part of something else. Either way I'm going to release v.8.1.1 so you can re-test with that.

[dspaan]

Hey Kumba,

I installed vicibox 8.1.1 and didn't change anything in Yast. I connected my laptop to a VPN and did a portscan. Ports 22, 80 and 443 were open.

I did a 'touch /etc/sysconfig/scripts/SuSEfirewall2-vicidynamic'
I then ran the VB firewall like this:

Code: Select all

/usr/local/bin/VB-firewall.pl --dynamic
   ViciBox firewall integration

         Database Host :   localhost
         Database Name :   asterisk
         Database User :   cron
         Database Pass :   1234
         Database Port :   3306
            White list :   Disabled
          Dynamic list :   Enabled
     IPSet Dynamic Age :   14
    IPSet Dynamic List :   dynamiclist
            Black list :   Disabled
       VoIP Black List :   Disabled
        Geo Block list :   Disabled


  Generating Dynamic IP List rules...
    Looking for valid web logins within the last 14 days
    Writing IPSet rule file to /tmp//VB-DYNAMIC-tmp
    Loading dynamic list IPSet rules into kernel
  Dynamic List had been loaded!


Then i logged in as agent through my VPN laptop.
I did a portscan again but the same ports were still open, so port 5060 etc. were not opened. Where did i go wrong?

[Kumba]

I don't know. I think you have extra moving parts due to your VPN and everything else. You'd want to use TCP Dump, ipset -L, etc, to see if things are getting to the server and being allowed in.

[Kumba]

The problem is you weren't passing --dynamic to the VB-firewall.pl script in cron.

Here's how you would modify the cron to disable black/block lists and enable the white/dynamic lists:

Code: Select all

### ViciBox integrated firewall, by default just load the VoIP Black list and reload it every 4 hours
### You can lock everyone out of your server if you set this wrong, so understand what you are doing!!!
@reboot /usr/local/bin/VB-firewall.pl --voipbl --noblack --quiet
0 */6 * * * /usr/local/bin/VB-firewall.pl --voipbl --noblack --flush --quiet


change to :

Code: Select all

### ViciBox integrated firewall, by default just load the VoIP Black list and reload it every 4 hours
### You can lock everyone out of your server if you set this wrong, so understand what you are doing!!!
#@reboot /usr/local/bin/VB-firewall.pl --voipbl --noblack --quiet
#0 */6 * * * /usr/local/bin/VB-firewall.pl --voipbl --noblack --flush --quiet

### Process dynamic and white lists for VB Firewall, comment out the black/block list entries above this
### Enable iptables white list rules with : touch /etc/sysconfig/scripts/SuSEfirewall2-viciwhite
### Enable iptables dynamic list rules with : touch /etc/sysconfig/scripts/SuSEfirewall2-vicidynamic
### Enable iptables full control with : touch /etc/sysconfig/scripts/SuSEfirewall2-vicifull
* * * * * /usr/local/bin/VB-firewall.pl --dynamic --white --flush --quiet


I'll add that white/dynamic list part to the default dialer cron so it will be there for reference in the future.

The full control option is where everything is blocked unless on the white or dynamic list, not just SIP/IAX/RTC. You will need to update your white list manually or have some method of inserting validated IPs into the whitelist to use it. I've got a tie-in for a third party dynamic validation portal add-on but I haven't completed the portal yet. Once that's done it will have a simple install script for it. But that will give you essentially a cluster-friendly version of IP validation similar to what DGG does.

[dspaan]

Thanks, i can confirm it's working now.

I understand what the vicifull option does but not how it works, quote:

### Enable iptables full control with : touch /etc/sysconfig/scripts/SuSEfirewall2-vicifull

What exact crontab entry do i use for this?
Is the touch command a one time command for a new install?

[Kumba]

Thanks, i can confirm it's working now.

I understand what the vicifull option does but not how it works, quote:

### Enable iptables full control with : touch /etc/sysconfig/scripts/SuSEfirewall2-vicifull

What exact crontab entry do i use for this?
Is the touch command a one time command for a new install?

By default the ViciBox Firewall only controls access to SIP/IAX/RTC ports. With full control enabled access to the entire server is now determined by these things. So if you enable full control, and an IP is on the black list or VoIP BL, then that IP will be 100% blocked from contacting the server. Similarly if you are using white or dynamic lists then nothing on the server will be accessible unless that IP is added to the appropriate list.

So instead of partially controlling access, it fully controls access. As far as enabling it the answer is yes. You just do a 'touch /etc/sysconfig/scripts/SuSEfirewall2-vicifull' and it will enable it the next time the SuSEfirewall runs. You can manually load the new rules by doing SuSEfirewall2 after enabling it to load the new iptables rules.

[Kumba]

The default kernel printk settings result in iptables spewing crap all across the console. This turns out to be a nightmare on a busy system when you are on the console trying to do something. You can fix it like this:

echo "kernel.printk = 4 4 1 7" >> /etc/sysctl.conf

then reboot

[thephaseusa]

In Admin/IP Lists, if you want to use whitelist you must create a white list here, and does it have to be named ViciWhite? To use dynamic you dont have to create a list for it in Admin/IP list, it pulls from recent logins right?

So once you have your Admin/IP List/ViciWhite list ip’s entered and list activated, do the touch for vicidynamic and viciwhite and set your cron entry to run every minute for —dynamic —white —flush —quiet Then all IP’s you enter in the Admin/IP/ViciWhite list plus all recent (within last 2 weeks) successful logins IPS will be allowed past the firewall for ports 80, 443, 5060, and 8089 correct?

And I understood that if you have all that set up, then do a touch vicifull then all IP’s except those on white or dynamic are dropped on all ports coming in.

Of course your warning was well founded about locking yourself out))) i ran the touch vicifull and I couldn’t log in as agent from anywhere, and my cluster boxes couldnt get to the mysql box. I had all cluster box IPs entered in the whitelist. I just went back to dynamic and white.

Thinking about it though, if vicidynamic and viciwhite control entry to ports 80,443 for web and 5060 for asterisk and 8089 for WSS, and I don’t open any other ports in SuSEfirewall2 then incoming attempts to any other port will be dropped by the firewall anyway right?

So, under what conditions would one want to use vicifull, or need to use vicifull?

William is right this new firewall is a good one. With the portal Kumba made, you could assign a new work from home agent a user/pass, give them the portal web login, let them log in from there, wait a minute, then go to another Access page log in and they pass through to the relogin page with their user/pass phone/pass filled in, choose a campaign, click login, then click Call Webphone, they hear the woman’s voice, unpause and they’re dialing.

[Kumba]

You are almost correct on everything. By default the VBF only controls SIP/IAX/RTC ports, which is 5060/4569/8089. Adding ViciFull makes it also control HTTP/HTTPS at 80/443. By default the only things allowed through the firewall when the NIC is assigned to the External zone and VBF isn't running is SSH 22 tcp, SIP 5060 udp, IAX 4569 udp, RTC 8089 tcp, HTTP 80 tcp, and HTTPS 443 tcp. Everything else is blocked. With the vicifull option the only port you'll see is SSH at port 22 unless you have manually changed that yourself. With just white or dynamic you'll also see the HTTP and HTTPS port.

Also I'm not sure why you got locked out when you enabled vicifull. The vicifull shouldn't have had an impact on things talking to the database but like I mentioned networks get really complex really quickly so it's hard to say why access was cut off. I'm guessing that somehow the zones that were assigned to your NIC's got changed to external. In these scenarios you'd need to add a custom rule in yast firewall to allow the other servers in the cluster to talk to the database. VBF doesn't do anything regarding mysql connections on TCP port 3306.

[dspaan]

The problem is you weren't passing --dynamic to the VB-firewall.pl script in cron.

Here's how you would modify the cron to disable black/block lists and enable the white/dynamic lists:

Code: Select all

### ViciBox integrated firewall, by default just load the VoIP Black list and reload it every 4 hours
### You can lock everyone out of your server if you set this wrong, so understand what you are doing!!!
@reboot /usr/local/bin/VB-firewall.pl --voipbl --noblack --quiet
0 */6 * * * /usr/local/bin/VB-firewall.pl --voipbl --noblack --flush --quiet


change to :

Code: Select all

### ViciBox integrated firewall, by default just load the VoIP Black list and reload it every 4 hours
### You can lock everyone out of your server if you set this wrong, so understand what you are doing!!!
#@reboot /usr/local/bin/VB-firewall.pl --voipbl --noblack --quiet
#0 */6 * * * /usr/local/bin/VB-firewall.pl --voipbl --noblack --flush --quiet

### Process dynamic and white lists for VB Firewall, comment out the black/block list entries above this
### Enable iptables white list rules with : touch /etc/sysconfig/scripts/SuSEfirewall2-viciwhite
### Enable iptables dynamic list rules with : touch /etc/sysconfig/scripts/SuSEfirewall2-vicidynamic
### Enable iptables full control with : touch /etc/sysconfig/scripts/SuSEfirewall2-vicifull
* * * * * /usr/local/bin/VB-firewall.pl --dynamic --white --flush --quiet


I'll add that white/dynamic list part to the default dialer cron so it will be there for reference in the future.

The full control option is where everything is blocked unless on the white or dynamic list, not just SIP/IAX/RTC. You will need to update your white list manually or have some method of inserting validated IPs into the whitelist to use it. I've got a tie-in for a third party dynamic validation portal add-on but I haven't completed the portal yet. Once that's done it will have a simple install script for it. But that will give you essentially a cluster-friendly version of IP validation similar to what DGG does.

Hi Kumba, i installed a new server with Vicibox V8.1.2 and ran the three commands (touch viciwhite, vicidynamic and vicifull) and applied above suggested cronjob but when i do a portscan ports 80 and 443 are still open for an IP that's not on the whitelist. What could have gone wrong?

Manual command output:

/usr/local/bin/VB-firewall.pl --dynamic --white
ViciBox firewall integration

Database Host : localhost
Database Name : asterisk
Database User : cron
Database Pass : 1234
Database Port : 3306
White list : Enabled
Vici White List : ViciWhite
IPSet White List IPs : whitelistips
IPSet White List Nets : whitelistnets
RFC1918 White List : YES
Dynamic list : Enabled
IPSet Dynamic Age : 14
IPSet Dynamic List : dynamiclist
Black list : Disabled
VoIP Black List : Disabled
Geo Block list : Disabled


Generating White List from IP List 'ViciWhite'...
Found 1 entires to process
Adding RFC1918 IPs to white lists
Writing IPSet rule files to /tmp//VB-WHITE-tmp and /tmp//VB-WHITENET-tmp
Loading white list IPSet rules into Kernel
White List had been loaded!

Generating Dynamic IP List rules...
Looking for valid web logins within the last 14 days
Writing IPSet rule file to /tmp//VB-DYNAMIC-tmp
Loading dynamic list IPSet rules into kernel
Dynamic List had been loaded!

In crontab i have:

### ViciBox integrated firewall, by default just load the VoIP Black list and reload it every 4 hours
### You can lock everyone out of your server if you set this wrong, so understand what you are doing!!!
#@reboot /usr/local/bin/VB-firewall.pl --voipbl --noblack --quiet
#0 */6 * * * /usr/local/bin/VB-firewall.pl --voipbl --noblack --flush --quiet

### Process dynamic and white lists for VB Firewall, comment out the black/block list entries above this
### Enable iptables white list rules with : touch /etc/sysconfig/scripts/SuSEfirewall2-viciwhite
### Enable iptables dynamic list rules with : touch /etc/sysconfig/scripts/SuSEfirewall2-vicidynamic
### Enable iptables full control with : touch /etc/sysconfig/scripts/SuSEfirewall2-vicifull
* * * * * /usr/local/bin/VB-firewall.pl --dynamic --white --flush --quiet

In /var/mail/root i see:

Subject: Cron <root@template2> /usr/local/bin/VB-firewall.pl --dynamic --white --flush --quiet

sh: iptables: command not found
sh: iptables: command not found

Question1: Why not include port 22 as well in the vicifull option?
Question 2: When using vicifull will certbot still be able to renew SSL certificates?

edit: By closing off the http and https allowed services in yast firewall i noticed i can still access the webserver through my IP that is in the whitelist so it seems to be working now only i wasn't aware that i had to do this. Is this the correct procedure?

[Kumba]

SSH (port 22) should be secured by the admin. There's too many methodologies behind how you could login to your linux server to really make it worth controlling. So the VBF focuses primarily on controlling access to the ports/services that directly let you use ViciDial. This means SIP/IAX/RTC for the phone portion and HTTP/HTTPS for the web interface.

Besides, you wouldn't want something that allows public access to hundreds or thousands of people to also give those same people SSH access when maybe 6 people in the whole organization need it. And on the flip side, you wouldn't want your SSH access to disappear cause someone messed up a blacklist or whitelist entry or because something prevented the VBF from running correctly.

With ViciFull, you will need to do some research to see if CertBot has specific IP's that is uses for authenticate against the web server with. If it does then you can add those to the whitelist.

And doing the touch commands should have made the VBF remove the http/https but yes, those entries along with the SIP/IAX/RTC ports should have been removed from yast firewall

[dspaan]

You are absolutely right about the SSH port and in hindsight i understand why it wasn't included in vicifull.

From experience i know that there are no fixed IP ranges that Let's Ecrypt uses and in the past we used a script that opens up the ports temporarily when the cronjob runs. So i guess we'll use that.

I just re-installed the same server because of an asterisk issue and als did the steps for the firewall again. I can confirm that doing the touch commands does NOT remove the allowed services in yast firewall. So for some reason that's not working.

I keep getting this:

You have new mail in /var/mail/root

And in root mail file i keep seeing this:

Subject: Cron <root@template2> /usr/local/bin/VB-firewall.pl --dynamic --white --flush --quiet

sh: iptables: command not found
sh: iptables: command not found

[williamconley]

you will need to do some research to see if CertBot has specific IP's that is uses for authenticate against the web server with

My last foray into this resulted in the concept that not only do they NOT have a specific IP range or set of ranges, if they did they would not release it. The use of SSL for a website is PUBLIC, so it must be open to all or they won't certify it. Thus we settled on "open, certify, close" when renewing.

[alexgrad]

I think the best way is to open 80/443 to the public, but move agc, vicidial and phpMyAdmin to SSL VirtualHost *:8443 which is closed to public.
The dynamic portal and chat_customer is set on 80/443.

[williamconley]

I think the best way is to open 80/443 to the public, but move agc, vicidial and phpMyAdmin to SSL VirtualHost *:8443 which is closed to public.
The dynamic portal and chat_customer is set on 80/443.

I hope you meant temporarily. Cuz opening 80/443 to the public is an open invitation to an attack and further probing. This has a cumulative effect as more and more script-kiddies notice your existence (and rat you out to friends). But if you open those ports, run the renewal script, and close those ports, they need only be opened for a few seconds (literally) in the middle of the night. Then you leave NO normal ports open to the public. Script kiddies, as a rule, will leave you alone.

[alexgrad]

I think the best way is to open 80/443 to the public, but move agc, vicidial and phpMyAdmin to SSL VirtualHost *:8443 which is closed to public.
The dynamic portal and chat_customer is set on 80/443.

I hope you meant temporarily. Cuz opening 80/443 to the public is an open invitation to an attack and further probing. This has a cumulative effect as more and more script-kiddies notice your existence (and rat you out to friends). But if you open those ports, run the renewal script, and close those ports, they need only be opened for a few seconds (literally) in the middle of the night. Then you leave NO normal ports open to the public. Script kiddies, as a rule, will leave you alone.

As the port for the dynamic portal has to be always opened what's the difference to open it on 80/443 or other ports?