Close port 445

[ColinTaylor]

When I look at this example: https://www.asus.com/support/FAQ/1013636/, it looks like the "source" was a WAN IP.

Yes, I've seen that image before. Ignore it, it's gibberish. None of those numbers make any sense.

EDIT: Maybe someone should ask Asus to correct that FAQ. This is not the first time someone's been confused by it.

EDIT 2: The other error in that FAQ is "The two options TCP and TCP All are the same". This is untrue, they are completely different. In fact the "TCP ALL" option was removed from Merlin's firmware as it was misleading and functionally useless.

 

[PunchCardBoss]

Yes, I've seen that image before. Ignore it, it's gibberish. None of those numbers make any sense.

Ahhhh. More gibberish. No wonder I'm confused (besides being old and gray haired).

Sooooo, here is a challenge for the more senior members of the forum - @ColinTaylor ; @DJones ; @bennor. How about drafting a comprehensive explanation/tutorial on how to use the "Network Service Filter" with lots of examples. I'm absolutely certain a good tutorial would draw many eyeballs to SNB Forums.

Update: ... And whoever drafts this tutorial will become FAMOUS!

 

[PunchCardBoss]

Yes, I've seen that image before. Ignore it, it's gibberish. None of those numbers make any sense.

EDIT: Maybe someone should ask Asus to correct that FAQ. This is not the first time someone's been confused by it.

EDIT 2: The other error in that FAQ is "The two options TCP and TCP All are the same". This is untrue, they are completely different. In fact the "TCP ALL" option was removed from Merlin's firmware as it was misleading and functionally useless.

DONE!

 

[ColinTaylor]

I'm not sure how much more help a tutorial would be. Provided people read the description on that page it's fairly straight forward. Usually the confusion comes from people ignoring the description and going straight to the settings. They assume it's a bidirectional filter when it isn't. Anything beyond simply blocking a port requires only a basic understanding of TCP/IP which is probably best served by looking for tutorials on the internet as none of that is specific to the Network Services Filter.

 

[DJones]

About as good as I can explain it. ¯\_(ツ)_/¯

I might be wrong idk my brains done enough thinking for one day.

Edit: updated fixed descriptions.

 

[PunchCardBoss]

About as good as I can explain it. ¯\_(ツ)_/¯

I might be wrong idk my brains done enough thinking for one day.

View attachment 48568

Wow! This is pretty good. I think I got it now. I read it twice and saved it for future reference.

So Asus's example has the 8.8.8.8 IP in the "Source" IP field - this is WRONG! Asus should have put the 8.8.8.8 the "Destination" IP field as you have it. No wonder I was having trouble reconciling what I had read to the explanations in this thread.

Mucho Thanks. 1st prize goes to @DJones. @ColinTaylor gets 2nd place.

 

[ColinTaylor]

@DJones I believe your descriptions are wrong.

Under LAN Source IP, as you and I have both said, NSF only affects LAN to WAN traffic (i.e. routed traffic). It does not affect LAN to LAN traffic.

Under Destination IP, Port forwarding is irrelevant as far as the NSF is concerned because that is WAN to LAN traffic. Again, NSF only affects LAN to WAN traffic.

Here is the iptables rule created by my earlier example:

-A NSFW -i br0 -o eth0 -p tcp -m tcp --dport 445 -j DROP

Notice that the source is restricted to br0 (the LAN interface) and the output is restricted to eth0 (the WAN interface).

 

[DJones]

@DJones I believe your descriptions are wrong.

Under LAN Source IP, as you and I have both said, NSF only affects LAN to WAN traffic (i.e. routed traffic). It does not affect LAN to LAN traffic.

Under Destination IP, Port forwarding is irrelevant as far as the NSF is concerned because that is WAN to LAN traffic. Again, NSF only affects LAN to WAN traffic.

Here is the iptables rule created by my earlier example:

-A NSFW -i br0 -o eth0 -p tcp -m tcp --dport 445 -j DROP

Notice that the source is restricted to br0 (the LAN interface) and the output is restricted to eth0 (the WAN interface).

Ah ok yeah that’s were I was having some doubt. See wasn’t exactly sure why you’d have a source port range (internal port) unless you were trying to filter any or a specific LAN device on br0 . Fair I’ll modify it.

But otherwise I agree.

 

[ColinTaylor]

See wasn’t exactly sure why you’d have a source port range (internal port) unless you were trying to filter any or a specific LAN device on br0 .

I suspect that the presence of the source port field is a case "might as well have it". The same goes for all the TCP flag options, which are effectively pointless. I guess someone could think of a theorical scenario for them, but in reality...

 

[DJones]

I suspect that the presence of the source port field is a case "might as well have it". The same goes for all the TCP flag options, which are effectively pointless. I guess someone could think of a theorical scenario for them, but in reality...

Say you had a WAN destination ip and a external port range you'd be blocking all LAN devices (unless specified) from accessing that port at that specific WAN ip. But what happens if you leave the port blank and only have a destination ip. Would that not block all port ranges at that specific WAN destination? I ask because you can drop a wan destination in the list without a port. Either it does nothing or it blocks all port ranges. Same with Internal port range. I'm leaning on blank means not specified.

 

[PunchCardBoss]

I'm leaning on none means not specified

I too have fallen into the same "logic trap". Blank in my mind should mean "no criteria" or all should pass. But is this the same meaning for DENY as ACCEPT? It is ambiguous.

 

[DJones]

Considering you can use greater> , < less then; in the port range. If you wanted to specify all port ranges I assume you'd put 0> or <65535. And anything blank would be not specified.

 

[ColinTaylor]

But what happens if you leave the port blank and only have a destination ip. Would that not block all port ranges at that specific WAN destination?

Yes. Blank means "all".

So typically you might specify only a destination port (i.e. 80 = I want to block access to all HTTP servers on the internet), or only a destination address (i.e. 111.22.33.44 = I want to block access to all services running on 111.22.33.44).

 

[DJones]

Yes. Blank means "all".

So typically you might specify only a destination port (i.e. 80 = I want to block access to all HTTP servers on the internet), or only a destination address (i.e. 111.22.33.44 - I want to block access to all services running on 111.22.33.44).

ok that clears some things up.

 

[PunchCardBoss]

@ColinTaylor
@DJones

It is a work in progress, but this is what I have so far based on @DJones work. It is just a more refined layout. I still need to make adjustments based on @ColinTaylor info in this thread.

BUT, any contributions you guys have will be gladly integrated - please!

Edit1: Revised image incorporating some of @ColinTaylor comments

 

[ColinTaylor]

Your description of Destination IP is confusing to my way of reading it. But it probably makes perfect sense to you.

"By also providing..." implies that you must have already supplied some other information. The implication, reading the fields from left to right, is that this is the source IP or source port. Neither of which is true.

"... on a specific port". This is ambiguous because it's not clear what port you're talking about. Indeed there's no requirement to specify any ports, source or destination.

 

[PunchCardBoss]

Your description of Destination IP is confusing to my way of reading it. But it probably makes perfect sense to you.

"By also providing..." implies that you must have already supplied some other information. The implication, reading the fields from left to right, is that this is the source IP or source port. Neither of which is true.

"... on a specific port". This is ambiguous because it's not clear what port you're talking about. Indeed there's no requirement to specify any ports, source or destination.

Most came from @DJones prior work. I'm still not comfortable writing the descriptions of each field and defer to your better understanding.

Please (please) suggest alternative copy and I will make the adjustments and re-post for further refinement.

 

[DJones]

"... on a specific port" maybe change that to “user defined port range”

“By also providing...” just remove “also”.

Sorry guys my wording might not be the best. From trying to understand the possible inputs in the network filter field Asus made the UI rather ambiguous. I would completely disregard the port range beside the source ip as Colin and I seem to agree it’s a pointless input. The port range beside the destination ip is valid.

Ip address should be in the destination ip not the port range.

 

[PunchCardBoss]

Okay guys. I will try my hand at appropriate NSF field descriptions. But in order for me to do this, I need to really understand how the NSF works. And the best way I know how to understand it is to work a few theoretical examples. So, here they are. Please correct my comment for each example filter below.

 

[ColinTaylor]

You don't need to say "outbound" because all traffic is going to be outbound.

For your port 445 example: "Blocks TCP traffic to port 445 at any address on the WAN".

Your 192.168.100.200 example is ambiguous. If your LAN is 192.168.100.x then it's wrong, otherwise it's OK.

Your 93.158.145.28 example is invalid because it's not a local address.