How to create Netfilter IPTables script for UniFi Dream Machine / Secure Gateway?

EnthusiastXYZ

Limp Gawd
Joined
Jun 26, 2020
Messages
221
UDM is not as flexible as USG when it comes to preserving changes made via SSH. There is no config.json file and SSH-set Netfilter IPTables rules reset after router reboots. To get the same flexibility, I need to follow this guide, but I don't know SSH/Linux/Debian enough to figure it out Step 3 ["Copy any shell scripts you want to run to /mnt/data/on_boot.d on your UDM (not the unifi-os shell) and make sure they are executable and have the correct shebang (#!/bin/sh)] . On Raspberry Pi, I use Persistent IPTables and save them via ["sudo bash -c "iptables-save >/etc/iptables/rules.v4"] , but rules.v4 only lists IPTables rules, it isn't in SH script format. I don't know how to write SH scripts...

How do I convert my "rules.v4" into SH script format? How to make them executable and assign to them correct shebang? Once my rules are converted and copied to "/mnt/data/on_boot.d", do I need to do anything else?
 
Last edited:
Would it be okay if you cheat around it and launch iptables-restore somewhere along the line?
 
You mean executing an IPTables-restoring command after each reboot? The only difference between that and what I am doing already would be executing one command VS copying & pasting all my custom IPTables after each reboot, which is done with 3 mouse clicks. Automation would allow me to not bother enabling SSH, entering SSH, executing anything after each reboot, then exiting SSH, and disabling SSH.
 
You mean executing an IPTables-restoring command after each reboot? The only difference between that and what I am doing already would be executing one command VS copying & pasting all my custom IPTables after each reboot, which is done with 3 mouse clicks. Automation would allow me to not bother enabling SSH, entering SSH, executing anything after each reboot, then exiting SSH, and disabling SSH.

Yes, executing it after a reboot, but have the device itself call this command on its own during startup, with the rules file on the device.

I was thinking place the rules file where they say scripts should reside (/mnt/data/on_boot.d), with the only additional scripting which should be required like so:

Code:
#!/bin/sh
iptables-restore /mnt/data/on_boot.d/your_rules_file

Mind you, I don't know this device and am mostly going by the how-to you mentioned and general experience with iptables.
The rules file itself, which is created by iptables, can be manually made into a shell script and I might help you with that if the above trick doesn't work.
 
Multiple other sources confirm that simply placing an SH-format file with listed IPTables rules (and "#!/bin/sh" as the top line) into on_boot.d directory should do the trick once I allow the file to be executed by anyone. There should be no need to execute any commands after reboot. I am going to test that and report back. I think many people are interested in running custom scripts on UDM, but not many know about UDM-utilities.
 
Multiple other sources confirm that simply placing an SH-format file with listed IPTables rules (and "#!/bin/sh" as the top line) into on_boot.d directory should do the trick once I allow the file to be executed by anyone. There should be no need to execute any commands after reboot. I am going to test that and report back. I think many people are interested in running custom scripts on UDM, but not many know about UDM-utilities.
In order to make it executable by anyone, you'd want to do:
Code:
chmod 755 some_script.sh
It will equate to read/write/execute by root and read/execute by others.

Now, about the SH file, aside from the #!/bin/sh shebang at the top, quite honestly there is no 'format'.
Whatever you can call during a normal ssh session, you can also place in a shell script.
I hope this helps, but feel free to elaborate if I'm missing the point.
 
Yey! Works! Now I just need to find out all possible CLI commands for UDM because the ones for Ubiquiti Edge routers and USG do not work. UDM is limited when it comes to SSH due to being more on the consumer side than on pro/enterprise side.

I assume I can add other functional CLI commands to that script (set service ubnt-discover disable, set service ubnt-discover-server disable) ?
 
Good to hear.
Well, it's actually possible that the commands you'd like to have are there, but their location is not added to the $PATH environment variable, which tells the shell (you are in a shell whenever you SSH) where to look for stuff.
IIRC you can use, for example,
Code:
whereis some_command
or
Code:
locate some_command

If the commands you need are indeed found, say, in the /usr/bin/ directory, you can invoke those commands through what's called an absolute path:
Code:
/usr/bin/ping someaddress

About the last bit regarding other commands - probably so, but before you try, at least check which shell is actually there by default.
Beware - You might bump into an issue on startup whereupon your startup script will stall and possibly hang there due to some fault condition (such as - wrong order of activating stuff, waiting for input...)

Whatever can't be launched during startup can always be launched a bit later on via crontab task scheduling, but that's another story.
 
Custom IPTables rules I made patched the bug that made UDM perform Device Discovery over both LAN and WAN via UDP port 10001, IP 255.255.255.255 and IP 239.X.X.X. It used to be a major security flaw that was supposedly fixed years ago, but re-appeared with later Network Controller updates. Using Web GUI to block those IP addresses and UDP port 10001 had no effect. Custom IPTables did stop that broadcast, but upon reboot the discovery broadcast re-appeared for a few seconds and then stopped once my IPTables script was executed.

These broadcasts contained some sensitive information that was sent from router's local LAN IP to router's public WAN IP. Where was that information actually sent? The ISP? The router itself? Maybe sending a package from router LAN IP to router WAN IP was an internal network transmission?
 
Sorry, I'm not qualified about networking that happens beyond the router.

I'm guessing - first guy to see your traffic is the ISP and they might have simply blocked traffic meant for broadcast or even other typical signatures of malicious activity.

Regarding LAN IP -> Router WAN IP traffic - do a tracert to your WAN-facing IP to check. In my case it's instant, one hop with nothing in between.
 
So far the only other thing I want to turn off is LLDP advertisement and I can't figure out how to do it. I know Ubiquiti uses a lot from OpenWRT, but I can't find a command that disables LLDP daemon or service.
 
What are the negative consequences of my router advertising LLDP over WAN every 30 seconds? LLDP is a layer 2 protocol and has no IP address. It has a source Unicast MAC address and a destination Multicast MAC address.

Wireshark shows that my LLDP packets contains router switch port real MAC address, while WAN MAC address is cloned. Doesn't that make WAN MAC address cloning pointless?
 
Back
Top