-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Il 27/07/2016 20:53, Farzan Doroodgar ha scritto: > You are right, after investigating a lot on this I must admit that it > is not a simple to do thing. [...]
In my opinion, one of the best option you have to gather the information you need, is "pmacct": http://pmacct.net/ You could employ PMACCT as both a Netflow PROBE and COLLECTOR, running exactly on the very same PF box. In such a way, PMACCT can record all the FLOWS of IP traffic (IPv4 and IPv6), collecting traffic statistics (bytes and packets) in both directons (inbound/outbound) and associating such flows to IP (src and dst), MAC (src and dst) and port (src and dst)...and other things (if needed) You're also free to: - - configure PMACCT so to store flow data directly in MySQL; - - configure some script to store data in TXT file for your own batch post-processing. Unfortunately there's no simple way to keep track of authenticated users associated to a "flow": that's way too much for a "standard" netfilter/iptables installation (BTW: netfilter _CAN_ be setup with rules dealing with "users" but... such "users" are, actually, UID of a process running on the system. As PF in inline mode simply act as a firewall/router --basically, working [routing/firewalling] as "root"--, it simply cannot be done). Anyway, once you have MAC and IP inside your flows, and once you have a time-reference for such a flow, than it's relatively easy to check PF LOG to see which user were using what IP at such a time. Also, if you will collect "flows" at your "internal" network side, than you'll have no problem with NAT-translations, as you'll record "internal" IPs. As for PMACCT, as I've described here: http://serverfault.com/questions/652168/monitor-network-traffic-usage-by-po rt "....just to give you some real numbers, I've succesfully used PMACCT on a server with a XEON X3350; 4GB of RAM; 4 broadcom GigaEth interfaces; nearly 70 VLANs configured on eth0 and pmacct listening on all of them; +/- 300GB of various IP traffic routed on a daily basis; PMACCT generating accounting EVERY_MINUTE, for EVERY_VLAN, for EVERY tuple (src_mac, dst_mac, src_ip, dst_ip, src_port, dst_port); +/- 60.000.000 accounting records per day. All of this, without any issue (but writing on text-files, not in MySQL). In smaller environments, anyway, there are no problems in writing directly to MySQL...." As for NAT-translation and related need to keep track of them.... another approach (an alternative to PMACCT) is described here: https://home.regit.org/2014/02/logging-connection-tracking-event-with-ulogd / However, I've not tested it.... but it looks interesting. > I need to create a new daemon monitoring NATed traffic and do a > accouting per IP/MAC and storing the results in db and join it with > internal packetfence logs to retrieve username. 1) unless you're a "kernel-hacker"... I kindly suggest you to... carefully evaluate such an option as... it's... really hard (in my opinion) ; 2) basically, what you described is very in-line with PMACCT structure (...and, believe me, despite the fact that it's not a well-known product, PMACCT is really rock-solid!) > Regarding TLS [...] As for SSL/TLS/Encryption, obviously such a traffic are not accounted in any means but.... please, consider that if you rely on "flow-like" technologies/approaches, than your traffic-analysis tools will _NOT_ check the payload of IP packets traveling allalong the FLOW-PROBE, as the "probe" will consider "only" header fields. This is way-much in-line with "privacy" laws/reqquirements (BTW: IANAL) with respect to, for example, HTTP proxies! That's all. HTH. Bye, DV P.S.: should something not be clear, please, don't hesitate to ask for details. - -- Damiano Verzulli e-mail: dami...@verzulli.it - --- possible?ok:while(!possible){open_mindedness++} - --- "Technical people tend to fall into two categories: Specialists and Generalists. The Specialist learns more and more about a narrower and narrower field, until he eventually, in the limit, knows everything about nothing. The Generalist learns less and less about a wider and wider field, until eventually he knows nothing about everything." - William Stucke - AfrISPA http://elists.isoc.org/mailman/private/pubsoft/2007-December/001935.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAleZLSUACgkQcwT9fsMT4SynrACeLbwFp54tSxLU6yVqHaxNjg4I TBEAn3yoFDMCq3GS7FpKL/yKg9vOKuBl =eKGx -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ _______________________________________________ PacketFence-users mailing list PacketFence-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/packetfence-users
