At times bettercap ARP sniffing works great and at times not at all, what would be the reason?

Question

I like to track the websites my daughter goes to in order to have some control. So I installed bettercap and setup a script to start it to sniff the HTML URLs being accessed (well, the reverse URL from the IP really).

sudo bettercap --eval 'set events.stream.time.format 2006-01-02 15:04:05;
                       set arp.spoof.targets 192.168.n.m;
                       arp.spoof on;
                       net.sniff on'

Note: the command is a single line (no new-line), I added new lines here for clarity.

The result is a large list of URLs as she hits one website or another. Especially, I see a ton of marketing websites (darn!). But at times I just see the messages:

endpoint detected as

and

end point lost

(the messages include the IP address and device name, in general).

So even though the end points are properly detected, no other data comes through.

My network looks more or less like this:

+--------+   +-------+
| Laptop |   | Phone |
+---+----+   +---+---+
    |            |
    |            |
    |            v
    |      +----------+
    +----->| WiFi Hub |
           +-----+----+
                 |            +-------------------+
                 |            | Main Server       |
                 v            |                   |
           +----------+       |   +-------------+ |
           | Switch   |<------+   | Kali Linux  | |
           +----------+       |   | (bettercap) | |
                 ^            |   | VPS         | |       +--------+
                 |            |   +-------------+ +------>| Router +----> Internet
                 |            |                   |       +--------+
                 |            +-------------------+
           +-----+-----+
           | Laptop    |
           | (Wired)   |
           +-----------+

So all the traffic from all the machines do go through the Main Server using the FORWARD capability of the Linux firewall. In other words the computers to the left are all isolated (they can still communicate between each others but not directly to the main server, the main server can connect to some of them, though). So the network is rather secure.

Since it worked before I would imagine that the script is correct, but still, there is something that makes Kali bettercap work or fail just like that. I'm not too sure what I would need to do to make it work every time I reboot without having to fiddle with it (although this time the fiddling didn't help, it's still not tracking anything).

---

For those wondering, what I can actually do is use a tool such as tcpdump to look at the packets going through the Main Server. The command accepts an expression which is a pcap filter. For example:

sudo tcpdump -i eth1 src host 192.168.100.100 | tee packets.txt

This command will record the packets in packets.txt and print them on the screen. It will include most everything that goes through 192.168.100.100 on the eth1 interface. Keep in mind that you're going to get all the packets. That's a lot. There are options to extend the filter, though, and for example only show TCP/UDP packets and not each ARP, ICMP, etc. That definitely works a lot better than the so called bettercap software. At the same time, you get swamped with packets so you really need to work on filtering the results. Especially, you'll see a bunch of repeat and IPs that do not resolve to a domain name... (many CDNs/large companies don't have names for all of their IPs).

Answer 1

To sum up the comments, you don't even need to use ARP spoofing since all of the network traffic is already passing through your server. At this point, you can passively sniff any unencrypted traffic, and may be able to determine what hosts are being contacted by using the TLS SNI value, which is unencrypted. If you want to monitor and control HTTPS traffic further, you would need to set up a TLS interception proxy and install your root CA on client machines.

If this were truly a scenario where an ARP spoof attack was needed, these attacks aren't always reliable due to their nature; mainly caching issues and conflict with legitimate ARP requests.