One of the products of the Dshield project (https://isc.sans.edu/howto.html) is seeing what is trending in scanning activity (https://isc.sans.edu/trends.html). This sometimes drives a "request for packets" like my last shift (https://isc.sans.edu/forums/diary/Request+for+Packets+Port+15454/23888/). Most of the responses we get from such requests are logs of probes, or pcaps of SYN traffic because the ports are just not commonly used, so there's not a lot of honeypots set up for them already.
In the last reqeust I sent out, I thought of how helpful it would be to have my own open-every-port sensor to go along with my distributed closed-on-every-port sensors. Then I imagined how my logs would fill up with SSH brute forcing, and propbes for open web proxies. That didn't sound very fun or interesting-- but a sensor open on every port that isn't popular sounded more interesting.
To proof-of-concept this, I set up a listener for a range of ports which listened for ports 15000-16000. This helped confirm that port 15454 wasn't the only port targeted in the scan, and it turned out to be just a boring RDP search for weak Admin sessions.
When port 52869 showed up on the trending report, I opened up 52000 through 53000 to see what landed. This soon captured the traffic discussed in https://isc.sans.edu/forums/diary/When+Cameras+and+Routers+attack+Phones+Spike+in+CVE20148361+Exploits+Against+Port+52869/23942/
This morning's trending report noted 8983, so I retuned to ports 8000 through 9000. Unfortunately ports 8080 and 8443 are in that range so "hello proxy probes." Ignoring that I sit back and wait. The sensor is on a commercial ISP in the United States, so anything IoT centric should be hitting that soon enough.
No hits on 8983 yet, but something odd hits 8545. I'm not sure what that is off the top of my head. Generally the strategy is:
The request that came in looks like:
The dshield report has a comment that mateches the traffic we saw:
So thanks JB, that saves me steps 2 and 3.
Aug 3rd 2018
1 week ago