There are literally so many different ways to combat these things, it could take an entire forum to explain them. That said, many viable solutions have been brought forth in this thread, so if anyone is still having a problem, feel free to read up and take to heart one of the solutions provided and put some skin in the game. There are alot of smart folk here who are more than willing to guide in any way possible.
I like the idea suggested by Jranderson777 and will be looking into that.
I’ve found this every minute in my logs. Turned off IPv6 and then get it on IPv4 - anything to worry about??
::1 localhost - [04/Jun/2020:09:16:21 +0100] “GET /dump1090-fa/data/stats.json HTTP/1.1” 200 3689 “-” “Python-urllib/2.7”
::1 localhost - [04/Jun/2020:09:16:21 +0100] “GET /skyaware978/data/receiver.json HTTP/1.1” 404 341 “-” “Python-urllib/2.7”
::1 localhost - [04/Jun/2020:09:16:21 +0100] “GET /dump1090-fa/data/receiver.json HTTP/1.1” 200 89 “-” “Python-urllib/2.7”
::1 localhost - [04/Jun/2020:09:16:21 +0100] “GET /dump1090-fa/data/aircraft.json HTTP/1.1” 200 15604 “-” “Python-urllib/2.7”
::1 localhost - [04/Jun/2020:09:17:21 +0100] “GET /dump1090-fa/data/stats.json HTTP/1.1” 200 3691 “-” “Python-urllib/2.7”
::1 localhost - [04/Jun/2020:09:17:21 +0100] “GET /skyaware978/data/receiver.json HTTP/1.1” 404 341 “-” “Python-urllib/2.7”
::1 localhost - [04/Jun/2020:09:17:21 +0100] “GET /dump1090-fa/data/receiver.json HTTP/1.1” 200 89 “-” “Python-urllib/2.7”
::1 localhost - [04/Jun/2020:09:17:21 +0100] “GET /dump1090-fa/data/aircraft.json HTTP/1.1” 200 16187 “-” “Python-urllib/2.7”
127.0.0.1 localhost - [04/Jun/2020:09:18:21 +0100] “GET /dump1090-fa/data/stats.json HTTP/1.1” 200 3689 “-” “Python-urllib/2.7”
127.0.0.1 localhost - [04/Jun/2020:09:18:21 +0100] “GET /skyaware978/data/receiver.json HTTP/1.1” 404 341 “-” “Python-urllib/2.7”
127.0.0.1 localhost - [04/Jun/2020:09:18:21 +0100] “GET /dump1090-fa/data/receiver.json HTTP/1.1” 200 89 “-” “Python-urllib/2.7”
127.0.0.1 localhost - [04/Jun/2020:09:18:21 +0100] “GET /dump1090-fa/data/aircraft.json HTTP/1.1” 200 15394 “-” “Python-urllib/2.7”
127.0.0.1 localhost - [04/Jun/2020:09:19:20 +0100] “GET /skyaware978/data/receiver.json HTTP/1.1” 404 341 “-” “Python-urllib/2.7”
127.0.0.1 localhost - [04/Jun/2020:09:19:20 +0100] “GET /dump1090-fa/data/stats.json HTTP/1.1” 200 3690 “-” “Python-urllib/2.7”
127.0.0.1 localhost - [04/Jun/2020:09:19:21 +0100] “GET /dump1090-fa/data/receiver.json HTTP/1.1” 200 89 “-” “Python-urllib/2.7”
127.0.0.1 localhost - [04/Jun/2020:09:19:21 +0100] “GET /dump1090-fa/data/aircraft.json HTTP/1.1” 200 15316 “-” “Python-urllib/2.7”
HTTP 200 response means “ok”
HTTP 404 response means “not found”. Are you operating a 978 feed as well?
It’s from localhost; you’re probably running stats graphs? That’s how it collects the stats.
1 Like
Foxhunter,
No, not running 978 as I’m in UK 
obj,
Thanks, makes perfect sense now, but was intrigued why localhost was requesting data.
A bit related - I’ve just installed PeerBlock on my VRS server and have imported an IP block list which blocks countries that really should have no interest in my feed and where I’ve noticed people connecting from and only grabbing the .json file.
And another reply to this as I’ve been thinking about this while not being able to sleep.
I’m testing this on a spare Pi 4 at the moment.
I’ve installed ufw (uncomplicated firewall), enabled it and I’m using a very basic script to add a shedload of CIDR formatted ranges that I downloaded from here. Of course, the first time I installed and enabled it, I forgot to allow ssh through so I had to start again. Oops.
ufw takes a while to respond to each line of the script which means it’ll take many hours to add the full list.
By default, ufw blocks incoming traffic so I’ve needed to enable that for the ports that I’m using (in my main receiver, that’s 80 and a handful of others.
Due to the amount of time this is taking to add the block rules, I’m not sure if I’m keen to install this on a live Pi. It looks like it’s taking just over a second per line and at over 100,000 lines, that’s well over a day.
I suspect that iptables is going to be somewhat unhappy about a filter table with 100k entries
1 Like
Yup, that’s why I’m trying it on a spare Pi first.
I think the ipset might work better for big sets of IP:
I am trying to do that myself, but I don’t know how to create the script.
I wonder if this this is a good start:
I use fail2ban on all my remote servers and it works a charm - may be a worthwhile cause for those who have exposed machines - 1000 ways to skin a cat:
1 Like
Make sure to disable extensive logging if used on a Raspberry with SDCard
Friend of mine killed it because of excessive write access.
Very valid point, I didn’t think of that for Pi use - but then again I always use log2ram on most of my Pi setups to eliminate that issue all together. But… stock out of the box installs, the extra logging will be a concern. Glad you mentioned it.
1 Like
Doesn’t that just load up iptables?
Experiment with ufw was a fail, it crashed after a few hours and I couldn’t log back in again. In fact, I couldn’t even ping the Pi so I crossed that option off the list.
I’m probably more exposed than the average person because I have a number of ‘things’ open to the network to make them accessible. Here’s a very small sample of the blocked log from PeerBlock earlier on my VRS box.
That’s not to say that these are all trying to leech my VRS data but these are all the attempts to connect to me on port 80 as that’s the only port I have forwarded through my router to my VRS box. I have that mapped to port 747 as that’s where VRS serves to.
1 Like
I’ve never messed with ufw, but I just learned the hard way to make sure you whitelist your own IP’s if working on a remote setup or you’ll be making a drive you don’t want to make. Luckily I had rescue mode available (I failed to whitelist my own IP in fail2ban) or it would have been a very long drive across the Atlantic where one of my servers reside…LOL
Funny, I exposed myself as well 
and have found after a long while, Alibaba server IP’s are scanning me approx 6 times every 10 seconds gathering data from a large swath of 47.x IP addresses. Closed firewall to outside and days later, they’re still knocking. As my traffic is behind an NGINX rev proxy, they’re not just stumbling on it. It’s targeted. Nice to see I’m not the only one with an Alibaba issue.
1 Like
Now that FA offers Skyaware Anywhere, there should be no need to expose your PiAware to the internet nor proxy it from another webserver, if all you want to display is the a/c traffic. I have shut down the proxy I had from my website to my PiAware and replaced it with a link to ADSBexchange Anywhere (their equivalent to Skyaware Anywhere.) Either should work fine.
1 Like
If it’s about the flights only you could also use Flightradar24 filter options where you can limit the traffic to a specific receiver (T-xxxx). This even works without having an FR24 account.
I just went trough the hoops described here, to block certain countries:
How to Block IPs from Countries using Iptables Geoip Addons (linoxide.com)
I first made the mistake to use the ! argument (“not”) to ban everything not equal to US IP. Well that worked so good that it blocked my local IP connection too (PuTTY lost connection to 192.168.1.xxx)! Ooops! Had to go to the laptop and manually clear the IP tables lists, to start fresh.
Then I just added a few countries to the blocked list (instead of “not” operator) but now I cannot test it. Probably works… IDK.
LE: I have tested it and seems to work. Added NL as DROP country and logged from a free VPN with NL IP address and I could not reach my local page.
Then I changed the rule to allow NL and DROP the other “hacky” countries…
1 Like