It'd be a lot more helpful if you posted the information I asked for earlier ( output of
cat /etc/firewall.user ,
iptables -L -v and
iptables -L -v -t nat) so we could see if there is an actual issue with fw3 or it's a misconfiguration on your part.
It'd be a lot more helpful if you posted the information I asked for earlier ( output of
I think we've exhausted this conversation. I've fixed my problem by overriding this accept rule. I just wanted to make other people aware of this issue.
You may disagree with the current defaults, but this is not an OpenWrt-specific approach.
There are other firewall implementations that also allow
DNAT by default.
Nowadays, this can be considered common sense, similar to
Your refusal to actually assist with any real troubleshooting makes it look like the issue here is nothing to do with fw3 or OpenWRT but is entirely user error/misunderstanding.
OK. Since you say I'm not being public spirited I'll continue to try to convince you. No, I'm not making my firewall.user file public but I'll give an example.
Suppose I want to forward a port in my router so I'll google how to do it. Out of curiosity just now I tried it and the first hit I got was this one. It tells me to do
iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j DNAT --to 192.168.1.2:8080 iptables -A FORWARD -p tcp -d 192.168.1.2 --dport 8080 -j ACCEPT
Note the second line. So suppose I don't want anyone to use my web server. I only want people from ip address 184.108.40.206 to do so. Well, the solution is obvious, I should change the second line to
iptables -A FORWARD -p tcp -d 192.168.1.2 --dport 8080 -s 220.127.116.11 -j ACCEPT
So I put this in my firewall.user file. Logically from what I just read on this web site, all should be well. But it isn't because anyone accessing the port from outside 18.104.22.168 just drops through this rule until they hit the default accept.
vgaetera thinks I'm an idiot for doing this. Well, OK, you are entitled to your opinion...
Why? If it contains any public IP details they're easy enough to redact. It's not exactly a security risk outside of that.
Not sure I'd go quite as far as calling you an idiot, but maybe naïve if you want to add a firewall rule to a router but don't bother including the router software name in your search...
Why would you just not use the tools/configs available within OpenWRT to set up firewall rules?
You'd best be clear about whether you are using OpenWrt firewall or raw iptables.
Mixed setups are possible, but discouraged due to extra issues.
It's normal to stick to your principles and critically evaluate other ways.
However, it's not okay to ignore the recommended method and blindly trust some random site which is unrelated to OpenWrt.
Yes - people who are make mistakes like this deserve to be hacked. You could choose to make it safer by not having well-hidden and completely undocumented default ACCEPT rules at the end of the iptables chain but people who don't follow our rules precisely should expect no mercy.
(Sorry - I don't want to come off as too angry. All I really wanted to do was make people aware of this issue.)
I get it, firewalls are complicated, but the issue isn't with OpenWRT or fw3. The approach you've taken to set up your firewall isn't recommended for exactly this type of reason, it can causes unforeseen issues. And the rule isn't exactly well hidden is it? You found it by running one simple command. It can also be seen quite easily through LuCI.
As I asked before:
Black and white thinking... you'd prefer they catered to your ( 1 in 100 000 ) use cases than integrating rules that will operate with the most clarity, manageability and scope... given what structure exists in front of them...
as mentioned, based on your definition 'right', explain in detail ( with examples ) how you would structure a zone based iptables ruleset, in which 25+ applications will seamlessly modify rules for... ?
context my friend... without it, you might wonder why a tennis ball is not square.
Why does the OP keep saying the rule is undocumented???
I guess the OP really is having a hard time understanding a zone based firewall...I also wonder why they're using custom iptables entries instead of OpenWrt syntax.
For future readers, refrain from placing such rules in the custom area. That area is best used used for rules that can't reduce to UCI syntax.
First sorry for my English, it is not my native language.
And, just to be clear, I like a lot OpenWRT despite things I don't like on this distro (nothing can be perfect), I use it directly on my FTTH 300/300mbps line on a x86_64 mini-pc with VLANs, vlan priorisation (necessary because of my ISP), Wireguard, adblock etc .... so it was not easy to make all working
About this subject I can understand the 2 positions.
I'm an IT guy but not (not at all !!) a network's guy (working mostly on servers rooms+vmware+system to make things simple) and not even a security guy. I can't imagine how a "not IT guy" can understand anything about that stuff.
And, for my day to day needs, I almost never understand anything to the OpenWRT documentation when I need it (and when this doc exists and when it is not completly obsolete).
This existing doc it perhaps very well done .... but in my opinion only for those who already know what we are talking about. So it looks like a doc written by ... and for ... those who already know is not very usefull for all the others.
I don't want to blame anybody, writing good docs is almost more difficult that doing the code itself .. and less interesting.
As an exemple (I took the first that came too me, I don't want anyone trying to explain SNAT today to me ... it's just an exemple):
Ok, those who know what is SNAT don't need to read this at all.
But in my case I (really) don't know what is SNAT ... and I simply didn't understand this chapter and what should be the difference(s) between DNAT/SNAT/Masquerading.
I also didn't understand how this can be done differently than manually (SNAT can also be done manually: .... also !
That's the same thing in many many many computer bioses:
Function Foo: yes/no with the comment:
Used to enable the Foo fonction clap clap clap, thank you, very usefull
Same thing here (just another exemple, I really don't care about that today):
I have many (really, many) exemples of bad/incomplete/incomprehensible/non-existent doc for OpenWRT and I unfortunatly have no enough time to investigate for each new need.
So, for those who know how things work inside OpenWRT: stop telling us: that's not the good way to do, or, you dindn't understand the way it works, or, you have done a bad choice, or, do your homework before asking .... please just explain and/or redirect the guy wich is asking something to a good piece of documentation, we will be happy to learn how to do that well
because that's simply not so easy, neither it is accessible for everybody.
Many guys (like me, like @stringer ) do a lot of efforts/search to understand these things, to do what they can to have a better router/firewall to protect their home network (many ISP or commercial routers are bad with many backdoors and no security updates, so it is smart to try to replace them with a great piece of software like OpenWRT)
I read really too often replies like I read here from guys who knows to guys who ask ... it is not very kind.
Because many things are not explained about how things work inside OpenWRT. Many things are hidden inside OpenWRT, and these choices were not explained to us.
And for you, those who know, you can't even figure out that it's impossible to find the correct information for those who don't yet know how these things work
Almost all the documentation is done the same way (with short tutorials/exemples about the most common needs/use cases, and .... that's all, no explanation, nothing more) where it should perhaps be better to list/explain all the available functions instead. We (I) have no enough time to go on each package's Github to read all the code to discover wich option/variable do what.
And, as I told early, English is not my native language, I try to make a lot of efforts in this aspects but sometime the documention uses very complexe sentences/words/concepts for many guys (at least for me) and things can be very confusing
Last aspect, the beginning of the firewall doc tells:
... but nowhere .. NOWHERE ... on this doc it is explained how to do that with LUCI ... you can only find how to do that with the configuration files.
Even the most beginning of the firewall configuration doesn't visually match the configuration files organisation if you don't carrefully understand how it works on the files vs how it works on Luci, it is at least very confusing .. and if you don't understand why I'm saying that it is because you already know how it works for too long and so you are not able anymore to understand why it should be hard for some non-already-linux-firewall-aware guys (it is not my config, I took that on Google images):
Just to help to understand what I mean:
- the left and right parts are independant on the firewall file (forwarding between defined zones on the left -- ONE zone configuration on the right) ... not on Luci because on the same line
- the right part (zone configuration) doesn't care about the forwarding destination, it only cares about the source zone defined on the left
.... but, because it is on the same line it is confusing.
A newcomer (like me a short time ago) will naturaly think that the right part is used to configure the left part, but it is not the case
There should be a better solution to display that no ? (just an example, remember)
Then why are you looking at it?
Wouldn't you go to a site like this instead of a router manual:
Why do you assume a router manual will tell you these things???
You have not once showed an example of an iptables rule you are trying to place into OpenWrt.
Did you actually look????
No, you did not look:
(If you don't know firewall terms, but are looking at a router's manual in the firewall section...how do you know what you want to configure?)
EDIT: And I digress, I realized you are not the OP.
An ex-boss told me something like that a long time ago:
I you take time to read things more carefully you will write less useless replies (sorry hard to translate and I don't want to offence anybody)
My reply never talked about technical aspects but about how guys reply to others here in this forum and how hard it is to find good or up to date OpenWRT information.
So I was just asking everybody to understand that one guy (here @stringer) created this post to inform about a problem he had (and found a solution for) to help others if they are facing the same problem.
And I just don't really agree with the replies he received.
I have no technical question.
I faced the same kind of replies some weeks ago about IPv6 questions, and because lacks in the OpenWRT documentation it was hard and so I made some errors/mistakes before asking the community, I received not pleasant replies. despite the time I spent to try to understand how to made this well.
So I just wanted to ask "those who know" to be gentle with "those who ask"
I know, I read it and participated. I also wondered why you didn't use the config provided by HE on thier site.
I assumed you knew what you were doing (since you told us what you wanted to do with the prefixes), and choose NOT to read the OpenWrt and HE manual.
that's not the subject here but I wanted to do something that IS NOT REALLY EXPLAINED in the doc.
I started with the openwrt+he doc (and it worked fine) and, after, I had another need (split the 3 prefixes, one from my ISP and the 2 from HE and never give 2 of them to the same downstream interface/network) and it was not easy until someone talked to me about iface aliases that are configurable on the config files (not on luci).
OpenWRT is very powerfull, but it is hard to find the configuration options needed to use this power
it is 5AM here, I have to go to bed
I run https://www.fail2ban.org/ and it only allows like a given number of attempts to connect before requiring a waiting period. Works for SSH and a lot of other protocols as well. Cheers!
For those who may be short on flash space, rules can also be added to OpenWrt, SSH samples below:
# time DROP rule config rule option src 'wan' option name 'SSH_CheckDrop' option family 'ipv4' option proto 'tcp' option dest '*' option dest_port '22' option target 'DROP' option extra '--syn -m recent --name ssh --update --seconds 300 --hitcount 5' # ACCEPT if above DROP criteria not met config rule option target 'ACCEPT' option family 'ipv4' option proto 'tcp' option src 'wan' option dest_port '22' option extra '--syn -m recent --name ssh --set' option name 'SSH_CheckAccept' option dest '*' # this connlimit rule is also an example of applying the rule to a different WAN DST ports than tcp/22 # fix if you will use tcp/22 config redirect option target 'DNAT' option src 'wan' option dest 'lan' option proto 'tcp' option src_dport 'xxxxxxxx-xxxxxxx' option dest_port '22' option name 'SSH-ConnectLimit' option extra '--syn -m connlimit --connlimit-above 3' # add here normal port forward(s) from WAN to the `src_dport` listed in connlimit - to SSH server LAN IP/port
Should work for whatever you can configure in proper syntax.
It's best to not expose Dropbear/uHTTPd to the internet if you really care about security.
That's because a single critical vulnerability could be enough to grant root privileges to the attacker.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.