Pi wants to connect to blacklisted server

FlightAware ADS-B Flight Tracking
1

My Pi Zero with 3.7.1 piaware image installed was caught by my router for an attempt to connect to a blacklisted IP-adress, located in India. The blacklist says the IP is blocked due to attacks on SSH, but I have no details on exactly what the pi tried to do and what was blocked. All I know is that a connection attempt to this IP-number was prevented.

How do I go about finding out more what my pi is doing and if this indeed is malicious?
(I am not experienced with linux but know my way around solaris, so tips and suggestions doesn’t need to be on a beginners level)

2

There was recent thread about something similar.
Without the router actually saying the port number and protocol, it’s anybodies guess.

Most likely the server is somehow listed in the debian NTP pool.
Are you running fr24feed as well?

1 Like
3

Yes, fr24feed is on that pi too.

4

fr24feed connects to those ntp pools to synchronize time:

 1.oceania.pool.ntp.org
 1.africa.pool.ntp.org
 1.north-america.pool.ntp.org
 1.south-america.pool.ntp.org
 1.asia.pool.ntp.org
 1.europe.pool.ntp.org

Take it up with FR24 support. Most likely they will do nothing.
Connecting to the localized pools instead of just using the default pools which will give you an ntp servers close to you is stupid.
It’s also against the pool policy.
Anyway enough ranting.

I’d ignore the warning.

1 Like
5

It seems your suspicion is right. In the fr24feed log there is a NTP sync entry 5 seconds before the firewall block message

2019-08-28 11:14:26 | [time][i]Synchronizing time via NTP

The sync takes 28 seconds to go through:

2019-08-28 11:14:54 | [time][i]Time synchronized correctly, offset +0.0013 seconds, drift 0.0000 seconds/minute

so it seems very likely it was waiting for that blocked server before moving on.

So you are saying I can’t prevent this by editing /etc/ntp.conf ?

6

One would think they knew that.

And delete FR24.:wink:

7

No it’s hardcoded into FR24.

You can do this:

sudo apt install ntp

And then add the following lines to /etc/hosts

127.0.0.1	1.oceania.pool.ntp.org
127.0.0.1	1.africa.pool.ntp.org
127.0.0.1	1.north-america.pool.ntp.org
127.0.0.1	1.south-america.pool.ntp.org
127.0.0.1	1.asia.pool.ntp.org
127.0.0.1	1.europe.pool.ntp.org

It fools the computer into thinking those domains are the computer itself.
So it just talks to the locally running ntp you installed above.
(which you can configure and by default will connnect to local servers / debian pool servers)

1 Like
8

Along this same line.
My gateway will show FR24 connecting using UltraSurf VPN.

I can provide IP and Port # later if needed when I get home.

9

IP is 23.111.133.135
Port 33755

This is occuring on my Pi3B that is running VRS, OpenSky, MM2, RB, and FR24.

10

Although I am not aware of my fr24 RPI going off to blacklisted ntp servers,
I updated /etc/hosts with your suggested fix to “short circuit” the fr24 hard
coded ntp server list. I used the fr24 log file /var/log/fr24feed/fr24feed.log
to see the time delta between the lines “Synchronizing time via NTP” and “Time
synchronized correctly…” Before the update to /etc/hosts, the delta was large
and variable. After the delta is about 0 seconds.

Pre update: (“Time synchronized…” truncated for clarity)
2019-08-28 15:37:18 | [time][i]Synchronizing time via NTP
2019-08-28 15:37:34 | [time][i]Time synchronized correctly,
2019-08-28 15:47:34 | [time][i]Synchronizing time via NTP
2019-08-28 15:47:41 | [time][i]Time synchronized correctly,
2019-08-28 15:57:41 | [time][i]Synchronizing time via NTP
2019-08-28 15:58:07 | [time][i]Time synchronized correctly,
2019-08-28 16:08:07 | [time][i]Synchronizing time via NTP
2019-08-28 16:08:34 | [time][i]Time synchronized correctly,
2019-08-28 16:18:34 | [time][i]Synchronizing time via NTP
2019-08-28 16:19:16 | [time][i]Time synchronized correctly,

Update happened here.
-rw-r–r-- 1 root root 423 Aug 28 17:24 /etc/hosts

Post update:
2019-08-28 17:31:34 | [time][i]Synchronizing time via NTP
2019-08-28 17:31:34 | [time][i]Time synchronized correctly,
2019-08-28 17:41:34 | [time][i]Synchronizing time via NTP
2019-08-28 17:41:34 | [time][i]Time synchronized correctly,
2019-08-28 17:51:35 | [time][i]Synchronizing time via NTP
2019-08-28 17:51:35 | [time][i]Time synchronized correctly,
2019-08-28 18:01:35 | [time][i]Synchronizing time via NTP
2019-08-28 18:01:35 | [time][i]Time synchronized correctly,
2019-08-28 18:11:36 | [time][i]Synchronizing time via NTP
2019-08-28 18:11:36 | [time][i]Time synchronized correctly,
2019-08-28 18:21:36 | [time][i]Synchronizing time via NTP
2019-08-28 18:21:36 | [time][i]Time synchronized correctly,
2019-08-28 18:31:37 | [time][i]Synchronizing time via NTP
2019-08-28 18:31:37 | [time][i]Time synchronized correctly,
2019-08-28 18:41:37 | [time][i]Synchronizing time via NTP
2019-08-28 18:41:38 | [time][i]Time synchronized correctly,
2019-08-28 18:51:38 | [time][i]Synchronizing time via NTP
2019-08-28 18:51:38 | [time][i]Time synchronized correctly,

Thanks for your suggestion.
So far looks good without side effects on my network.

11

Well to ring alarm bells upon any and all traffic to certain IPs is kinda ridiculous anyway.

Typical snake oil product, not even providing details like port and protocol.
Information is only useful to give people the feeling “they are protected” so they’ll buy the snake oil again.

If some malicious software would already be trying to connect from your RPi to the blacklisted server, you’d already be compromised.
I suppose it’s nice to know that you have a device on the network which might be compromised, but the reliability of that detection is highly suspect.

12

Great suggestion.

Hosts file very useful.

Geoff