[SOLVED] My system is receiving 15 GB of mail (via POP) per day from "PEGATRON"

adrianmariano · 05-22-2014, 04:14 PM

My ISP notified me that I was exceeding my data allowance. Some investigation revealed that my machine is pulling down something like 15 GB of data per day.

Code:

adrian> vnstat
Database updated: Thu May 22 16:54:14 2014

   eth0 since 05/21/14

          rx:  15.68 GiB      tx:  444.62 MiB      total:  16.11 GiB

   monthly
                     rx      |     tx      |    total    |   avg. rate
     ------------------------+-------------+-------------+---------------
       May '14     15.68 GiB |  444.62 MiB |   16.11 GiB |   72.07 kbit/s
     ------------------------+-------------+-------------+---------------
     estimated     22.39 GiB |     634 MiB |   23.01 GiB |

   daily
                     rx      |     tx      |    total    |   avg. rate
     ------------------------+-------------+-------------+---------------
     yesterday      4.69 GiB |  130.50 MiB |    4.82 GiB |  467.56 kbit/s
         today     10.99 GiB |  314.12 MiB |   11.30 GiB |    1.56 Mbit/s
     ------------------------+-------------+-------------+---------------
     estimated     15.60 GiB |     445 MiB |   16.04 GiB |

I installed ntop and found that 99.8% of the traffic (16.2 GB) was identified as due to "Mail_POP". Further investigation identifies it all with a specific host:

Code:

First/Last Seen: Wed May 21 16:38:35 2014  -  Thu May 22 17:03:58 2014 [Inactive since 3 sec]
MAC Address: 70:71:BC:DD:29:17  [PEGATRON CORPORATION]
Host Location: Local (inside specified/local subnet or known network list)
Total Data Sent: 837.1 MBytes/11,990,382 Pkts/0 Retran. Pkts [0%]
Broadcast Pkts Sent: 416 Pkts
Total Data Rcvd: 31.4 GBytes/21,648,383 Pkts/0 Retran. Pkts [0%]
IP vs. Non-IP Rcvd: 0 %	/ 100%
Sent vs. Rcvd Pkts: Sent 35.6 %	/ 64.5%
Sent vs. Rcvd Data: Sent 2.5 %	/ Rcvd 97.5 %
Host Healthness: Medium Risk, Wrong network mask or bridging enabled 

Time	Tot. Traffic Sent	% Traffic Sent	Tot. Traffic Rcvd	% Traffic Rcvd
5 PM 	1.5 MBytes	0.4 %	52.5 MBytes	0.3 %
4 PM 	18.1 MBytes	4.6 %	678.8 MBytes	4.5 %
3 PM 	19.6 MBytes	4.9 %	715.4 MBytes	4.7 %
2 PM 	20.0 MBytes	5.1 %	769.6 MBytes	5.1 %
1 PM 	16.9 MBytes	4.3 %	655.7 MBytes	4.3 %
12 PM 	16.1 MBytes	4.1 %	628.4 MBytes	4.1 %
11 AM 	18.6 MBytes	4.7 %	682.5 MBytes	4.5 %
10 AM 	16.2 MBytes	4.1 %	628.5 MBytes	4.1 %
9 AM 	18.4 MBytes	4.6 %	662.2 MBytes	4.4 %
8 AM 	20.5 MBytes	5.2 %	714.6 MBytes	4.7 %
7 AM 	16.6 MBytes	4.2 %	651.6 MBytes	4.3 %

I'm not sure what to make of all this, nor what exactly I need to do. Evidently I'm infected with something. The problem started on May 7 very clearly according to my ISPs data use logs. I just re-installed Ubuntu 14.04 around April 20.

smallpond · 05-22-2014, 04:45 PM

If your receive were low and your transmit were high, I would guess you had been hacked by spammers, but your box seems like the opposite.

One possibility is that someone (Pegatron?) has a misconfigured email server that is sending to you instead of their intended target. I had that happen once and tracked it down their domainname being one character different from ours. I solved it by adding a block in iptables to drop all input from that host, and then contacting them via their whois data.

adrianmariano · 05-22-2014, 04:57 PM

Yeah, I'm not sure why you would hack someone and then *send* them tons of email.

In order to be receiving stuff by POP3 don't I have to be initiating a connection with a POP3 server, though? I'm not running such a server, as far as I know. I'm not actually observing tons of email anywhere.

Another thing I wondered about is that the host is identified by ntop as "local" and it has "Wrong network mask or bridging enabled".

Emerson · 05-22-2014, 07:24 PM

70:71:BC:DD:29:17 is a NIC made by PEGATRON, probably the NIC you have on your motherboard.
Whenever you suspect your box is compromised disconnect it from network before doing anything else.

adrianmariano · 05-22-2014, 09:03 PM

So it turns out that the problem was a legitimate mail message that couldn't be delivered because it was over a message size limit set by postfix (10 MB). Apparently the system was in a loop trying to retrieve this message from the server and (I guess?) getting 10 MB of it each time and then failing to deliver it and leaving it on the server to try again.