shadow / tornettools

A tool to generate realistic private Tor network models, run them in Shadow, and analyze the results.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Traffic destined to unknown host

marcosimioni opened this issue · comments

While running a number of simulations, all generated via tornettools and mostly with scale 0.001, I have noticed in my logfiles the following:

1- traffic destined to addresses that do not exist, on SMTP port:

04:53:56.171433 [worker-63] 08:08:10.923397000 [WARN] [relay2exit:173.244.209.5] [socket.c:812] [syscallhandler_connect] attempting to connect to address '0.26.218.174:25' for which no host exists
04:53:56.189871 [worker-30] 08:08:10.964678000 [WARN] [relay1exitguard:192.42.116.25] [socket.c:812] [syscallhandler_connect] attempting to connect to address '0.217.161.2:25' for which no host exists
04:54:14.054405 [worker-63] 08:08:41.747397000 [WARN] [relay2exit:173.244.209.5] [socket.c:812] [syscallhandler_connect] attempting to connect to address '0.34.211.176:25' for which no host exists
04:54:14.165074 [worker-30] 08:08:42.013158000 [WARN] [relay1exitguard:192.42.116.25] [socket.c:812] [syscallhandler_connect] attempting to connect to address '0.69.50.124:25' for which no host exists
04:54:14.178831 [worker-63] 08:08:42.066397000 [WARN] [relay2exit:173.244.209.5] [socket.c:812] [syscallhandler_connect] attempting to connect to address '0.15.255.28:25' for which no host exists
04:54:14.208260 [worker-30] 08:08:42.124870000 [WARN] [relay1exitguard:192.42.116.25] [socket.c:812] [syscallhandler_connect] attempting to connect to address '0.49.51.192:25' for which no host exists
04:54:14.217769 [worker-30] 08:08:42.152870000 [WARN] [relay1exitguard:192.42.116.25] [socket.c:812] [syscallhandler_connect] attempting to connect to address '0.252.75.78:25' for which no host exists

2- unsupported socket

04:55:40.387151 [worker-15] 08:11:19.098723000 [WARN] [server3:11.0.0.66] [socket.c:1211] [syscallhandler_socket] unsupported socket domain "1", we only support AF_INET
04:55:42.437866 [worker-27] 08:11:22.788000000 [WARN] [server1:11.0.0.63] [socket.c:1211] [syscallhandler_socket] unsupported socket domain "1", we only support AF_INET
04:55:42.492532 [worker-59] 08:11:22.917114000 [WARN] [server2:11.0.0.65] [socket.c:1211] [syscallhandler_socket] unsupported socket domain "1", we only support AF_INET
04:55:46.101605 [worker-73] 08:11:29.882831000 [WARN] [server4:11.0.0.67] [socket.c:1211] [syscallhandler_socket] unsupported socket domain "1", we only support AF_INET
04:55:47.071638 [worker-54] 08:11:31.685506000 [WARN] [server10:11.0.0.64] [socket.c:1211] [syscallhandler_socket] unsupported socket domain "1", we only support AF_INET

Is this normal?
In relation to (1), I would have thought that all the traffic is carefully crafted by tgen so that it's directed to other hosts of the network, and not to unknown hosts (and on port 25).
In relation to (2), I don't see what application might want to try and open an AF_UNIX socket. I think there's only tgen on those servers if I'm not mistaken.

Let me know if you need more info and how I can dig that up.

For (1):

What changes have you made to tornettools or the configuration files? The simulations run for I think 60 simulated minutes by default, but it looks like yours is at over 8 hours?

But yeah something's weird about those addresses. It's not just tgen that makes connections, but tor relays/clients also need to make connections, and IP addresses for tor hosts are set by shadow (the shadow config currently only allows you to set an IP hint). But these addresses starting with 0 aren't valid, and I'm not sure why it's saying port 25. I think we'll need a reproducible example to be able to look more into this, and I don't see this in any of my simulations.

For (2):

This is normal. Tor creates a unix socket and shadow doesn't yet support unix sockets.

For (1):

What changes have you made to tornettools or the configuration files? The simulations run for I think 60 simulated minutes by default, but it looks like yours is at over 8 hours?

I was running a 24h long simulation with a bunch of hiddenservices that stop at different times.
I'll try to reproduce with a simple, minimal configuration that I'll share with you.

For (2):

This is normal. Tor creates a unix socket and shadow doesn't yet support unix sockets.

Fair enough, but on those hosts server1 server2 etc. there is no Tor process running, they are simple tgen servers. Same here, I'll share a minimal configuration hopefully soon.

Thanks for your comments.

@stevenengler both issues can be reproduced with configs that contain multiple hiddenservices. I could not however reproduce with the minimal Tor config shipped with shadow, but I can definitely reproduce consistently with configs generated via #5.

I don't see anything wrong with the config, so I think these are genuinely shadow issues (and in that case, I guess we should probably close this issue and open one over there).

My environment:

shadow --show-build-info
Shadow v2.0.0-pre.4-20-gb9c8b840 2021-07-29--13:56:05 running GLib v2.56.4 and IGraph v0.7.1
Shadow was built from branch main on 2021-07-31--10:23:17 in Release mode with compile options: -ggdb;-fno-omit-frame-pointer;-Wreturn-type;-Wswitch;-O3 and link options: -Wl,--no-as-needed
For more information, visit https://shadow.github.io or https://github.com/shadow

tornettools --version
2021-07-31 17:38:51 1627749531.048351 [tornettools] [INFO] Logging system initialized! Logging events to stdout
2021-07-31 17:38:51 1627749531.048475 [tornettools] [INFO] tornettools version 1.1.0

uname -a
Linux ***** 4.15.0-137-generic #141-Ubuntu SMP Fri Feb 19 13:46:27 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

I'm on commit 8d461184e31f37df79dfae947edb46e7d98e23a8 with tornettools (please note the PR is now rebased and aligned with master) and on b9c8b840d2a57a5e76ec9f45db5af571fdfac814 with shadow.

Attaching my shadow.config here, but you probably need to generate yours unless you want me to attach the whole simulation folder (but that's pretty big):

shadow.config.yaml.tar.gz

From shadow.log, I can still see these:

00:32:57.313285 [worker-117] 00:15:54.607347000 [WARN] [relay2exit:83.97.20.101] [socket.c:814] [syscallhandler_connect] attempting to connect to address '0.185.201.194:25' for which no host exists
00:32:57.539441 [worker-117] 00:15:54.687575000 [WARN] [relay2exit:83.97.20.101] [socket.c:814] [syscallhandler_connect] attempting to connect to address '0.70.174.172:25' for which no host exists
00:32:59.186114 [worker-3] 00:15:55.199632000 [WARN] [relay1exitguard:185.220.101.212] [socket.c:814] [syscallhandler_connect] attempting to connect to address '0.37.162.70:25' for which no host exists
00:36:04.168582 [worker-117] 00:16:56.915843000 [WARN] [relay2exit:83.97.20.101] [socket.c:814] [syscallhandler_connect] attempting to connect to address '0.192.174.76:25' for which no host exists
00:37:38.483713 [worker-3] 00:17:28.116315000 [WARN] [relay1exitguard:185.220.101.212] [socket.c:814] [syscallhandler_connect] attempting to connect to address '0.245.173.10:25' for which no host exists
00:39:08.479155 [worker-3] 00:17:58.574409000 [WARN] [relay1exitguard:185.220.101.212] [socket.c:814] [syscallhandler_connect] attempting to connect to address '0.204.72.254:25' for which no host exists
00:39:08.931518 [worker-3] 00:17:58.727000000 [WARN] [relay1exitguard:185.220.101.212] [socket.c:814] [syscallhandler_connect] attempting to connect to address '0.111.230.24:25' for which no host exists
00:39:09.153363 [worker-3] 00:17:58.810772000 [WARN] [relay1exitguard:185.220.101.212] [socket.c:814] [syscallhandler_connect] attempting to connect to address '0.99.15.66:25' for which no host exists
00:39:10.006346 [worker-117] 00:17:59.138843000 [WARN] [relay2exit:83.97.20.101] [socket.c:814] [syscallhandler_connect] attempting to connect to address '0.212.103.50:25' for which no host exists
00:39:10.227390 [worker-3] 00:17:59.225315000 [WARN] [relay1exitguard:185.220.101.212] [socket.c:814] [syscallhandler_connect] attempting to connect to address '0.126.227.244:25' for which no host exists

but also these:

00:01:25.812569 [worker-31] 00:05:01.245433000 [WARN] [server1:11.0.0.107] [socket.c:1212] [syscallhandler_socket] unsupported socket domain "1", we only support AF_INET
00:01:25.812600 [worker-31] 00:05:01.245433000 [WARN] [server1:11.0.0.107] [socket.c:1212] [syscallhandler_socket] unsupported socket domain "1", we only support AF_INET
00:01:25.949116 [worker-59] 00:05:01.409482000 [WARN] [server2:11.0.0.108] [socket.c:1212] [syscallhandler_socket] unsupported socket domain "1", we only support AF_INET
00:01:25.949148 [worker-59] 00:05:01.409482000 [WARN] [server2:11.0.0.108] [socket.c:1212] [syscallhandler_socket] unsupported socket domain "1", we only support AF_INET
00:01:25.976461 [worker-49] 00:05:01.447447000 [WARN] [server3:11.0.0.109] [socket.c:1212] [syscallhandler_socket] unsupported socket domain "1", we only support AF_INET
00:01:25.976526 [worker-49] 00:05:01.447447000 [WARN] [server3:11.0.0.109] [socket.c:1212] [syscallhandler_socket] unsupported socket domain "1", we only support AF_INET
00:01:29.238716 [worker-10] 00:05:04.488639007 [WARN] [server5:11.0.0.111] [socket.c:1212] [syscallhandler_socket] unsupported socket domain "1", we only support AF_INET
00:01:29.238747 [worker-10] 00:05:04.488639007 [WARN] [server5:11.0.0.111] [socket.c:1212] [syscallhandler_socket] unsupported socket domain "1", we only support AF_INET
00:01:50.622608 [worker-101] 00:05:20.254542000 [WARN] [server4:11.0.0.110] [socket.c:1212] [syscallhandler_socket] unsupported socket domain "1", we only support AF_INET
00:01:50.622642 [worker-101] 00:05:20.254542000 [WARN] [server4:11.0.0.110] [socket.c:1212] [syscallhandler_socket] unsupported socket domain "1", we only support AF_INET

and I can't explain especially these last ones, given that these servers don't run Tor but only TGen as you can see.

For (2):
This is normal. Tor creates a unix socket and shadow doesn't yet support unix sockets.

Fair enough, but on those hosts server1 server2 etc. there is no Tor process running, they are simple tgen servers. Same here, I'll share a minimal configuration hopefully soon.

@sporksmith mentioned what seems like the cause in shadow/shadow#1620:

In particular, tgen calls getnameinfo. This currently isn't intercepted, and the libc implementation tries to open an AF_UNIX socket to the nscd daemon.