Have you enabled the conntrack accounting and conntrack timestamps via sysctl? On Mon, 17 Feb 2020 at 18:13, Alessandro Vesely <vesely@xxxxxxx> wrote: > > Hi, > > Only the start timestamp is NULL, the end one looks fine. I tried setting > hash_enable=0, it apparently didn't better nor worse the logging. > > > In /proc/net/nf_conntrack there is no timestamp, but port numbers seem good > (there is no port 32767). > > > What am I missing? > > Best > Ale > > On Sat 15/Feb/2020 17:03:19 +0100 Alessandro Vesely wrote: > > I've set up logging as follows, to get a history of TCP connections: > > > > # conntrack logging to MariaDB > > stack=ct1:NFCT,ip2str1:IP2STR,mysql1:MYSQL > > > > [ct1] > > accept_proto_filter=tcp # layer 4 proto of connections > > event_mask=0x00000004 # only listen to DESTROY events > > > > [mysql1] > > table="ct" > > reconnect=4 > > connect_timeout=60 > > procedure="INSERT" > > db="ulog" > > host="localhost" > > user="ulog" > > pass="*****" > > port=3306 > > > > > > It doesn't work well. For example, I get this: > > > > MariaDB [ulog]> SELECT FROM_UNIXTIME(flow_start_sec) AS start, flow_end_sec - flow_start_sec AS sec, > >> orig_ip_saddr_str AS src, orig_l4_sport AS sport, orig_ip_daddr_str, orig_l4_dport AS svc > >> FROM ct WHERE orig_ip_saddr_str = '66.110.216.209'; > > +-------+------+----------------+-------+-------------------+------+ > > | start | sec | src | sport | orig_ip_daddr_str | svc | > > +-------+------+----------------+-------+-------------------+------+ > > | NULL | NULL | 66.110.216.209 | 32767 | 62.94.243.226 | 143 | > > | NULL | NULL | 66.110.216.209 | 32767 | 62.94.243.226 | 143 | > > +-------+------+----------------+-------+-------------------+------+ > > 2 rows in set (0.00 sec) > > > > > > > > flow_start_sec and flow_end_sec are both NULL, after several hours. They seem to be non-NULL for outgoing connections and for connections coming from the internal network. Even then, they don't seem to be accurate timings. > > > > The mail log for the IP above IP is as follows (the source port is always 32767): > > > > Feb 15 12:08:07 22 north imapd: LOGIN FAILED, user=sungjtrio@xxxxxxxxxxxx, ip=[66.110.216.209], port=[41204] > > Feb 15 12:08:16 23 north imapd: Disconnected, ip=[66.110.216.209], port=[41204], time=16 > > Feb 15 12:08:47 23 north imapd: Connection, ip=[66.110.216.209], port=[45344] > > Feb 15 12:08:54 22 north imapd: LOGIN FAILED, user=sungjtrio@xxxxxxxxxxxx, ip=[66.110.216.209], port=[45344] > > Feb 15 12:09:06 23 north imapd: Disconnected, ip=[66.110.216.209], port=[45344], time=19 > > > > Disconnections are likely caused by conntrack -D -s 66.110.216.209. I'm reporting abusive login attempts at end-of-day, and I've been told to mention my server (target) address and port, 62.94.243.226:143 in this case. Since the mail log doesn't mention that data, the idea is to find it in the NFCT log based on the time and source IP. > > > > Should I be running conntrackd? > > Should I play with socket buffer/ resync timeout/ backlog_oneshot_requests/ ring_buffer_size? > > Any other hint? > > > > > > TIA > > Ale > > -- Anton Danilov.
