Im using a hex RB750Gr3 starting with the default settings and firewall and I modified them a bit. I disabled the services I don’t use and made ssh and winbox only available from inside the LAN 192.168.88.0/24 as shown below (4). I also want to setup a firewall rule that drops all requests from the WAN to ssh port 22 and winbox port 8219, but allows them from the LAN side. I’m having trouble setting that up correctly per (1) and (2) below. What do I need to set “in-interface” to in order to block from the WAN only? My interfaces are in (3) below. Thank you.
WAN is on eth1 but this does not work to block ssh from the WAN (in-interface=ether1).
4 ;;; DROP SSH FROM WAN ON ETH1
chain=input action=drop protocol=tcp in-interface=ether1 dst-port=22 log=no log-prefix=""
This works but block ssh from all ports including the LAN (in-interface=bridge).
4 ;;; DROP SSH FROM WAN ON ETH1
chain=input action=drop protocol=tcp in-interface=bridge dst-port=22 log=no log-prefix=""
Here are my interfaces…
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU MAX-L2MTU MAC-ADDRESS
0 R ether1 ether 1500 1596 2026 08:55:31:6B:50:8A
1 RS ether2 ether 1500 1596 2026 08:55:31:6B:50:8B
2 RS ether3 ether 1500 1596 2026 08:55:31:6B:50:8C
3 S ether4 ether 1500 1596 2026 08:55:31:6B:50:8D
4 S ether5 ether 1500 1596 2026 08:55:31:6B:50:8E
5 R ;;; defconf
bridge bridge 1500 1596 08:55:31:6B:50:8B
These are the services…
# NAME PORT ADDRESS CERTIFICATE
0 XI telnet 23
1 XI ftp 21
2 XI www 80
3 ssh 22 192.168.88.0/24
4 XI www-ssl 443 none
5 XI api 8728
6 winbox 8291 192.168.88.0/24
7 XI api-ssl 8729 none
Why waste time writing all this?
Simply the DEFAULT firewall rules already protect everything from the WAN, not just SSH and WINBOX (e.g. DNS, telnet, NTP server, etc.),
and are allowed from LAN what are leaved enabled.
But must be the true DEFAULT rules, not something “see on youtube”, for example, or something senselessly modified.
This is easily accomplished as stated by the default firewall rules.
Let me direct you to the rule in question.
INPUT CHAIN (traffic to and fro the router)
add action=drop chain=input comment=“defconf: drop all not coming from LAN” disabled=yes in-interface-list=!LAN
As the last rule in the input chain it says, DROP all traffic Not coming from the LAN! DONE!
However, this allows ALL users on the LAN full access to the ROUTER, for router services they need and access to services they dont need SSH/winbox).
So I believe the question you have posed could be better stated as.
How do I ensure that only I, as the admin, are able to access the router for configuration purposes.
Answer.
Replace the single default rule with a more encompassing drop everything rule.
But you need to put some rules ahead of this last rule so that you as admin can access the router and lan users can access services.
INPUT CHAIN
add chain=input action=accept in-interface-list=LAN src-address-list=adminaccess
add action=accept chain=input comment=“Allow DNS from local” dst-port=53
in-interface-list=LAN protocol=udp
add action=accept chain=input comment=“Allow DNS from local” dst-port=53
in-interface-list=LAN protocol=tcp
add chain=input action=drop comment=“drop all else”
where firewall address list (from static set DHCP leases)
add ip=ip of admin desktop list=adminacccess
add ip=ip of admin latpop list=adminaccess
add ip=ip of admin ipad list=adminaccess
add ip=ip of admin smartphone list=adminaccess.
YOu add services required,
So if upnp is required you add it before drop all rule
So if NTP is added you add it before drop rule.
Not sure what you mean by DHCP, not required on input chain rule??
Otherwise none of my configs would work LOL.
PS> capsman is for people that like beating themselves with a belt,
a. for using mT home wifi and b.for using caspsman not my problem. Take pills maybe…
Summary, the rules I use work very well, dont need to do anything funky
Its a block all, add what you need strategy that is simple, clean.
I hope to explain better:
With the changes you have proposed, the DHCP Server stops working as well, except for the administrative addresses.
The DHCP Server is a service inside RouterBOARD, and if you block the input chain on that way, the devices are unable to obtain the IP from DHCP Server.
Better leave the default rules and secure the admin services on proper places.
p firewall filter
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=\
established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment="Allow ADMIN to Router" in-interface=RBG-wg log-prefix="AdminAccess test" \
src-address=192.168.hh.p
add action=accept chain=input comment="Allow ADMIN to Router" log-prefix=AdminAccess src-address-list=adminaccess
add action=accept chain=input comment="Allow LAN DNS queries - TCP" connection-state=new dst-port=53 in-interface-list=\
LAN protocol=tcp
add action=accept chain=input comment="Allow LAN DNS queries-UDP" connection-state=new dst-port=53 in-interface-list=\
LAN protocol=udp
add action=accept chain=input comment="Allow NTP service" connection-state=new dst-port=123 in-interface-list=LAN \
protocol=udp src-address-list=NTPserver
add action=accept chain=input comment=allowWGTUNNELstart disabled=yes dst-port=xxxxx in-interface-list=WAN log=yes \
log-prefix="FIRST HIT FROM WG " protocol=udp src-address-list=CAR_WAN
add action=accept chain=input comment=allowWGTUNNELstart disabled=yes dst-port=yyyyy in-interface-list=WAN log=yes \
log-prefix="FIRST HIT FROM IPHONE" protocol=udp
add action=drop chain=input comment="Drop All Else"
Hi rextended, I normally believe anything you say without checking into it but in this case I have to explore a bit.
My own configs for at least 3 years consists of the config I just gave the OP.
My DHCP service for the LANS works great.
MY CLIENT DHCP service for the WANS works great.
SO I have to ask which DHCP service are you talking about???
Maybe thinking bout Radius server functionality?
I do not think is so hard to explain/understand…
One thing is the DHCP Server service
another is DHCP Client service
If you block port 67 and 68 udp on input, you broken part of the DHCP protocol deleting the packet that DHCP Client send back to DHCP Server, to see what you discard, simply add this rule before drop all:
I have some problem on the past (2017/07/26) with some device that can’t “talk back” to DHCP Server,
and after that “discovery” no longer have “failed assign address”.
Not all device do that problem, but if happen, often this is the reason…
I do not have any experience about sniff those packets and see inside what contains, for that, do not ask…
That is very interesting,…
I will have to explore some more.
I have two DHCP clients and have not had any issues connecting that are unusual.
My bell client upon any kind of disconnect needs the route to be manually updated with the new gateway but that was an issue for my zyxel routers as well.
The rest of the bell client information is inserted into the router just fine.
I never have any issues with my dhcp client on the cable modem ISP.
My suspicion is that the FIRST input rule accept, is where this dhcp client info communication occurs ??
(established, related, untracked)
I will be the first to admin I dont have a clue about the initial router ISP handshaking other than its fun to look at in wireshark!!
Thanks for the replies. I get it now. My initial tests were faulty and made me think that the default firewall need to be modified to block ssh. In my testing I ssh into my router from a computer on the LAN to the router’s piblic WAN side IP addresss. Since this was working I thought the firewall rules need to be changed. I guess the router firewall sees this as a request from the LAN so it does not block it? After seeing the replies to my post I had a friend try to ssh into my router from his house and it did not work with the default firewall rules.
As stated, the default firewall rules ensure you are safe out of the blocks, however one can later fine tune and be more precise on who has access to especially the router itself.
