FOOD FOR THOUGHT Public vs Non Public

[billsimon]

Watching another thread I see confusion about "public" vs "non-public" configurations of IncrediblePBX. It made me wonder why two versions are needed. Wouldn't the security scheme for the public version work fine in all scenarios?

 

[krzykat]

I think the public version relies upon FQDN. Unless someone has the knowledge with routers to set that up, that may make it harder for some to use.

 

[tbrummell]

That is correct, PUBLIC uses FQDN to allow SIP through iptables, and drops anything SIP referenced by IP. Non-public basically blocks all SIP and only allows what you enter in IPtables. Non-public is fine for anyone on static IP(s), but as soon as you want a mobile client, it's pretty much useless, and that's where PUBLIC comes in.

 

[roundaway]

That is correct, PUBLIC uses FQDN to allow SIP through iptables, and drops anything SIP referenced by IP. Non-public basically blocks all SIP and only allows what you enter in IPtables. Non-public is fine for anyone on static IP(s), but as soon as you want a mobile client, it's pretty much useless, and that's where PUBLIC comes in.

Public = if you're behind a double NAT (carrier grade NAT).

 

[krzykat]

Public = if you're behind a double NAT (carrier grade NAT).

?? Not really - typically you've got a public IP assigned - with it having a FQDN to allow access through firewall as @tbrummell explained.

 

[billsimon]

I think the public version relies upon FQDN. Unless someone has the knowledge with routers to set that up, that may make it harder for some to use.

Just brainstorming (or brainfarting) here... if the rules were to allow traffic directed to FQDN or traffic from known local subnets, would that cover everything?

 

[tbrummell]

That's how mine is set up. IPtables drops IP referenced SIP, allows FQDN and my "local" subnet (which is routed via OpenVPN). I still need to use FQDN's on the local subnet, so my local DNS server has an entry to point the clients across the VPN link. And of course, my real world DNS points to the public IP on Vultr.

 

[jerrm]

if the rules were to allow traffic directed to FQDN or traffic from known local subnets

The requirement for a specific FQDN is enforced by asterisk.

In iptables, PUBLIC opens up the SIP ports to the world. The iptables rules never references the FQDN. What iptables does do is block any packet that contains the server's public IP in clear text. The public IP string match rule is after the state rule(s), so shouldn't have any impact on TCP or established UDP connections.

Additionally for iptables, the PUBLIC setup blocks common SIP scanners, adds voipbl blacklisting, adds geoip country blocking for some worst offenders, adds connection limiting and adds fail2ban. Probably a couple other tweaks I'm forgetting.

 

[billsimon]

The requirement for a specific FQDN is enforced by asterisk.

I must be getting my methodologies mixed up. I thought iptables was allowing initial SIP requests (REGISTER, INVITE) that contained the FQDN. I will look into it more closely.

 

[tbrummell]

Well, essentially it's what @jerrm said. It doesn't specifically allow your FQDN, it allows *any* FQDN to pass (or not get filtered is the better term) and expects Asterisk to only allow the true FQDN to register/invite/etc via the domain= directive.
This drops the geoip's:

 1394 83226 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set cn src
   37  1992 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set ru src
    2   104 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set ps src
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set kp src
    6   304 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set ua src
    1   220 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set md src
  209 12726 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set nl src
  120  8005 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set fr src

This drops the IP referenced packets:

    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            STRING match  "68.232.xxx.xxx" ALGO name bm TO 65535

If an attacker *knew* an Asterisk server was at the IP, they could set up their own DNS (or use a damn hosts file for that matter) and send the Register to that FQDN, which then Asterisk would drop because of the domain, and F2B would then put them on time-out.

 

[wardmundy]

There's a third approach under development that is similar to what Rob developed for FreePBX. The current release unfortunately requires a commercial module, but it's GPL code so... stay tuned.

 

[jerrm]

The current release unfortunately requires a commercial module

It's not difficult to remove sysadmin from the firewall module. The only issue is how to do it "securely."

I would argue it doesn't matter much. The zend/signature/hook structure can make claims about security, but as long as the (most likely to be compromised) asterisk user can simply disable and/or change any firewall setting it's mostly just lip service.

 

[jerrm]

I thought iptables was allowing initial SIP requests (REGISTER, INVITE) that contained the FQDN. I will look into it more closely.

Pretty sure Ward's early iterations had an fqdn string match in iptables, but it's been a while and I may be mistaken.

For clear SIP, I build iptables chains to match on a valid "[email protected]" and allowed user agents. Basically nothing unwanted makes it to asterisk with those limitations.

 

[Brianmac]

Can you switch a non-public to public server?

 

[krzykat]

Can you switch a non-public to public server?

YES - Compliments of Nerd Vittles