What's new

Merlin Firewall...???

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Since you know about iptables, I am thinking that it will be easier if you flash the iptables and redo the order of it. U can use the existing system generated as guide and input them when necessary.
This script should be place in the firewall-start script.

I am not expert but I self learn too. I think the current setting is good enough for basic user but if u need customisation, you have to be an expert on your own. After all this router is meant for basic user level and asuswrt-merlin is just a slight upgrade based on its existing platform. But don't think u can expect must from a brand new GUI for the firewall configuration. Alternatively is can try out openwrt which really start the router bare and full customisation. Lol. I don't like it.
 
Last edited:
Since you know about iptables, I am thinking that it will be easier if you flash the iptables and redo the order of it. U can use the existing system generated as guide and input them when necessary.
This script should be place in the firewall-start script.

I am not expert but I self learn too. I think the current setting is good enough for basic user but if u need customisation, you have to be an expert on your own. After all this router is meant for basic user level and asuswrt-merlin is just a slight upgrade based on its existing platform. But don't think u can expect must from a brand new GUI for the firewall configuration. Alternatively is can try out openwrt which really start the router bare and full customisation. Lol. I don't like it.
I'm absolutely new to iptables and doing self study. I work on nterprise network firewalls so I am Quite Well Skilled on the basis but in linux i'm much more like a goat! :) also, i gave a read to the Skynet script and it is simply Incredible for complexity and as Well as functionality. It does auto learn and works well a lot. I only need to Add some details but Because of the complexity of IP Tables Itself It's really not easy. In such case If I will Keep Merlin I will never give up about using Skynet. Also I Found Where To donate something for Merlin but not for Skynet That is a huge work too

Sent from a phone cab with Tapatalk
 
Coming from a Checkpoint non-Linux world as well....highly recommend looking at pfSense or one of the various related flavors to get the GUI interface you seek. I started with m0n0wall many years ago and moved on to pfSense when that project ended. It is waaaaaay easier to maintain when you don't have the time and/or motivation to learn/re-learn iptables each time you want to make a change.
 
Coming from a Checkpoint non-Linux world as well....highly recommend looking at pfSense or one of the various related flavors to get the GUI interface you seek. I started with m0n0wall many years ago and moved on to pfSense when that project ended. It is waaaaaay easier to maintain when you don't have the time and/or motivation to learn/re-learn iptables each time you want to make a change.

Very nice project (even if claiming to be same state of Check Point GUI seems to me a bit presumptuous) but I don't think it can run on Asus Merlin box. If I have to put another device in the chain I can freely use Fortinet or ChckPoint soho boxes we have for testing purposes, but I don't want to fire a fly with bazooka :) And its better to learn something more about iptables.

Up to now I wuold like to better understand the -m and -j options, and what is the command line I have to issue (and consequently put in a script to run after the Skynet initialization) to block all packet to/from internet of an internal device, logging them, and allow (before the drop) some ports/ip.
 
Very nice project (even if claiming to be same state of Check Point GUI seems to me a bit presumptuous) but I don't think it can run on Asus Merlin box. If I have to put another device in the chain I can freely use Fortinet or ChckPoint soho boxes we have for testing purposes, but I don't want to fire a fly with bazooka :) And its better to learn something more about iptables.

Up to now I wuold like to better understand the -m and -j options, and what is the command line I have to issue (and consequently put in a script to run after the Skynet initialization) to block all packet to/from internet of an internal device, logging them, and allow (before the drop) some ports/ip.
Lol... yes it is a bazooka firing small flies...
 
Understood. I am running on x86 hardware since my requirements were generally always above what the ARM/MIPS routers could provide over the years.

And no...the GUI is nowhere near what Checkpoint's interface is...but it is good enough for casual home use for sure. I actually despise the current Checkpoint GUI...it is like they changed things just to change them and finding things has become quite the challenge since I don't work in the FW manager on a daily basis anymore.
 
I started some tests but I didn't good results.

I run these two commands:
Code:
iptables -A FORWARD -s 192.168.2.97 -j LOG --log-prefix "Ball_CAM_Drop"
iptables -A FORWARD -s 192.168.2.97 -j DROP

But I don't see any log in the /tmp/syslog.log and the host still communicate with internet.

Where is the problem?

Edit: Because the -A was an append statement and instead I must insert the rule before the others :)
 
I started some tests but I didn't good results.

I run these two commands:
Code:
iptables -A FORWARD -s 192.168.2.97 -j LOG --log-prefix "Ball_CAM_Drop"
iptables -A FORWARD -s 192.168.2.97 -j DROP

But I don't see any log in the /tmp/syslog.log and the host still communicate with internet.

Where is the problem?
You'll probably want to use -I to insert the rule at the top of the table. -A appends to the end so there may be a rule further up accepting the traffic
 
Also bear in mind that if you're inserting rules at the beginning of the chain each insertion will "push" the previous rule down the order. So either insert them in the reverse order or insert them using absolute rule numbers.
Code:
iptables -I FORWARD -s 192.168.2.97 -j DROP
iptables -I FORWARD -s 192.168.2.97 -j LOG --log-prefix "Ball_CAM_Drop"
or
Code:
iptables -I FORWARD 1 -s 192.168.2.97 -j LOG --log-prefix "Ball_CAM_Drop"
iptables -I FORWARD 2 -s 192.168.2.97 -j DROP

P.S. I prefer to look at the output of iptables-save to understand the existing rules.
 
P.S. I prefer to look at the output of iptables-save to understand the existing rules.

Its another command I didn't know and its nice becaquse it shows a rule sequence that is more clearly understandable for who has GUI approach.
Finally I set up these rules:
Code:
iptables -I FORWARD 1 -p udp -s 192.168.2.97 --destination-port 123 -j ACCEPT

iptables -I FORWARD 2 -p udp -s 192.168.2.97 -d 8.8.8.8 --destination-port 53 -j ACCEPT
iptables -I FORWARD 3 -p tcp -s 192.168.2.97 --destination-port 587 -j ACCEPT
iptables -I FORWARD 4 -s 192.168.2.97 -j LOG --log-prefix "[BLOCKED - OUTBOUD Ball_CAM] "
iptables -I FORWARD 5 -s 192.168.2.97 -j DROP

And I put them even i the firewall-start script after the call to Skynet.
It seems to be working, and as I was already sure of, the KKMOON camera tryes to reach on a cyclic base some addresses that are related to alibaba but I don't know for what reason

Code:
Jan  5 14:13:52 kernel: [BLOCKED - OUTBOUD Ball_CAM] IN=br0 OUT=eth0 SRC=192.168.2.97 DST=47.94.56.41 LEN=32 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=UDP SPT=52572 DPT=32100 LEN=12 MARK=0x6
Jan  5 14:13:52 kernel: [BLOCKED - OUTBOUD Ball_CAM] IN=br0 OUT=eth0 SRC=192.168.2.97 DST=47.91.165.44 LEN=32 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=UDP SPT=52572 DPT=32100 LEN=12 MARK=0x6
Jan  5 14:13:52 kernel: [BLOCKED - OUTBOUD Ball_CAM] IN=br0 OUT=eth0 SRC=192.168.2.97 DST=47.88.0.50 LEN=32 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=UDP SPT=52572 DPT=32100 LEN=12 MARK=0x6
Jan  5 14:13:52 kernel: [BLOCKED - OUTBOUD Ball_CAM] IN=br0 OUT=eth0 SRC=192.168.2.97 DST=47.94.56.41 LEN=72 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=UDP SPT=52572 DPT=32100 LEN=52 MARK=0x6
Jan  5 14:13:52 kernel: [BLOCKED - OUTBOUD Ball_CAM] IN=br0 OUT=eth0 SRC=192.168.2.97 DST=47.91.165.44 LEN=72 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=UDP SPT=52572 DPT=32100 LEN=52 MARK=0x6
Jan  5 14:13:52 kernel: [BLOCKED - OUTBOUD Ball_CAM] IN=br0 OUT=eth0 SRC=192.168.2.97 DST=47.88.0.50 LEN=72 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=UDP SPT=52572 DPT=32100 LEN=52 MARK=0x6

Now I would like to do an enanched filter on DNS calls to avoid any resolution than the FQDN of the provider's smtp server and the ntp one. This to avoid leak of data through apparently authorized connections.
 
Looks like port 32100 is used for the cloud based mobile app. There's some discussion about it on the internet. Also described here,

https://pierrekim.github.io/blog/2017-03-08-camera-goahead-0day.html
Wow! The lack of https access was already the reason for which I never exposed any of my cheap webcams. I already saw while I was using the billion router that the dbpower webcam was trying to reach some destinations in China and similar. And I blocked that behaviour with the billion's firewall. That's the reason because I wanted to set up a real firewall even on the Asus.
Even the KKMOON that I own actually was never exposed to internet, how can it be already compromised? This would mean that the software out of the box already contains malicious code.
 
Now I would like to do an enhanced filter on DNS calls to avoid any resolution other than the FQDN of the provider's smtp server and the ntp one. This to avoid leak of data through apparently authorized connections.
I'm not sure I'm understanding what you're trying to block, but you can't use iptables to "look inside" packets and understand one DNS lookup from another. You're already dropping all packets that aren't destined for DNS, NTP or SMTP.

If you want to force the camera to go to specific NTP and SMTP servers you can do that by rewriting the destination address in the PREROUTING chain (this is how the DNSFilter works).
Code:
iptables -t nat -A PREROUTING -s 192.168.2.97 -p tcp -m tcp --dport 587 -j DNAT --to-destination 12.34.56.78
iptables -t nat -A PREROUTING -s 192.168.2.97 -p udp -m udp --dport 123 -j DNAT --to-destination 188.114.116.1
Change the destination IP addresses accordingly.
 
I'm not sure I'm understanding what you're trying to block, but you can't use iptables to "look inside" packets and understand one DNS lookup from another. You're already dropping all packets that aren't destined for DNS, NTP or SMTP.

You were right, thats what I want to do, looking inside the dns packets and drop everything (from the cam) that is not requiring the resolution of
time.nist.gov
smtp.fastwebnet.it
That are the ntp settings FQDN for time adjust and the SMTP for motion detection alarm relay.

If you want to force the camera to go to specific NTP and SMTP servers you can do that by rewriting the destination address in the PREROUTING chain (this is how the DNSFilter works).
Code:
iptables -t nat -A PREROUTING -s 192.168.2.97 -p tcp -m tcp --dport 587 -j DNAT --to-destination 12.34.56.78
iptables -t nat -A PREROUTING -s 192.168.2.97 -p udp -m udp --dport 123 -j DNAT --to-destination 188.114.116.1
Change the destination IP addresses accordingly.

Powerful feature, but because in the packets can be encapsulated data coming from inside, simply redirecting should not be done, even because the other side can see those communication like some kind of intrusion and put my address onto quarantine or blacklist. So its better to drop.
I'm looking how to check inside the packets, must be done in the mangle table but I'm still looking for the full command.
 
Powerful feature, but because in the packets can be encapsulated data coming from inside, simply redirecting should not be done, even because the other side can see those communication like some kind of intrusion and put my address onto quarantine or blacklist. So its better to drop.
I still can't imagine what it is you're trying to protect against and how looking at DNS requests will help you :confused:. The only thing a DNS request is going to do is give you an IP address. You are happy enough to send "encapsulated data" to the NTP and SMTP servers but not Google's DNS :confused::confused:. If that's the case then maybe you need to run your own "fake" DNS server that only resolves two addresses (NTP and SMTP).

Maybe this is what you're after:

https://www.centos.org/forums/viewtopic.php?t=58860
 
Last edited:
I still can't imagine what it is you're trying to protect against and how looking at DNS requests will help you :confused:. The only thing a DNS request is going to do is give you an IP address. You are happy enough to send "encapsulated data" to the NTP and SMTP servers but not Google's DNS :confused::confused:.

Its simple, I want that the cam is able to resolve only two FQDNs. Resolving other, could bring to use the fact that I set some "any destination" rules to send out data.
For example, If I know that port TCP 587 is open, I can setup on internet a server that answers on TCP 587 and connect to it after having resolved its name by dns.
Obviously even the DNS filter can be bypassed having a fixed ip address server on the othe side, but hardcoding an ip address into malicious code restrict drammatically the possibilities to use that way, and once the server is gone, all the code become unusable.
So limiting the dns answers, should efficiently address possible problems.
I know its a bit obsessive, but my work is into network security so I like to do so, and also is a nice challenge to better learn iptables.

If that's the case then maybe you need to run your own "fake" DNS server that only resolves two addresses (NTP and SMTP).

Yes, but the less the processes on the router the best will be the performance and stability.


Yes its something like that, and it address an error that I would have done for sure, like using the "."
 
There is way more to DNS than just IP address resolution. The amount of information that can be passed back and forth via DNS is impressive. There are nation-state attackers that have used this method to pass data and commands through Enterprise firewalls successfully.

Now....in a home environment....it is less likely to be used and abused as much.

But to note...iptables is not an app layer firewall. It pretty much ends at Layer4 so any app inspection/enforcement will need to be done elsewhere.

Also to note...your example of 537 abuse...blocking DNS doesn't prevent abuse of that port...it just means they can't use a name that must be resolved. If the attacker wants to abuse 537, they still can if they just directly reference an IP.

Sent from some device using Tapatalk
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top