Am I being hacked?

I just looked at my logs and they are littered with someone trying to ssh into my openwrt box. I'm on x86, 23.05.2. I'm relatively new, but is there something I can do to mitigate this? I believe someone is trying to brute force it.

I'm getting a lot of this:

Thu Mar 28 15:01:22 2024 authpriv.info dropbear[9957]: Child connection from 183.81.169.238:34104
Thu Mar 28 15:01:23 2024 authpriv.warn dropbear[9957]: Bad password attempt for 'root' from 183.81.169.238:34104
Thu Mar 28 15:01:24 2024 authpriv.info dropbear[9957]: Exit before auth from <183.81.169.238:34104>: (user 'root', 1 fails): Exited normally

I would agree, but the open port 34104 is something you configured yourself.

But the port keeps switching in the log. It's always a different port. As far as I know, I don't have anything forwarded for the firewall, and the only thing I've done is add Openvpn with Nord.

Post /etc/config/firewall.

Does your NordVPN accept external connections in the other end of the tunnel?

I'm not sure the the answers to the nord tunnel.

Do I just post the dump from

uci show firewall``` 

?

Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button:
grafik
Remember to redact passwords, MAC addresses and any public IP addresses you may have:

ubus call system board
cat /etc/config/network
cat /etc/config/firewall

Thank you for your time so far. I'm hoping I redacted what I had to. Hope I'm not wasting your time.

root@OpenWrt:~# ubus call system board
{
        "kernel": "5.15.137",
        "hostname": "OpenWrt",
        "system": "Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz",
        "model": "HP HP EliteDesk 800 G3 SFF",
        "board_name": "hp-hp-elitedesk-800-g3-sff",
        "rootfs_type": "squashfs",
        "release": {
                "distribution": "OpenWrt",
                "version": "23.05.2",
                "revision": "r23630-842932a63d",
                "target": "x86/64",
                "description": "OpenWrt 23.05.2 r23630-842932a63d"
        }
}
root@OpenWrt:~# cat /etc/config/network

config interface 'loopback'
        option device 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'redacted'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'eth0'
        list ports 'eth1'
        list ports 'eth3'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option ipaddr '192.168.1.1'
        option netmask '255.255.255.0'
        option ip6assign '60'

config interface 'wan'
        option device 'eth2'
        option proto 'dhcp'

config interface 'wan6'
        option device 'eth2'
        option proto 'dhcpv6'
        option reqaddress 'try'
        option reqprefix 'auto'

config interface 'nordvpntun'
        option proto 'none'
        option device 'tun0'

config interface 'docker'
        option device 'docker0'
        option proto 'none'
        option auto '0'

config device
        option type 'bridge'
        option name 'docker0'

root@OpenWrt:~# cat /etc/config/firewall

config defaults
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option synflood_protect '1'
        option drop_invalid '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'

config rule
        option name 'Allow-DHCP-Renew'
        option src 'wan'
        option proto 'udp'
        option dest_port '68'
        option target 'ACCEPT'
        option family 'ipv4'

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'

config rule
        option name 'Allow-DHCPv6'
        option src 'wan'
        option proto 'udp'
        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'

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'

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'

config include 'pbr'
        option fw4_compatible '1'
        option type 'script'
        option path '/usr/share/pbr/pbr.firewall.include'

config zone
        option name 'vpnfirewall'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option masq '1'
        option mtu_fix '1'
        list network 'nordvpntun'

config forwarding
        option src 'lan'
        option dest 'vpnfirewall'

config zone 'docker'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        option name 'docker'
        list network 'docker'

config redirect
        option dest 'lan'
        option target 'DNAT'
        option name 'plex'
        option src 'wan'
        option dest_ip '192.168.1.1'
        list proto 'all'
        option enabled '0'```

34104 is the remote port of the attacker, & upon every retry that changes. Thats not the issue.
@bigsleezy Some how your port 22 is exposed to external network.

Install fail2ban in the mean time? Is your device in a DMZ?

This guy has tried from at least 4 IP address I can see in my logs. 3 went back to a VPN IP after I checked them. Then a static address in China. Is there any way to force drop packets coming in on port 22?

Assuming you have exposed your device intentionally to the internet for your private intentions (for example remote access) then you have to deal with it and accept those annoying connection attempts. The best short term solution is to install fail2ban that will blacklist the IPs from failed connection attempts.
The web is full of scanning bots knocking up to doors with number 22 stamped on them. You can additionally change your default ssh port to something way higher for increased security.

There are 3 tick marks "```" at the end of this rule... can you check that this is purely a copy-paste issue in the forum? If the ticks are in the in the actual config file, that might do strange things.

Also, although it is disabled, you should probably remove it... this doesn't have a port number associated, and anything that points to the router itself should be a rule, not a redirect.

1 Like

I think I may have figured it out. I had a firewall rule to open to the outside for my plex port 32400 for my router IP (the one hosting my plex app). I think he was using that. I haven't had an ssh login attempt since I closed that port.

I initially opened that port to allow access for my movies and shows outside of my house. According to my logs, after I shut that port down on my firewall, I haven't had another attempt.

This is what it looked like in the log.

Thu Mar 28 15:01:19 2024 authpriv.info dropbear[9948]: Child connection from 183.81.169.238:34060
Thu Mar 28 15:01:20 2024 authpriv.warn dropbear[9948]: Bad password attempt for 'root' from 183.81.169.238:34060
Thu Mar 28 15:01:20 2024 authpriv.info dropbear[9948]: Exit before auth from <183.81.169.238:34060>: (user 'root', 1 fails): Exited normally
Thu Mar 28 15:01:21 2024 authpriv.info dropbear[9956]: Child connection from 183.81.169.238:34064
Thu Mar 28 15:01:21 2024 authpriv.warn dropbear[9956]: Bad password attempt for 'root' from 183.81.169.238:34064
Thu Mar 28 15:01:22 2024 authpriv.info dropbear[9956]: Exit before auth from <183.81.169.238:34064>: (user 'root', 1 fails): Exited normally
Thu Mar 28 15:01:22 2024 authpriv.info dropbear[9957]: Child connection from 183.81.169.238:34104
Thu Mar 28 15:01:23 2024 authpriv.warn dropbear[9957]: Bad password attempt for 'root' from 183.81.169.238:34104
Thu Mar 28 15:01:24 2024 authpriv.info dropbear[9957]: Exit before auth from <183.81.169.238:34104>: (user 'root', 1 fails): Exited normally
Thu Mar 28 15:03:35 2024 user.notice pbr: Reloading pbr due to firewall action: includes
Thu Mar 28 15:03:35 2024 user.notice pbr: Activating traffic killswitch [✓]
Thu Mar 28 15:03:36 2024 user.notice pbr: Setting up routing for 'wan/eth2/73.15.132.1' [✓]
Thu Mar 28 15:03:36 2024 user.notice pbr: Setting up routing for 'nordvpntun/tun0/10.8.1.3' [✓]
Thu Mar 28 15:03:36 2024 user.notice pbr: Routing 'qbit' via nordvpntun [✓]
Thu Mar 28 15:03:36 2024 user.notice pbr: Deactivating traffic killswitch [✓]
Thu Mar 28 15:03:36 2024 user.notice pbr: service monitoring interfaces: wan nordvpntun
Thu Mar 28 15:03:36 2024 user.notice SQM: Stopping SQM on eth2
Thu Mar 28 15:03:36 2024 daemon.notice ttyd[8368]: [2024/03/28 15:03:36:9386] N: rops_handle_POLLIN_netlink: DELADDR
Thu Mar 28 15:03:37 2024 user.notice SQM: Starting SQM script: piece_of_cake.qos on eth2, in: 1400000 Kbps, out: 220000 Kbps
Thu Mar 28 15:03:37 2024 user.notice SQM: piece_of_cake.qos was started on eth2 successfully
Thu Mar 28 15:07:15 2024 user.notice pbr: Reloading pbr wan6 interface routing due to ifupdate of wan6 (eth2)
Thu Mar 28 15:07:18 2024 user.notice pbr: Reloading pbr wan6 interface routing due to ifupdate of wan6 (eth2)
Thu Mar 28 15:08:34 2024 user.notice pbr: Reloading pbr wan6 interface routing due to ifupdate of wan6 (eth2)
Thu Mar 28 15:08:38 2024 user.notice pbr: Reloading pbr wan6 interface routing due to ifupdate of wan6 (eth2)

Edit: @psherman, it was a copy error. I may sound stupid, but how do I make it a rule, not a redirect?

This is an example of a rule (already in the default firewall):

From LuCI, you can do this on the "Traffic Rules" tab of the firewall config.

1 Like

Also, my firewall did have a port number on it when I made it initially. I'm thinking somehow he got in and changed it? I don't think I'd have been that stupid and opened ALL of my ports to my router and not caught it.

I can't say if they got in or not... I would think they wouldn't have continued the 'attempts' if they already had access. But I could be wrong.

If you are in any doubt, though, reset to defaults and configure from scratch. Make a backup if you'd like, but don't restore it directly since it would just restore whatever config changes they might have made (if they actually did gain access)..

1 Like

Better safe than sorry. Thanks for everyones helpful hints. I'll try not to be a knob next time!

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.