Strange FirewallD issue I'm working through

[Kumba]

Any FirewallD/IPTables experts handy? Trying to figure out one lingering issue for ViciBox v.9.0.0.

Basically the last piece is getting the ViciBox Firewall part working correctly. The part that isn't working is the blacklist. By default SIP and HTTP are open on the firewall. If an entry is inserted into the voipblips or voipblnets ipsets it should block that ip. This is how ViciBox v.8.1 works.

However in ViciBox v.9.0 they've moved to firewalld instead of using SuSEfirewall. The problem is I can't get the blacklist to work properly. The dynamic and whitelist work appropriately but no blacklist. The down side is I can't figure out why.

So here's the INPUT table:

Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere
INPUT_direct all -- anywhere anywhere
INPUT_ZONES_SOURCE all -- anywhere anywhere
INPUT_ZONES all -- anywhere anywhere
DROP all -- anywhere anywhere ctstate INVALID
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited

Table Breakdown:
1) So this should accept all connections that are established (TCP thing, we're worried about SIP UDP traffic here) and new connections
2) Pass through the INPUT_direct table
3) Pass through the INPUT_ZONES_SOURCE table
4) Pass through the INPUT_ZONES table
5) Drop anything with an invalid/mismatched state
6) Reject everything else cause they shouldn't be here (catch-all)


The INPUT_direct table is empty as well as the INPUT_ZONES_SOURCE table, so those will effectively do nothing to any traffic.


Chain INPUT_ZONES (1 references)
target prot opt source destination
IN_public all -- anywhere anywhere [goto]
IN_public all -- anywhere anywhere [goto]

Everything is sent to the IN_public table, which is the 'public' firewall zone and holds those rules.


Chain IN_public (2 references)
target prot opt source destination
IN_public_log all -- anywhere anywhere
IN_public_deny all -- anywhere anywhere
IN_public_allow all -- anywhere anywhere
ACCEPT icmp -- anywhere anywhere

At this point, the traffic is passed through three public zone tables.
1) Any matching rules in IN_public_log generates log entries for systemd
2) Any matching rules in IN_public_deny should reject/drop/etc the matched traffic
3) Any matching rules in IN_public_allow should accept the traffic, and send it out on the network


The table IN_public_log is empty, so that does nothing.
Chain IN_public_deny (1 references)
target prot opt source destination
DROP udp -- anywhere anywhere match-set blackips src udp dpt:sip ctstate NEW
DROP udp -- anywhere anywhere match-set blackips src udp dpt:iax ctstate NEW
DROP tcp -- anywhere anywhere match-set blackips src tcp dpt:8089 ctstate NEW

1) If packet is UDP, the source IP matches any IPs in the blackips IPSet, the destination port is 5060 (SIP), and the connection state is new (all UDP is new), then drop
2) Same thing, but with udp port 4569 (IAX)
3) Same thing, but with tcp port 8089 (WebRTC)


Chain IN_public_allow (1 references)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh ctstate NEW
ACCEPT udp -- anywhere anywhere udp dpt:sip ctstate NEW
ACCEPT udp -- anywhere anywhere udp dpt:iax ctstate NEW
ACCEPT udp -- anywhere anywhere match-set whiteips src udp dpt:sip ctstate NEW
ACCEPT udp -- anywhere anywhere match-set whiteips src udp dpt:iax ctstate NEW
ACCEPT tcp -- anywhere anywhere match-set whiteips src tcp dpt:8089 ctstate NEW


1) If packet is TCP, destination port is 22 (SSH), and connection state is new, accept the connection
2) Same thing, UDP port 5060 (SIP)
3) Same thing, UDP port 4569 (IAX)
4) If packet is UDP, source matches IPSet whiteips, Destination port is 5060 (SIP), accept the connection
5) Same, but destination port is 4569 (IAX)
6) Same, but packet is TCP and port if 8089 (WebRTC)


The contents of the blackips ipset is:

vicibox9:~ # ipset -L blackips
Name: blackips
Type: hash:ip
Revision: 4
Header: family inet hashsize 1024 maxelem 262144
Size in memory: 136
References: 3
Number of entries: 1
Members:
192.168.198.146


So now for the actual problem. The IN_public_deny table is ran before IN_public_allow, which should be matching and dropping the traffic from my soft-phone when it tries to register. It's almost like the IP_public_deny table isn't being parsed at all and the traffic is just being flowed into IN_public_allow instead. The packet counts for IN_public_deny do not increment but that could be because the rules didn't match. I'm not 100% sure that's how the IPTables counters work.

Just to make sure I'm not crazy, I removed the general allow-all access rule from the IN_public_allow table so I could test the almost identical whitelist rule. The whitelist rules with IPSet work perfectly within the IN_public_allow table so I have verified that it's at least not the general rule syntax.

So I'm really somewhat at a loss here. At one point I thought maybe the the tables are evaluating in descending/backwards order, but then nothing would ever get out of the INPUT table. So the flow is definitely in ascending order.

So the packets flow through the tables in this order, or should:

INPUT --> INPUT_ZONES --> INPUT_public --> INPUT_public_deny (here's where blackips IPSet should match) --> INPUT_public_allow (the IP in blackips should never get to this table, but it is.).


Here's the IPTables commands that firewalld generates to set-up the IN_public table and the IN_public_deny table:
-A IN_public -j IN_public_log
-A IN_public -j IN_public_deny
-A IN_public -j IN_public_allow
-A IN_public -p icmp -j ACCEPT
-A IN_public_deny -p udp -m set --match-set blackips src -m udp --dport 5060 -m conntrack --ctstate NEW -j DROP
-A IN_public_deny -p udp -m set --match-set blackips src -m udp --dport 4569 -m conntrack --ctstate NEW -j DROP
-A IN_public_deny -p tcp -m set --match-set blackips src -m tcp --dport 8089 -m conntrack --ctstate NEW -j DROP


And there is what is holding ViciBox v.9.0 back from release at this point. The integrated blacklisting isn't working and I have no clue why. If there's any firewalld or IPTables experts out there, feel free to chime in. I'll probably make a beta version of ViciBox available in a bit so you can download and test if you want.

[williamconley]

are your tables full? i've recently gotten some messages about that on 8.X in a few systems using the vBox firewall setup. Only visible in the actual console, not a remote. Not sure what command you'd use to check, as we don't use the tables we still use the recent module and chains.

otherwise, i'd have to see it as "iptables-save" output, I never try to read the "pretty version" or general descriptions as there is always a misunderstanding ... but iptables-save never lies. lol

or direct access to a sample machine.

this is something they still let me troubleshoot from time to time.

[Kumba]

The iptables commands I posted came from iptables-save. I verified the table setup from that as well.

The full issue you are likely talking about is the IPSet. I didn't specify the max elements in the original version, so it capped out at 65K entries.

This setup was testing with just a single IP in an IPSet table. Still no go.



Here's a link to the current ViciBox v.9.0 Beta that i'm testing against: http://download.vicidial.com/vicibox/se ... 0-beta.iso

Might be a good idea to make sure it installs on your various pieces of test hardware as well.

[williamconley]

The iptables commands I posted came from iptables-save.

we use iptables-save with NO arguments. just iptables-save, which doesn't interpret or simplify or modify anything. it merely dumps the firewall in a format that can be used with iptables-restore. In other words: That's the actual firewall. In code.

I'll have someone vSphere the new .iso and see if we can find the flaw.

[williamconley]

preliminary tests:

working:

Code: Select all

ipset add blackips xx.xx.xx.xx
iptables -I IN_public_deny 1 -m set --match-set blackips src -j DROP


failing:

Code: Select all

firewall-cmd --permanent --ipset=blackips --add-entry=xx.xx.xx.xx

Notes:

Even though the "--add-entry" command result in "success" and reports the IP in the IPSET:

Code: Select all

firewall-cmd --permanent --ipset=blackips --get-entries

The ipset fails to block when the IP is added this way. But it DOES block when using "ipset add blackips"

We may have more time to play with it tomorrow.

Other notes:

* INPUT_direct is "sent to" and declared but never populated. (along with a few other chains)

Pointless log attempt:

Code: Select all

firewall-cmd --set-log-denied=all

Resulting log:

Code: Select all

2019-07-10 22:42:39 ERROR: UNKNOWN_INTERFACE: 'eth0' is not in any zone

But if you put eth0 in a zone ... that bypasses the firewall in favor of a newly created pathway. Counterproductive.

However, this:

Code: Select all

journalctl --no-pager | grep 'DPT=80'

Along with a few of these (one at the top of each zone):

Code: Select all

iptables -I IN_public_deny 1 -j LOG --log-prefix "IN_public_deny 1 " --log-tcp-options --log-ip-options

Help with tracing to be sure we're all in the right place.

[Kumba]

And figured out. No clue why it's not executing in the proper context, but I managed to get the rules forced into place through some direct rule contexts.