IDH firewall issues? Can't reach honeypot services at all

[kingtriumph]

SO version: 2.3.182
Distributed setup

Hello. I'm trying to get a SO IDH node working on a Hyper-V VM. The VM is configured with two network interfaces - one for the connection to the manager node and the other should be what the honeypot services are listening on.

During the installation, the SO installer did not see both network interfaces. I had to change the ONBOOT variable in the second (non-manager) network interface after installation to get the second network interface up and connected. Also during installation, I configured the IDH node to not listen for honeypot connections on the network interface connected to the manager.

iptables appear correct. The connection to the manager node is blocked for the specific honeypot services that should be running. All other connections are allowed to the honeypot services. The http.default.yaml file also appears to just listen on port 80 without specifying a specific interface binding.

Currently, I cannot get the honeypot services to respond at all on the IP associated with the second network interface, which is where I want it to respond. I do not receive IDH alerts in the SOC Alerts pane.

The documentation states that updates to the IDH node can be made via edits to the IDH minion .sls file. Looking at my IDH minion .sls file, I see the following:

host:
  mainint: 'eth0'
sensoroni:
  node_address: '###.###.###.###'

(where the IP after 'node_address' is for the management interface)

Can or should I update the minion file to include the second network interface where the honeypot services should be listening? If so, what is the correct syntax to do so? I've searched through the Salt documentation, but haven't found anything that stands out as helpful in this situation.

Thanks for the assistance.

EDIT 1: The so-idh docker container on the IDH node appears to be empty except for a handful of hidden files. Is this normal?

EDIT 2: I have now removed the original IDH node from my Security Onion instance and re-installed the IDH from scratch. This time the installer recognized both network interfaces, but I still had to change the ONBOOT variable in the ifcfg-eth1 config file after the install in order for the second network interface to connect.

Everything looks the same as before I wiped and re-installed the IDH node. iptables look the same and seemingly allow connections to the honeypot services on any interface other than the management interface. The so-idh docker container has almost nothing in it besides a handful of hidden files. I still cannot reach any of the honeypot services on the second network interface.

I do not want to set up the honeypot to use the management interface and I don't have spare hardware for the IDH node. It's gotta be a VM at this point. Any help or suggestions are appreciated.

EDIT 3: nmap shows all ports filtered on the second network interface for the IDH node. This is true whether or not firewalld is running or disabled (see below for more confusion about firewalld and iptables on the IDH node). I have verified that my router ACLs allow the expected connections to the IDH node from the subnets I am using to test the honeypot services.

I've looked through the various firewall yaml config files on the manager node (hostgroups.yaml, assigned_hostrgroups.map.yaml, etc) and noted that the IDH rules are different in how they're applied than the other nodes (it's logic based it would seem), but this in turn makes it more difficult for me to figure out where and how I need to make changes to the IDH node firewall. Do I need to make changes to the IDH firewall using so-firewall to create port and host groups and then apply them to the IDH pillar minion like other nodes?

The documentation for the IDH node says you can run iptables commands from the IDH node itself to make firewall changes on the IDH ndoe. I have experimented with this and have successfully added new allows to the INPUT chain, but it makes no difference in my ability to reach the honeypot services and trigger alerts. The other confusing aspect is that the IDH node says that iptables is not running or even installed, instead firewalld is. However, there appear to be no rules in firewalld.

[defensivedepth]

Are you using the ISO or Network install? Is this Centos or Ubuntu?

---

The [documentation for the IDH node](https://docs.securityonion.net/en/2.3/idh.html#idh) says you can run iptables commands from the IDH node itself to make firewall changes on the IDH ndoe.

You should not be manually editing firewall files or running iptables commands except for the one specific situation that the linked documentation makes note of: If you changed the default port of an IDH service, it needs to be manually closed. Other than that, as the docs state, use the default & minion sls file to customize ports, services etc.

[kingtriumph]

Hi there and thank you for the response.

I installed the IDH using the Security Onion ISO, thus the underlying OS is Centos 7 I believe.

Are firewall rule updates then done the same as other minions? It looks as though the IDH has some special logic to how it applies the rules based on what I see in the assigned_hostgroups.map.yaml file.

Am I barking up the wrong tree entirely by looking at the iptables rules on the IDH node? Those rules would seem to allow connections from any to any for the honeypot services except for the interface that communicates with the manager node.

Here is a sanitized version of my idh minion .sls file:

host:
  mainint: 'eth0'
sensoroni:
  node_address: '10.10.10.10'
  node_description: 'Security Onion IDH'

ntp:
  servers:
    - 'ntp1.domain'
    - 'ntp2.domain'
    - 'ntp3.domain'
patch:
  os:
    source: 'manager'
    schedule_name: 'manual'
    enabled: True
    splay: 300

idh:
  restrict_management_ip: True
  services:
    - http
    - ftp
    - ssh

[kingtriumph]

Ok, well I've successfully updated the IDH firewall via the pillar minion file. I can see the changes reflected in the iptables output. However, the IDH services are still inaccessible on the second network interface.

I've added explicit router ACL allows to the second IDH network interface for the required ports for testing purposes, even though they should not be needed. This also has not helped.

Unless I'm missing something else about the SO firewall rules, it would seem that the IDH services are not being published on the second network interface. At this point I don't know what else would be causing it not to work, although I am open to any suggestions.

[defensivedepth]

There should not be a need to do any of that.... The IDH docker container binds to every interface on the system, and by default, the firewall rules allow all connections inbound to all IPs on all interfaces to the IDH ports, unless block management IP is selected (in which case it blocks inbound connections to the IDH ports on the management interface only).

Setup not seeing the interface initially means there may be some virtual hardware issue you are running into.

If you login directly to the IDH node, can you curl the non-Managment IP? This is what it should look like:

[kingtriumph]

Thank you for all your assistance. The issue appears to have been a routing issue on the IDH. It was weighting the management interface higher than the secondary interface, so all responses were trying to exit the incorrect interface. I added a static route to the IDH that routes traffic through the second network interface's gateway for the subnet I am testing from. I am now able to pull up the IDH webpage and ssh interface.

Thank you again. Your help is very much appreciated.

[defensivedepth]

No problem, glad you got it figured out!