Hikvision camera resets ITSELF to factory default twice!

[ndstate]

Be glad they only reset the camera (and hope they didn't install infected firmware too). Maybe the attacker decided a reset, which might take the camera off the internet, was better than inserting a warning message into the camera's text overlay and leaving it online (where it would be vulnerable to worse attacks). Look at me, assuming a guy who hacks cameras for fun really has your best interests at heart.

As for why camera manufacturers have UPnP on by default, I don't think anyone knows. Nobody knows to look for an open port they didn't set up themselves.

Would upgrading the firmware take care of any infected firmware? So all of the precautions I took of VPNing into my network to view cameras were basically voided by UPnP being on in the camera? I have also now setup my router to block all (WAN) services for all my cameras (I use an IP range). I presume this would have over ridden any UPnP issues?

So they got into the camera via the reported backdoor? I guess I never considered UPnP opening ports and assumed since I had to VPN to access the cameras I was safe. I guess I forgot a lot from those CISCO networking classes 18+ years ago. LOL.

Besides using ShieldsUp and having to VPN into the network to access BlueIris is there something else I should be doing to ensure I have secured everything? Thanks so much.

 

[alastairstevenson]

I disabled UPnP on my router. Running ShieldsUp on my Blue Iris server shows everything as stealth. On my Ubuntu laptop I am seeing 20, 21, 22 as closed, not stealth.

Was this before or after you disabled UPnP on the router? If after, it would have been interesting to see the before status.

 

[bpratt]

So this hack is coming in via port 80 or is it because UPNP is enabled ?

Just wondering if changing port numbers would make it any safer or not.

I'd like to be able to continue to use ivms-4500 when I'm out and about, rather totally block all access to the camera from outside.

Don't feel competant to try hacking firmwares for my ali express purchases.

 

[fenderman]

So this hack is coming in via port 80 or is it because UPNP is enabled ?

Just wondering if changing port numbers would make it any safer or not.

I'd like to be able to continue to use ivms-4500 when I'm out and about, rather totally block all access to the camera from outside.

Don't feel competant to try hacking firmwares for my ali express purchases.

it will not help...the bots easily scan all ports
fyi...ivms 4500 does not need the http port (default 80) forwarded to work...all it needs is the media port (default 8000)...
maybe someone can comment on whether this exploit is possible with just the media port forwarded...
regardless, you dont need to update the firmware, but rather disable forwarding and setup a vpn.

 

[Dez]

Just change default port numbers to something random, "hackers" usually mass scanning only 80 and 8000 ports

 

[Silas]

Just change default port numbers to something random, "hackers" usually mass scanning only 80 and 8000 ports

Really? I hope you are just kidding, oh here comes a hacker, oh port 80 isn't open, hmm must be a secure system, better move on...

 

[MrRalphMan]

Really? I hope you are just kidding, oh here comes a hacker, oh port 80 isn't open, hmm must be a secure system, better move on...

Why do you think another valid HTTP port is 8080, that's much more (80 ports) secure...

 

[Dez]

Really? I hope you are just kidding, oh here comes a hacker, oh port 80 isn't open, hmm must be a secure system, better move on...

No, i'm not, i'm talking only about these kids who run automatic mass scanning on default ports, of course if you will simply change the port it will not completely fix the problem, but at least you will be safe from these "hackers" who break cameras just for fun.

 

[Tolting Colt Acres]

To be fair though, Most ISPs (here in the states, at least) have IDS systems which will block mass port scans, so putting your cameras on non standard ports (especially in, say, the high 20,000 range) is not likely to get scanned.

 

[bpratt]

Yes I know the 'script kiddies' scan more than just the default ports, was just wondering if this hack was primarily coming in on port 80 or 8000 or being found by upnp being enabled.

I wanted to be able to still use ivms4500 on my phone, which is normally on a dynamic IP back to my home which has a bunch of publically routable IP's on it.

It's sounding more and more like having to run a vpn from my phone/mobile device, back in to home, and then block incoming to the IP's my cameras are located on.

Sadly my cameras were bought through aliexpress, so chinese cameras with old firmware from 5.2.5 build 141201 to 5.4.23 build 161020 . The only camera that hasn't been hacked/defaulted is one with 5.4.5 build 170124 on it.

 

[Silas]

Hacking 0000001
Get angryip
Goto Internet
Select ip range of routable address
Run angryip
Browse results with web browser
If amazed at the number of 'devices' that are sat on port 80
Consider your a hacker

 

[Mike A.]

To be fair though, Most ISPs (here in the states, at least) have IDS systems which will block mass port scans, so putting your cameras on non standard ports (especially in, say, the high 20,000 range) is not likely to get scanned.

The way that the automated bots typically operate is that the workload and IP/port ranges are broken up across large numbers of machines so you don't usually see mass scans like that. It takes on a Christmas tree-type structure where, first, vulnerable machines are located and then they are employed to do further scanning/exploitation with the workload broken up using subsets and random numbers. And so on down the line with the network taking on multiplicative power as it grows. Once potential targets are identified for specific exploits, more directed scanning at a greater level can be done since they're dealing with far fewer numbers.

I don't know what the current numbers are but from an experiment done in 2012 to demonstrate the effect:

Starting with one device and assuming a scan speed of ten IP addresses per second, it should find the next open device within one hour. The scan rate would be doubled if we deployed a scanner to the newly found device. After doubling the scan rate in this way about 16.5 times, all unprotected devices would be found; this would take only 16.5 hours. Additionally, with one hundred thousand devices scanning at ten probes per second we would have a distributed port scanner to port scan the entire IPv4 Internet within one hour.

They eventually ended up with 420,000 client devices in their botnet which identified and scanned 460 million hosts. You can imagine what's out there now.

Virtually everything gets scanned these days. I know mine gets hit on all kinds of odd ports. Any open ports are very quickly found. The port that's opened dynamically by OpenVPN is always quickly found. Right now it's in the 196xx range and being hit from the Netherlands.

As an example, a list of attempted connections to destination ports from unique hosts over about 15 minutes tonight. Origins in China, Brazil, Ukraine, Netherlands, US, etc. Only listed the first port tried for each host where they hit multiple beyond that:

23
23
23
23
23
23
23
23
33
80
129
2022
2323
2323
3333
3389
3451
5060
5066
5076
8080
8383
8888
8888
9600
33887
46735
50802
53360

 

[Defender666]

The question is, is latest Hik Firmware also vulnerable if it is different from earlier security flaws.

 

[Tolting Colt Acres]

The way that the automated bots typically operate is that the workload and IP/port ranges are broken up across large numbers of machines so you don't usually see mass scans like that.

IDS software vendors have adapted to this brute-force approach. Now they look for a pattern of repeated port scans to a single hosts (or group of hosts) within a certain time period.

Sure, with a large number of bots you could scan through all ports over a long period of time and probably avoid detection. I tend to think folks using the brute force approach will scan less protected networks instead where they are likely to have greater success.

All I'll say is I have a single inbound ssh port enabled on my router as an emergency backup in case I cannot get in via VPN (which has happened), and nobody has attempted to log in via that port, ever, to log in, in the 9 years I've had it.

 

[alastairstevenson]

Sadly my cameras were bought through aliexpress, so chinese cameras with old firmware from 5.2.5 build 141201 to 5.4.23 build 161020 .

You might therefore consider doing the 'enhanced mtd hack' and then updating to more secure firmware : Hikvision DS-2CD2x32-I (R0) brick-fix tool / full upgrade method / fixup roundup.

 

[Mike A.]

IDS software vendors have adapted to this brute-force approach. Now they look for a pattern of repeated port scans to a single hosts (or group of hosts) within a certain time period.

Sure, with a large number of bots you could scan through all ports over a long period of time and probably avoid detection. I tend to think folks using the brute force approach will scan less protected networks instead where they are likely to have greater success.

All I'll say is I have a single inbound ssh port enabled on my router as an emergency backup in case I cannot get in via VPN (which has happened), and nobody has attempted to log in via that port, ever, to log in, in the 9 years I've had it.

Apparently it's not working all that well for Verizon. Mine get pounded continually. Over time virtually every port will be hit.

Making the connect and logging into ssh is much harder than just testing a port and connecting to various other services. I rarely see random tests against default ssh ports in my logs. Likely because it's a relatively costly thing to try to attack in terms of resources required. Only going to see much of that in the case that somebody specifically targets that host. On the other hand, telnet on 23 is the most common port scanned. Hundreds of scans every day from all over. If there's something responding there that will get LOTS of attention. Same with common trojan ports and other known exploits. You can watch the volume of attempts quickly increase once a connection is detected and a "positive" address gets propagated.

Below is ~45 min earlier tonight. As above, just trying to hide on a higher port doesn't really work anymore. They get tested all the time. Better than having it on a default port for something like this Hikvision backdoor since you'll avoid some just quickly testing for that specific exploit and moving on but you're not really hiding anything. Once something responding to http requests is found there it will get more attention.

Sep 30 20:01:44 DROP SRC=5.8.48.21 DPT=3322
Sep 30 20:02:29 DROP SRC=94.120.24.28 DPT=23
Sep 30 20:03:50 DROP SRC=185.188.207.15 DPT=53
Sep 30 20:04:17 DROP SRC=103.26.210.180 DPT=23
Sep 30 20:04:39 DROP SRC=5.188.10.108 DPT=23389
Sep 30 20:05:07 DROP SRC=5.249.22.7 DPT=137
Sep 30 20:06:35 DROP SRC=176.35.176.26 DPT=23
Sep 30 20:06:43 DROP SRC=113.128.104.207 DPT=18245
Sep 30 20:06:57 DROP SRC=120.12.158.191 DPT=23
Sep 30 20:06:57 DROP SRC=120.12.158.191 DPT=23
Sep 30 20:06:57 DROP SRC=120.12.158.191 DPT=2323
Sep 30 20:06:57 DROP SRC=120.12.158.191 DPT=23
Sep 30 20:06:57 DROP SRC=120.12.158.191 DPT=23
Sep 30 20:09:35 DROP SRC=114.112.100.88 DPT=1433
Sep 30 20:11:04 DROP SRC=191.101.167.245 DPT=11222
Sep 30 20:14:17 DROP SRC=191.96.249.168 DPT=389
Sep 30 20:14:33 DROP SRC=186.67.146.19 DPT=23
Sep 30 20:17:08 DROP SRC=222.173.42.245 DPT=1433
Sep 30 20:18:05 DROP SRC=211.226.208.220 DPT=23
Sep 30 20:18:33 DROP SRC=74.82.47.48 DPT=523
Sep 30 20:20:36 DROP SRC=118.200.195.157 DPT=23
Sep 30 20:21:29 DROP SRC=5.188.86.39 DPT=34382
Sep 30 20:22:10 DROP SRC=5.188.203.55 DPT=2664
Sep 30 20:22:13 DROP SRC=5.8.48.21 DPT=7062
Sep 30 20:23:13 DROP SRC=176.32.32.85 SPT=5222 DPT=5077
Sep 30 20:23:13 DROP SRC=176.32.32.85 SPT=5222 DPT=5079
Sep 30 20:23:13 DROP SRC=176.32.32.85 SPT=5222 DPT=5071
Sep 30 20:23:13 DROP SRC=176.32.32.85 SPT=5222 DPT=5078
Sep 30 20:23:13 DROP SRC=176.32.32.85 SPT=5222 DPT=5072
Sep 30 20:23:13 DROP SRC=176.32.32.85 SPT=5222 DPT=5075
Sep 30 20:23:13 DROP SRC=176.32.32.85 SPT=5222 DPT=5074
Sep 30 20:23:13 DROP SRC=176.32.32.85 SPT=5222 DPT=5073
Sep 30 20:23:13 DROP SRC=176.32.32.85 SPT=5222 DPT=5076
Sep 30 20:27:09 DROP SRC=122.240.163.22 SPT=59362 DPT=1433
Sep 30 20:27:31 DROP SRC=84.220.234.137 SPT=50614 DPT=23
Sep 30 20:30:12 DROP SRC=116.75.123.190 SPT=54521 DPT=23
Sep 30 20:31:32 DROP SRC=12.9.125.6 SPT=52707 DPT=23
Sep 30 20:31:42 DROP SRC=163.172.171.174 DPT=5060
Sep 30 20:32:02 DROP SRC=185.56.82.34 DPT=80
Sep 30 20:33:58 DROP SRC=46.174.191.30 DPT=51138
Sep 30 20:37:18 DROP SRC=191.101.167.245 DPT=61616
Sep 30 20:40:05 DROP SRC=80.211.135.29 DPT=53413
Sep 30 20:40:08 DROP SRC=195.3.146.96 DPT=3398
Sep 30 20:40:09 DROP SRC=5.8.48.21 DPT=7075
Sep 30 20:40:33 DROP SRC=217.23.1.22 DPT=3309
Sep 30 20:40:49 DROP SRC=219.91.155.9 DPT=23
Sep 30 20:40:56 DROP SRC=80.24.52.73 DPT=23
Sep 30 20:45:18 DROP SRC=164.52.0.130 DPT=143
Sep 30 20:45:18 DROP SRC=164.52.0.130 DPT=49431

 

[Defender666]

The MTD Hack seems not to work for non R0 cameras. No way to downgrade G1 cameras to enable SSH

 

[Tolting Colt Acres]

Apparently it's not working all that well for Verizon. Mine get pounded continually. Over time virtually every port will be hit.

In your sample log, most of your hits are one and two, which usually fall below the threshold.

As I stated before, given enough hosts and enough time, yes, every port can be probed. If you have 100k bots out there, all it takes is one bot per port.

I have a single SSH port open through my firewall, as a failsafe if I ever need to get in (there have been times where I cannot get in, because where I am at is blocking the GRE protocol or some other port necessary to establish a VPN connection). In the past 7 years I have not had a single intrusion attempt. This is not to say it will never happen, but, its far easier to scan on known ports and less secure networks than it is to invest the time and effort on more secure networks.

 

[alastairstevenson]

No way to downgrade G1 cameras to enable SSH

Does SSH show as 'filtered' or 'closed' if you nmap the camera IP address?

If you feel inclined to spend time exploring this - and on the possibly big assumption that the G1 hardware is the same as the G0 hardware -
With the inability of the publicly-available unpacker/repacker tools to handle the recent G1 firmware, you'd have to resort to connecting to the camera serial console to start manipulating the internals of the firmware.
And then you'd have to get past the block that is psh in order to be able to do anything useful.
On my Chinese G0 camera I was able to do this by tftp booting a uImage into a debug mode with no psh running that allowed full access via the shell.
And on my 3335 Chinese camera, dropbear was not present, so SSH would not be possible.
This was one of the changes that I made once I'd gained access.
A bit of messing around, but as much for the interest and experience as anything else, as this camera had resisted all previous attempts to upgrade or downgrade using any versions of G0 or G1 firmware I'd had to hand. Until I accidentally erased the sys/app/cfg partitions and broke it.

alastair@PC-I5 ~ $ ssh admin@192.168.1.64
admin@192.168.1.64's password:


BusyBox v1.19.3 (2016-07-12 16:09:01 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

# prtHardInfo
Start at 2017-10-01 13:57:37
Serial NO :DS-2CD3335D-I20150619AACH524222564
V5.4.20 build 160726
NetProcess Version: 1.7.1.204140 [16:40:42-Jul 11 2016]
Db Encrypt Version: 65537
Db Major Version: 1176
Db svn info:
Path: /Camera/Platform/Branches/branches_frontend_software_platform/db_process_for_5.4.20
Last Changed Rev: 201703
Last Changed Date: 2016-06-17 09:43:40 +0800 (Fri, 17 Jun 2016)
hardwareVersion    = 0x0
hardWareExtVersion    = 0x0
encodeChans        = 1
decodeChans        = 1
alarmInNums        = 0
alarmOutNums        = 0
ataCtrlNums        = 0
flashChipNums        = 0
ramSize            = 0x100
networksNums        = 1
language            = 1
devType            = 0x22501
net reboot count    = 0
vi_type            = 32
Path: /Camera/Platform/Branches/branches_frontend_software_platform/IPC_develop_branch/ipc_e0_g0_r3_5.4.20
Last Changed Rev: 210205
Last Changed Date: 2016-07-25 21:49:11 +0800 (Mon, 25 Jul 2016)


#

 

[Mike A.]

In your sample log, most of your hits are one and two, which usually fall below the threshold.

As I stated before, given enough hosts and enough time, yes, every port can be probed. If you have 100k bots out there, all it takes is one bot per port.

I have a single SSH port open through my firewall, as a failsafe if I ever need to get in (there have been times where I cannot get in, because where I am at is blocking the GRE protocol or some other port necessary to establish a VPN connection). In the past 7 years I have not had a single intrusion attempt. This is not to say it will never happen, but, its far easier to scan on known ports and less secure networks than it is to invest the time and effort on more secure networks.

Which is what I'd said earlier. You don't typically see a single machine scanning a full or large ranges of ports. The workload is distributed across many machines working together. The days of defending against some kid randomly sequentially scanning your ports are long over. Now it's a more ordered, comprehensive, distributed scanning of everything on the net by 10s of millions of bots. There's not really any hiding of things just by moving them up in port number. Because you have a secured encrypted login that hasn't been cracked isn't an equivalent case vs a cam with known vulnerabilities just hung off of a port forward and relying on nothing but the obscurity of a high port number to protect it.

If you watch your logs you can see how the scans are distributed. These are several related machines working together scanning from the same time period above. One tries 23389 then 3389, another transposes the numbers to check 3398, another 2664 then 2665, and on and on through a larger range of ports...

Sep 30 20:04:39 DROP SRC=5.188.10.108 DPT=23389
Sep 30 20:21:29 DROP SRC=5.188.86.39 DPT=3438
Sep 30 20:22:10 DROP SRC=5.188.203.55 DPT=2664
Sep 30 20:51:52 DROP SRC=5.188.10.108 DPT=3389
Sep 30 21:24:25 DROP SRC=5.188.203.55 DPT=2665
Sep 30 21:35:59 DROP SRC=5.188.10.12 DPT=3398

Then you'll also see more-intensive coordinated scans of ports testing for specific services/exploits:

Oct 1 4:15:54 DROP SRC=64.94.228.199 TTL=1 SPT=38173 DPT=33437
Oct 1 4:15:55 DROP SRC=64.94.228.199 TTL=2 SPT=38173 DPT=33438
Oct 1 4:15:56 DROP SRC=64.94.228.199 TTL=3 SPT=38173 DPT=33439
Oct 1 4:15:57 DROP SRC=64.94.228.199 TTL=4 SPT=38173 DPT=33440
Oct 1 4:15:59 DROP SRC=64.94.228.201 TTL=1 SPT=38179 DPT=33439
Oct 1 4:16:00 DROP SRC=64.94.228.201 TTL=2 SPT=38179 DPT=33440
Oct 1 4:16:01 DROP SRC=64.94.228.201 TTL=3 SPT=38179 DPT=33441
Oct 1 4:16:02 DROP SRC=64.94.228.201 TTL=4 SPT=38179 DPT=33442
Oct 1 4:16:04 DROP SRC=64.94.228.198 TTL=1 SPT=38174 DPT=33439
Oct 1 4:16:05 DROP SRC=64.94.228.198 TTL=2 SPT=38174 DPT=33440
Oct 1 4:16:06 DROP SRC=64.94.228.198 TTL=3 SPT=38174 DPT=33441
Oct 1 4:16:07 DROP SRC=64.94.228.198 TTL=4 SPT=38174 DPT=33442
Oct 1 4:16:09 DROP SRC=64.94.228.203 TTL=1 SPT=38178 DPT=33439
Oct 1 4:16:10 DROP SRC=64.94.228.203 TTL=2 SPT=38178 DPT=33440
Oct 1 4:16:11 DROP SRC=64.94.228.203 TTL=3 SPT=38178 DPT=33441
Oct 1 4:16:12 DROP SRC=64.94.228.203 TTL=4 SPT=38178 DPT=33442
Oct 1 4:16:14 DROP SRC=64.94.228.197 TTL=1 SPT=38175 DPT=33438
Oct 1 4:16:15 DROP SRC=64.94.228.197 TTL=2 SPT=38175 DPT=33439
Oct 1 4:16:16 DROP SRC=64.94.228.197 TTL=3 SPT=38175 DPT=33440
Oct 1 4:16:17 DROP SRC=64.94.228.197 TTL=4 SPT=38175 DPT=33441
Oct 1 4:16:19 DROP SRC=64.94.228.196 TTL=1 SPT=38176 DPT=33439
Oct 1 4:16:20 DROP SRC=64.94.228.196 TTL=2 SPT=38176 DPT=33440
Oct 1 4:16:21 DROP SRC=64.94.228.196 TTL=3 SPT=38176 DPT=33441
Oct 1 4:16:22 DROP SRC=216.52.192.118 TTL=1 SPT=32284 DPT=33439
Oct 1 4:16:22 DROP SRC=64.94.228.196 TTL=4 SPT=38176 DPT=33442
Oct 1 4:16:23 DROP SRC=216.52.192.118 TTL=2 SPT=32284 DPT=33440
Oct 1 4:16:24 DROP SRC=216.52.192.118 TTL=3 SPT=32284 DPT=33441
Oct 1 4:16:25 DROP SRC=216.52.192.118 TTL=4 SPT=32284 DPT=33442
Oct 1 4:16:27 DROP SRC=216.52.192.110 TTL=1 SPT=32290 DPT=33439
Oct 1 4:16:28 DROP SRC=216.52.192.110 TTL=2 SPT=32290 DPT=33440
Oct 1 4:16:29 DROP SRC=216.52.192.110 TTL=3 SPT=32290 DPT=33441
Oct 1 4:16:30 DROP SRC=216.52.192.110 TTL=4 SPT=32290 DPT=33442
Oct 1 4:16:32 DROP SRC=216.52.192.115 TTL=1 SPT=32285 DPT=33439
Oct 1 4:16:33 DROP SRC=216.52.192.115 TTL=2 SPT=32285 DPT=33440
Oct 1 4:16:34 DROP SRC=216.52.192.115 TTL=3 SPT=32285 DPT=33441
Oct 1 4:16:35 DROP SRC=216.52.192.115 TTL=4 SPT=32285 DPT=33442
Oct 1 4:16:37 DROP SRC=216.52.192.111 TTL=1 SPT=32289 DPT=33438
Oct 1 4:16:38 DROP SRC=216.52.192.111 TTL=2 SPT=32289 DPT=33439
Oct 1 4:16:39 DROP SRC=216.52.192.111 TTL=3 SPT=32289 DPT=33440
Oct 1 4:16:40 DROP SRC=216.52.192.111 TTL=4 SPT=32289 DPT=33441
Oct 1 4:16:42 DROP SRC=216.52.192.114 TTL=1 SPT=32286 DPT=33439
Oct 1 4:16:43 DROP SRC=64.94.1.176 TTL=1 SPT=38742 DPT=33439
Oct 1 4:16:43 DROP SRC=216.52.192.114 TTL=2 SPT=32286 DPT=33440
Oct 1 4:16:44 DROP SRC=64.94.1.176 TTL=2 SPT=38742 DPT=33440
Oct 1 4:16:44 DROP SRC=216.52.192.114 TTL=3 SPT=32286 DPT=33441
Oct 1 4:16:45 DROP SRC=64.94.1.176 TTL=3 SPT=38742 DPT=33441
Oct 1 4:16:45 DROP SRC=216.52.192.114 TTL=4 SPT=32286 DPT=33442
Oct 1 4:16:47 DROP SRC=64.94.1.176 TTL=4 SPT=38742 DPT=33442
Oct 1 4:16:48 DROP SRC=216.52.192.112 TTL=1 SPT=32288 DPT=33441
Oct 1 4:16:49 DROP SRC=64.94.1.170 TTL=1 SPT=38747 DPT=33438
Oct 1 4:16:49 DROP SRC=216.52.192.112 TTL=2 SPT=32288 DPT=33442
Oct 1 4:16:50 DROP SRC=64.94.1.170 TTL=2 SPT=38747 DPT=33439
Oct 1 4:16:50 DROP SRC=216.52.192.112 TTL=3 SPT=32288 DPT=33443
Oct 1 4:16:51 DROP SRC=64.94.1.170 TTL=3 SPT=38747 DPT=33440
Oct 1 4:16:51 DROP SRC=216.52.192.112 TTL=4 SPT=32288 DPT=33444
Oct 1 4:16:52 DROP SRC=64.94.1.170 TTL=4 SPT=38747 DPT=33441
Oct 1 4:16:53 DROP SRC=216.52.192.113 TTL=1 SPT=32287 DPT=33437
Oct 1 4:16:54 DROP SRC=64.94.1.175 TTL=1 SPT=38743 DPT=33437
Oct 1 4:16:54 DROP SRC=216.52.192.113 TTL=2 SPT=32287 DPT=33438
Oct 1 4:16:55 DROP SRC=64.94.1.175 TTL=2 SPT=38743 DPT=33438
Oct 1 4:16:55 DROP SRC=216.52.192.113 TTL=3 SPT=32287 DPT=33439
Oct 1 4:16:56 DROP SRC=64.94.1.175 TTL=3 SPT=38743 DPT=33439
Oct 1 4:16:56 DROP SRC=216.52.192.113 TTL=4 SPT=32287 DPT=33440
Oct 1 4:16:57 DROP SRC=64.94.1.175 TTL=4 SPT=38743 DPT=33440
Oct 1 4:16:59 DROP SRC=64.94.1.171 TTL=1 SPT=38746 DPT=33439
Oct 1 4:17:00 DROP SRC=64.94.1.171 TTL=2 SPT=38746 DPT=33440
Oct 1 4:17:01 DROP SRC=64.94.1.171 TTL=3 SPT=38746 DPT=33441
Oct 1 4:17:02 DROP SRC=64.94.1.171 TTL=4 SPT=38746 DPT=33442
Oct 1 4:17:04 DROP SRC=64.94.1.173 TTL=1 SPT=38744 DPT=33439
Oct 1 4:17:05 DROP SRC=64.94.1.173 TTL=2 SPT=38744 DPT=33440
Oct 1 4:17:06 DROP SRC=64.94.1.173 TTL=3 SPT=38744 DPT=33441
Oct 1 4:17:07 DROP SRC=64.94.1.173 TTL=4 SPT=38744 DPT=33442
Continuing for hours from other source IPs rolling through more ports in that same general high range...

This goes on all day, everyday, times thousands of different IPs originating from 10s of millions of bots continually scanning every IP out there. Anyone who monitors their logs will see the exact same thing. Put something vulnerable out there and it's just a matter of time before it will be found. Yes, you'll likely be found faster if you have the same vulnerable service/device on a known default port that's targeted but a high port number won't protect you.