Hive sensor showing up in wrong geo in maps

[0xJoeMartin]

I am new to using tpot and I have a distributed deployment with honeypots in several geos. The latest is in Singapore but, on the map views it is showing up as being in (or close to) Seattle, WA.

From the install logs I can see that it correctly set the LAT/LON for "MY_EXTIP" (IPs and UUIDs redacted):

Trying: dig +short myip.opendns.com @resolver4.opendns.com
[MAIN]
ip = xxx.xxx.xxx.xxx
HONEY_UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
xxxx-xxxx
MY_EXTIP=xxx.xxx.xxx.xxx
MY_EXTIP_LAT=1.2897
MY_EXTIP_LONG=103.8501
MY_INTIP=xxx.xxx.xxx.xxx
MY_HOSTNAME=xxxxxxxxxxxxx

Any ideas?

[t3chn0m4g3]

The animated T-Pot attack map (outside ELK) does not support distributed geo locs and will always show a local view (where the HIVE is running), that is what the Live Attack Map in ELK is for which does support a distributed view.
Please check the logs in Discover mode if LAT and LONG are correctly submitted for the source and destination (that is the basis for the geo coords on the dashboard).

[0xJoeMartin]

Ya. So geo lat/lon definitely not correct in the ELK logs.
....
"geoip_ext": {
"country_code2": "US",
"location": {
"lat": 47.6348,
"lon": -122.3451
},
"longitude": -122.3451,
"timezone": "America/Los_Angeles",
"dma_code": 819,
"ip": "xxx.xxx.xxx.xxx",
"country_code3": "US",
"continent_code": "NA",
"postal_code": "98109",
"latitude": 47.6348,
"country_name": "United States",
"region_name": "Washington",
"city_name": "Seattle",
"region_code": "WA"
},....

So I assume this is coming from the geo-ip filter in the logstash pipeline. But every other geoip DB that I look at shows this correctly as being in Singapore.

LOCATION
City Singapore
Postal code 18
Country Singapore (SG)
Continent Asia (AS)
Coordinates 1.3036 (lat) / 103.8554 (long)

[t3chn0m4g3]

Only the T-Pot attack map will work with the coordinates from lat / lon of elk_environement while logstash will base the geo coordinates from the associated src / dest IP address. Either the IP address T-Pot acquires during start is not the one from your Singapore location (proxied maybe) or as you mentioned Logstash is performing a faulty translation based on its database. Unfortunately in both cases there is nothing really I can do about it.

[t3chn0m4g3]

Fix is on the way, #1313