My firewall has few very ports opened. Unsolicited visitors to these ports are logged and banned. Unsolicited visitors to other ports where I don't have a service running are silently dropped. It's not unusual to log millions of such silently dropped packets in a typical month. For example, in the recent period of three months, I had close to three millions such packets i.e. >30,000 packets per day. For a long time, I considered it as normal activity because everyone knows Internet is nasty, right? Not quite.
I have Transmission running as a service on my AP (RT-AC56U). On rare occasions I submit magnet links from Safari with help of this browser extension or upload torrent files from command line using Transmission's RPC. Transmission will work on the downloads from there. I actually don't need such convenience as I seldomly use. I set it up this way because my AP has very light workload and I unfortunately didn't see the downside.
Transmission as honeypot
A torrent file contains a list of tracker IPs. From there, a client gets peer IPs which carry the resource for download. In addition, a client uses distributed hash table (DHT) protocol to exchange with peers for more IPs that carry the desirable resource for download. Transmission by default uses UDP port 51413 for DHT. My setup closes the port (for ingress traffic) when no work in its queue and open the port when there is new submission of work. All done through NAT-PMP and event scripts in Transmission. So my firewall blocks ingress traffic to this port when Transmission is idle. All good here.
Now the part that surprised me. When Transmission has nothing in its queue, it will still initiate egress traffic from port 51413 to peers. Without the very first tracker, how Transmission gets an initial list of peer IPs to talk to? I have no idea. I don't know enough about the DHT protocol. But it's evident that a DHT client constantly exchanges with peers for seeking more peers. In the event a torrent is submitted, it gets started to work with full speed right away.
It's the DHT mechanism that solicits peers to respond. Some of these peers are malicious hosts that show up in one or more compiled lists of malicious IPs such as the emerging thread list. We can't rule out some hosts belong to innocent users who are infected by malware. More than likely many of the peers are truly hostile hosts who collect IPs and exploit potential weakness in their system.
A new firewall rule for egress traffic
Realising the issue, I could shut down Transmission, and launch only when needed. Then I would lose the minute convenience of being always-on. I chose to let it always-on but introduced two new firewall rules on RT-AC56U where Transmission runs:
iptables -I OUTPUT -p udp --sport 51413 -j REJECT ip6tables -I OUTPUT -p udp --sport 51413 -j REJECT
Alternatively I could add similar rules to my router's firewall. I found it's cleaner to do it at the source of trouble. Once a torrent is submitted to Transmission, the firewall rule has to be lifted. Then put it back when no more torrents to work on. Transmission has events (aka hooks to calling scripts) defined for addition and completion of a torrent. These event driven scripts are convenient places to operate the firewall rule. I already have been using the event scripts to open the DHT port for ingress traffic.
An interesting tidbit. With the egress traffic blocked on UDP port 51413, I launch a fresh session of Transmission. It still attempts to connect to peers, and some of those are classified malicious. Since the packets can't go out and no responses talk back, Transmission eventually quiets down and stops its attempts. It's roughly about 100 trials on IPv4 and IPv6 each. Like a cancer, it's successfully suppressed and contained!
With the firewall rules on egress traffic in place, ingress packets going into default drop reduces by a factor of 10! Now on an average day, I get about 3000 such packets compared to >30,000 packets before. About one third or 1000 exist in one or more lists of malicious IP. Lesson learned.