On 9/13/21 18:47, MRob wrote: > While you probably can't recover such information for past events, >> going forward, iptables can help you figure this out. Putting an >> IPtables >> rule in the OUTPUT table prior to ACCEPTing the packets can help, e.g.: >> >> iptables -A OUTPUT -p tcp -m owner --uid-owner nginx -j ACCEPT OUTPUT and "-m owner" are only going to work for outgoing connections, initiated by nginx, which probably isn't much for most systems that aren't reverse proxies. Most of the time, if you want iptables to track the amount of traffic for a specific service, you'll need one or more rules inserted at the beginning of the INPUT chain, before the typical first rule that allows RELATED and ESTABLISHED packets. You could have one rule that allows all traffic to the service port (a stateless rule), or you could have one rule that allows ESTABLISHED traffic to the service port and one that allows NEW,UNTRACKED traffic to the port (stateful rules) > That is nice solution! Why do you add a new output rule rather you can > look at the existing port rule: > > # iptables -v -L | grep https > xxx yyy ACCEPT tcp -- any any anywhere anywhere > tcp dpt:https ctstate NEW,UNTRACKED > > xxx is number packets, yyy is number bytes. If adding OUTPUT rule, > what is gained? Because the rule you're looking at only matches NEW and UNTRACKED packets, so it's usually only a record of the TCP SYN packets that initiated connections. If you want a byte count of the traffic for that service, this rule won't provide that. The nginx logs are the most detailed and usually the most useful record of traffic used, but accounting through iptables is also an option. Though, if you're interested in the sort of less detailed logs that you'll get from iptables, then I'd suggest what you want might be NetFlow data: https://www.linuxnetflow.com/