It’s there in fw3, but disabled.
then it's OK, I guess.
but since we can't see the rules for port 80, and 22, I assume they're (intentionally ?) added on OS level.
I'm guessing that is why all posts I find about it uses cli to edit the iptables?
I added an ssh key and disabled passlogin to feel a BIT safer at least, I was very close to just pull the plug and go back to the old router, but I KNOW I will NEVER fix this then.
So what are your recomendations? Is there a way to add a few rules that could fix this for me?
I REALLY appreciate you guys taking time to help me, trust me, I have TRIED to learn this stuff myself like all other linux things, but this is WAY above my knowledge grade.
If that is true, ppl HAVE TO BE WARNED ABOUT THIS IMMEDIATELY! But I also want to make sure this is actually by design, and not something I actually broke before accusing anybody of anything.
What can I do?
I would consider this device compromised, unplug it, and never use again, until there's a better/trustworthy image available somewhere..
Reimage, see in the same happens again, then it's made on purpose.
Yeah, I'll do that and come back here so maybe someone can help me find out if its actually completely open by design or not.
Be back in a while and hope someone is willing to help out.
Until then, lets assume I fucked up somehow.
(What about the fact the traffic is actually UDP and not TCP?)
Am I (the one) missing something?
Cause this seems like tail chasing.
OpenWRT isn't. If your router is then either you've misconfigured it or you're using a custom image of OpenWRT which has been modified by whoever created it.
What is the output from running cat /etc/config/firewall; cat /etc/firewall.user
on the router?
adbd seems to be Android related, is there some reason for it to run on your device ?
Also let us know where you’re downloading this image from. And post the output from
ubus call system board
So we’re all on the same page from where you’re starting from.
Absolutely!
I just got back to my internet, it took a while to switch back to my old router and get everything to work as I want (since I had to factory reset it)
I will NOT leave this be without finding out what happened, because I'm just as upset as the next fool. If there are actually ppl releasing experimental images that they present as "working out of the box" then this is NOT ok. But again, I want to make sure that I did not fuc*k (funny how one word can stop a whole post) up before pointing fingers. I'm one of those guys who assumes the best rather than worst, call me naive if you want, but that's how I work.
I'm pretty tired now after all this so I might do the reflashing tomorrow and then come back, but believe me, I won't leave without figuring this out!!
it did work out of the box, it might have, however, shipped with some additional, undocumented features
It is a bit harsh to scrap the whole device since there is no proof in the fw config or fw active setup readout of these open ports.
The thing with port scans is that it isn’t that easy to know what it actually has sniffed at if you actually read the whole manual for NMAP for example.
So even if you scan a IP the actual scan system will look around 360° in the uplink and if any device on the way answers on the pinging you will get a false reading for that IP. So the less devices between test computer and device under test the more meaningful answer you will get.
And we have a lot of forum treads with pretty much the same result of you make port scans without understanding port scans.
It would probably be more meaningful test to actually try ssh connecting to port 22 for example on a specific IP address to see what happens instead of port scan it. If the ssh connection is rejected than the whole port scan result is false measurement result.
Using a browser to go to the public IP address the OP posted earlier brought up the Luci login page. Think it's safe to say it was more than a misreporting by nmap.
Maybe it would make sense to learn the following:
Which banana pi? I see several supported devices in the official openwrt listings.
And if the specific model is indeed not supported by the official project, has the op contacted the vendor support channels for help/debugging.
Meanwhile, let’s see the actual firewall file:
Please copy the output of the following commands and post it here using the "Preformatted text </>
" button:
Remember to redact passwords, MAC addresses and any public IP addresses you may have:
cat /etc/config/firewall
Ok @psherman @krazeh @frollic @dave14305
I thought my profile would show the board I have (I added it when creating the profile, mb).
But here goes.
Completely fresh install, NOTHING is changed (I lied earlier, I did change the ip of the router on the previous install) and it does not have access to the internet. I haven't even logged into the webgui, only accessed it with ssh.
I connect directly to it with my win machine and it deliveres new ip when "ipconfig /renew".
Wall of text incoming:
BusyBox v1.33.1 (2021-11-18 23:12:11 UTC) built-in shell (ash)
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
OpenWrt 21.02-SNAPSHOT, r0-f920a121a
Manufacturer: BananaPi
Manufacturer URL: https://www.banana-pi.org/
Bug URL: https://www.banana-pi.org/
ubus call system board
{
"kernel": "5.10.66",
"hostname": "OpenWrt",
"system": "ARMv8 Processor rev 0",
"model": "BananaPi RK3568-BPI-R2PRO-PC HDMI (Linux)",
"board_name": "rockchip,rk3568-bpi-r2pro-pc",
"release": {
"distribution": "OpenWrt",
"version": "21.02-SNAPSHOT",
"revision": "r0-f920a121a",
"target": "bananapi/armv8",
"description": "OpenWrt 21.02-SNAPSHOT r0-f920a121a"
}
}
cat /etc/config/firewall
config defaults
option syn_flood 1
option input ACCEPT
option output ACCEPT
option forward ACCEPT
option fullcone 1
# Uncomment this line to disable ipv6 rules
# option disable_ipv6 1
config zone
option name lan
list network 'lan'
option input ACCEPT
option output ACCEPT
option forward ACCEPT
config zone
option name wan
list network 'wan'
list network 'wan6'
option input REJECT
option output ACCEPT
option forward REJECT
option masq 1
option mtu_fix 1
config forwarding
option src lan
option dest wan
# We need to accept udp packets on port 68,
# see https://dev.openwrt.org/ticket/4108
config rule
option name Allow-DHCP-Renew
option src wan
option proto udp
option dest_port 68
option target ACCEPT
option family ipv4
# Allow IPv4 ping
config rule
option name Allow-Ping
option src wan
option proto icmp
option icmp_type echo-request
option family ipv4
option target ACCEPT
config rule
option name Allow-IGMP
option src wan
option proto igmp
option family ipv4
option target ACCEPT
# Allow DHCPv6 replies
# see https://dev.openwrt.org/ticket/10381
config rule
option name Allow-DHCPv6
option src wan
option proto udp
option src_ip fc00::/6
option dest_ip fc00::/6
option dest_port 546
option family ipv6
option target ACCEPT
config rule
option name Allow-MLD
option src wan
option proto icmp
option src_ip fe80::/10
list icmp_type '130/0'
list icmp_type '131/0'
list icmp_type '132/0'
list icmp_type '143/0'
option family ipv6
option target ACCEPT
# Allow essential incoming IPv6 ICMP traffic
config rule
option name Allow-ICMPv6-Input
option src wan
option proto icmp
list icmp_type echo-request
list icmp_type echo-reply
list icmp_type destination-unreachable
list icmp_type packet-too-big
list icmp_type time-exceeded
list icmp_type bad-header
list icmp_type unknown-header-type
list icmp_type router-solicitation
list icmp_type neighbour-solicitation
list icmp_type router-advertisement
list icmp_type neighbour-advertisement
option limit 1000/sec
option family ipv6
option target ACCEPT
# Allow essential forwarded IPv6 ICMP traffic
config rule
option name Allow-ICMPv6-Forward
option src wan
option dest *
option proto icmp
list icmp_type echo-request
list icmp_type echo-reply
list icmp_type destination-unreachable
list icmp_type packet-too-big
list icmp_type time-exceeded
list icmp_type bad-header
list icmp_type unknown-header-type
option limit 1000/sec
option family ipv6
option target ACCEPT
config rule
option name Allow-IPSec-ESP
option src wan
option dest lan
option proto esp
option target ACCEPT
config rule
option name Allow-ISAKMP
option src wan
option dest lan
option dest_port 500
option proto udp
option target ACCEPT
# allow interoperability with traceroute classic
# note that traceroute uses a fixed port range, and depends on getting
# back ICMP Unreachables. if we're operating in DROP mode, it won't
# work so we explicitly REJECT packets on these ports.
config rule
option name Support-UDP-Traceroute
option src wan
option dest_port 33434:33689
option proto udp
option family ipv4
option target REJECT
option enabled false
# include a file with users custom iptables rules
config include
option path /etc/firewall.user
### EXAMPLE CONFIG SECTIONS
# do not allow a specific ip to access wan
#config rule
# option src lan
# option src_ip 192.168.45.2
# option dest wan
# option proto tcp
# option target REJECT
# block a specific mac on wan
#config rule
# option dest wan
# option src_mac 00:11:22:33:44:66
# option target REJECT
# block incoming ICMP traffic on a zone
#config rule
# option src lan
# option proto ICMP
# option target DROP
# port redirect port coming in on wan to lan
#config redirect
# option src wan
# option src_dport 80
# option dest lan
# option dest_ip 192.168.16.235
# option dest_port 80
# option proto tcp
# port redirect of remapped ssh port (22001) on wan
#config redirect
# option src wan
# option src_dport 22001
# option dest lan
# option dest_port 22
# option proto tcp
### FULL CONFIG SECTIONS
#config rule
# option src lan
# option src_ip 192.168.45.2
# option src_mac 00:11:22:33:44:55
# option src_port 80
# option dest wan
# option dest_ip 194.25.2.129
# option dest_port 120
# option proto tcp
# option target REJECT
#config redirect
# option src lan
# option src_ip 192.168.45.2
# option src_mac 00:11:22:33:44:55
# option src_port 1024
# option src_dport 80
# option dest_ip 194.25.2.129
# option dest_port 120
# option proto tcp
cat /etc/firewall.user
# This file is interpreted as shell script.
# Put your custom iptables rules here, they will
# be executed with each firewall (re-)start.
# Internal uci firewall chains are flushed and recreated on reload, so
# put custom rules into the root chains e.g. INPUT or FORWARD or into the
# special user chains, e.g. input_wan_rule or postrouting_lan_rule.
Are there worries to be had about this image?
Need more info? Shout and I will obey. The board is only sitting there, isolated in its own little network bubble, all alone silently sobbing... xD
Edit.
Looking at the output of /etc/config/firewall at the end. WTF IS 194.25.2.129 ?!?!
I can ping it from my computer, someone/something in Germany??!?
Where do you download it from? It's an odd image because it claims to be a 21.02-SNAPSHOT, but runs Linux 5.10.66, which only appeared in 22.03. Hard to predict what else was turned inside out for this board.
EDIT: Does it come from here:
https://wiki.banana-pi.org/Banana_Pi_BPI-R2_Pro#Release_image
What output do you get now with iptables-save -c
Those entries are commented out as examples for user customization.
Yeah, you are right, should read more carefully.
iptables-save -c
# Generated by iptables-save v1.8.7 on Fri Jan 1 18:54:18 2021
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:postrouting_lan_rule - [0:0]
:postrouting_rule - [0:0]
:postrouting_wan_rule - [0:0]
:prerouting_lan_rule - [0:0]
:prerouting_rule - [0:0]
:prerouting_wan_rule - [0:0]
:zone_lan_postrouting - [0:0]
:zone_lan_prerouting - [0:0]
:zone_wan_postrouting - [0:0]
:zone_wan_prerouting - [0:0]
COMMIT
# Completed on Fri Jan 1 18:54:18 2021
# Generated by iptables-save v1.8.7 on Fri Jan 1 18:54:18 2021
*mangle
:PREROUTING ACCEPT [7265:707350]
:INPUT ACCEPT [6105:444411]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [6820:754080]
:POSTROUTING ACCEPT [6829:757074]
COMMIT
# Completed on Fri Jan 1 18:54:18 2021
# Generated by iptables-save v1.8.7 on Fri Jan 1 18:54:18 2021
*filter
:INPUT ACCEPT [6106:444451]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [6821:754456]
:forwarding_lan_rule - [0:0]
:forwarding_rule - [0:0]
:forwarding_wan_rule - [0:0]
:input_lan_rule - [0:0]
:input_rule - [0:0]
:input_wan_rule - [0:0]
:output_lan_rule - [0:0]
:output_rule - [0:0]
:output_wan_rule - [0:0]
:reject - [0:0]
:syn_flood - [0:0]
:zone_lan_dest_ACCEPT - [0:0]
:zone_lan_forward - [0:0]
:zone_lan_input - [0:0]
:zone_lan_output - [0:0]
:zone_lan_src_ACCEPT - [0:0]
:zone_wan_dest_ACCEPT - [0:0]
:zone_wan_dest_REJECT - [0:0]
:zone_wan_forward - [0:0]
:zone_wan_input - [0:0]
:zone_wan_output - [0:0]
:zone_wan_src_REJECT - [0:0]
COMMIT
Info about the image, compile logs are available at https://forum.banana-pi.org/t/banana-pi-bpi-r2-pro-openwrt-ubuntu-debian-linux-image/13158
So this whole thread is about a private/OEM "21.02" build containing a kernel 5.10 version only used since 22.03 and using a chip rk3568 that is not supported by the regular OpenWrt...
Nice.
The image is likely a mix of 21.02 with backports from 22.03 mixed with vendor's device hardware support code. No idea what they have done to the firewall/NAT code.
You should try to get help from the actual author of the image.
I did some more checking into the actual zip files I had on my computer.
It turns out that the version I'm using is no longer the one linked to in the forum post.
It used to be so the one on the banana pi wiki page was older than the one in the one linked to in the thread I posted. But the logs linked in the wiki was to the link with the post containing the newer images.
That is no longer the case, the forum post must have been changed back to the "old" one. I'm guessing it was removed for exactly the reasons I was experiencing.
Since I cant find this image (OpenWRT-21.02-EMMCBoot-rockdev-MT7531SW-DSA-20220623.zip) but rather only (OpenWRT-EMMCBoot-rockdev-MT7531SW-20220228) there is no real reason to panic.
I'll just delete the image I have on my computer and try the old one out, carefully. xD
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.