This morning just before apparently 8:30 my R7800 (on 21.02) restarted. It was functioning fine for at least a few weeks. What caused the restart? I don't know. The router logs to my NAS but nothing strange is logged.
What worries me is that as soon as the router restarted i saw this sequence of events in its eventlog:
Thu Oct 14 08:26:58 2021 daemon.notice netifd: Network device 'wlan1' link is up
Thu Oct 14 08:26:59 2021 authpriv.info dropbear[3122]: Child connection from 41.47.233.161:36603
Thu Oct 14 08:26:59 2021 authpriv.info dropbear[3122]: Exit before auth from <41.47.233.161:36603>: Exited normally
Thu Oct 14 08:26:59 2021 authpriv.info dropbear[3124]: Child connection from 41.47.233.161:36648
Thu Oct 14 08:27:00 2021 daemon.info dnsmasq[3163]: Connected to system UBus
Thu Oct 14 08:27:00 2021 daemon.info dnsmasq[3163]: started, version 2.85 cachesize 150
Thu Oct 14 08:27:00 2021 daemon.info dnsmasq[3163]: DNS service limited to local subnets
Thu Oct 14 08:27:00 2021 daemon.info dnsmasq[3163]: compile time options: IPv6 GNU-getopt no-DBus UBus no-i18n no-IDN DHCP no-DHCPv6 no-Lua TFTP no-conntrack no-ipset no-auth no-cryptohash no-DNSSEC no-ID loop-detect inotify dumpfile
Thu Oct 14 08:27:00 2021 daemon.info dnsmasq[3163]: UBus support enabled: connected to system bus
Thu Oct 14 08:27:00 2021 daemon.info dnsmasq-dhcp[3163]: DHCP, IP range 192.168.1.100 -- 192.168.1.249, lease time 12h
Thu Oct 14 08:27:00 2021 daemon.info dnsmasq[3163]: using only locally-known addresses for domain test
Thu Oct 14 08:27:00 2021 daemon.info dnsmasq[3163]: using only locally-known addresses for domain onion
Thu Oct 14 08:27:00 2021 daemon.info dnsmasq[3163]: using only locally-known addresses for domain localhost
Thu Oct 14 08:27:00 2021 daemon.info dnsmasq[3163]: using only locally-known addresses for domain local
Thu Oct 14 08:27:00 2021 daemon.info dnsmasq[3163]: using only locally-known addresses for domain invalid
Thu Oct 14 08:27:00 2021 daemon.info dnsmasq[3163]: using only locally-known addresses for domain bind
Thu Oct 14 08:27:00 2021 daemon.info dnsmasq[3163]: using nameserver 127.0.0.1#5053
Thu Oct 14 08:27:00 2021 daemon.info dnsmasq[3163]: using nameserver 127.0.0.1#5054
Thu Oct 14 08:27:00 2021 daemon.info dnsmasq[3163]: using only locally-known addresses for domain lan
Thu Oct 14 08:27:00 2021 daemon.info dnsmasq[3163]: read /etc/hosts - 4 addresses
Thu Oct 14 08:27:00 2021 daemon.info dnsmasq[3163]: read /tmp/hosts/odhcpd - 1 addresses
Thu Oct 14 08:27:00 2021 daemon.info dnsmasq[3163]: read /tmp/hosts/dhcp.cfg01411c - 8 addresses
Thu Oct 14 08:27:00 2021 daemon.info dnsmasq-dhcp[3163]: read /etc/ethers - 0 addresses
Thu Oct 14 08:27:01 2021 authpriv.warn dropbear[3124]: Bad password attempt for 'root' from 41.47.233.161:36648
Thu Oct 14 08:27:02 2021 authpriv.info dropbear[3124]: Exit before auth from <41.47.233.161:36648>: (user 'root', 1 fails): Exited normally
The entries at time stamp 08:26:59 and 08:27:01 and 08:27:02 worry me. What happened here?
Tried some to log in to my router? As the title says "Should I be worried?". Is my router false configured? Is there a connection between the restart and these entries?
I looked up the ip address and it refers to an address in Cairo/Egypt.
Do you have ssh open to the WAN? Password or key based auth? Highly recommend disabling password based if you are open to the WAN. Also consider running a non-standard port and using a util like fail2ban or if possible 2-factor auth.
I'm not aware that SSH is open to WAN. This is how my SSH is configured.
Looking at the interface info; it appears to listens to all interfaces (including the WAN).
Is this bad configured? It is or should be stock 21.02.
This is bog standard SSH brute forcing like it happens to any internet connected host offering an SSH server. Apparently your SSH port is exposed to the WAN, otherwise you wouldn't see those entries. Normally access to port 22 from WAN is prevented by default firewall settings, you must have changed something that allows this access now.
But apart from that, Bad password attempt means that authentication didn't succeed and Exit before auth means that the brute forcing bot quit the connection without trying further.
please connect to your router via ssh and provide the contents of the /etc/config/firewall file. The screenshots aren't sufficient for a proper review.
Also, changing the SSH interface to LAN doesn't actually prevent connections from the WAN (although there is nuance here that may result in the same effect, but it is not the preferred way to ensure that WAN connectivity is prohibited).
config defaults
option syn_flood 1
option input ACCEPT
option output ACCEPT
option forward REJECT
# 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
config redirect
option target 'DNAT'
option src 'wan'
option dest 'lan'
option proto 'tcp udp'
option dest_ip '192.168.1.100'
option name 'QBit'
option src_dport '62496'
option dest_port '62496'
config redirect
option target 'DNAT'
option src 'wan'
option dest 'lan'
option proto 'tcp udp'
option src_dport '42638'
option dest_ip '192.168.1.10'
option dest_port '42638'
option name 'NAS'
option enabled '0'
config redirect
option target 'DNAT'
option src 'wan'
option dest 'lan'
option dest_ip '192.168.1.125'
option name 'XBoxOne'
option src_port '3544'
option src_dport '50426'
option dest_port '50426'
option proto 'tcp udp'
config redirect
option target 'DNAT'
option src 'wan'
option dest 'lan'
option dest_ip '192.168.1.126'
option name 'XBox360'
option proto 'tcp udp'
option dest_port '3074'
option src_dport '3074'
config redirect
option src 'wan'
option name 'XBoxX'
option target 'DNAT'
option dest 'lan'
option dest_ip '192.168.1.132'
option dest_port '50007'
list proto 'tcp'
list proto 'udp'
option src_dport '50007'
/etc/config$ ip route
default via xx.yy.184.1 dev eth0.2 src xx.yy.184.135
xx.yy.184.0/23 dev eth0.2 scope link src xx.yy.184.135
192.168.1.0/24 dev br-lan scope link src 192.168.1.1
That looks fine too. My only guess is that the firewall was simply not initialized for a brief period of time while your router rebooted which caused one or two connection attempts to "slip through". Especially if these were the only ones. Normally SSH servers are brute forced all the time, so if your port 22 would be exposed still, you'd see ongoing login attempts.
As for the cause of the reboot, it is likely not related to SSH but either an OOM condition or a Kernel OOPS/bug, e.g. due to instabilities in the wireless driver.
Sounds like a credible theory. The login attempt took place during start-up, probably at just the right moment.
Thanks for your effort. I was realy worried I had done something stupid. Keep up the good work.
Seems like you're okay. But if you're ever in doubt, you can always reset your router to defaults (take a backup first), and re-create your settings. The advantage here is that, instead of simply restoring your backup, you'll have the opportunity to review your settings as you go (but you'll have a backup to use as reference and/or to restore if you have any difficulties with the process of recreating everything).
And obviously you've come here, which is always good -- the forums are here to help in all sorts of ways
