I am trying to use conntrack -D to delete undesirable conntrack entries. In this case those entries are connections from people trying to brute force access to my Asterisk server. The attackers keep using the same IP and source port for many attempts at UDP port 5060, which means that my rule allowing established connections takes effect before my deny rule gets a chance to drop the packet. To avoid this, I delete the connection from the connection database... except it does not work. I am trying this: # conntrack -L --src 77.247.0.0/16 to find one of the attackers, lots of lines output: udp 17 80 src=77.247.110.82 dst=10.1.0.11 sport=60733 dport=5060 src=10.1.0.11 dst=77.247.110.82 sport=5060 dport=60733 [ASSURED] mark=0 secctx=system_u:object_r:unlabeled_t:s0 use=1 udp 17 76 src=77.247.110.158 dst=10.1.0.11 sport=50606 dport=5060 src=10.1.0.11 dst=77.247.110.158 sport=5060 dport=50606 [ASSURED] mark=0 secctx=system_u:object_r:unlabeled_t:s0 use=1 udp 17 117 src=77.247.110.82 dst=10.1.0.11 sport=63151 dport=5060 src=10.1.0.11 dst=77.247.110.82 sport=5060 dport=63151 [ASSURED] mark=0 secctx=system_u:object_r:unlabeled_t:s0 use=1 udp 17 48 src=77.247.110.158 dst=10.1.0.11 sport=64488 dport=5060 src=10.1.0.11 dst=77.247.110.158 sport=5060 dport=64488 [ASSURED] mark=0 secctx=system_u:object_r:unlabeled_t:s0 use=1 udp 17 117 src=77.247.110.173 dst=10.1.0.11 sport=55607 dport=5060 src=10.1.0.11 dst=77.247.110.173 sport=5060 dport=55607 [ASSURED] mark=0 secctx=system_u:object_r:unlabeled_t:s0 use=1 udp 17 31 src=77.247.110.82 dst=10.1.0.11 sport=59984 dport=5060 src=10.1.0.11 dst=77.247.110.82 sport=5060 dport=59984 [ASSURED] mark=0 secctx=system_u:object_r:unlabeled_t:s0 use=1 udp 17 61 src=77.247.110.173 dst=10.1.0.11 sport=58433 dport=5060 src=10.1.0.11 dst=77.247.110.173 sport=5060 dport=58433 [ASSURED] mark=0 secctx=system_u:object_r:unlabeled_t:s0 use=1 udp 17 20 src=77.247.110.158 dst=10.1.0.11 sport=62983 dport=5060 src=10.1.0.11 dst=77.247.110.158 sport=5060 dport=62983 [ASSURED] mark=0 secctx=system_u:object_r:unlabeled_t:s0 use=1 udp 17 104 src=77.247.110.158 dst=10.1.0.11 sport=52180 dport=5060 src=10.1.0.11 dst=77.247.110.158 sport=5060 dport=52180 [ASSURED] mark=0 secctx=system_u:object_r:unlabeled_t:s0 use=1 udp 17 119 src=77.247.110.158 dst=10.1.0.11 sport=63844 dport=5060 src=10.1.0.11 dst=77.247.110.158 sport=5060 dport=63844 [ASSURED] mark=0 secctx=system_u:object_r:unlabeled_t:s0 use=1 udp 17 111 src=77.247.110.82 dst=10.1.0.11 sport=63181 dport=5060 src=10.1.0.11 dst=77.247.110.82 sport=5060 dport=63181 [ASSURED] mark=0 secctx=system_u:object_r:unlabeled_t:s0 use=1 udp 17 95 src=77.247.110.173 dst=10.1.0.11 sport=65104 dport=5060 src=10.1.0.11 dst=77.247.110.173 sport=5060 dport=65104 [ASSURED] mark=0 secctx=system_u:object_r:unlabeled_t:s0 use=1 udp 17 21 src=77.247.110.173 dst=10.1.0.11 sport=65441 dport=5060 src=10.1.0.11 dst=77.247.110.173 sport=5060 dport=65441 [ASSURED] mark=0 secctx=system_u:object_r:unlabeled_t:s0 use=1 conntrack v1.4.5 (conntrack-tools): 13 flow entries have been shown. # conntrack -D --src 77.247.0.0/16 conntrack v1.4.5 (conntrack-tools): Operation failed: such conntrack doesn't exist Then I look at one specific connection: # conntrack -G --src 77.247.110.173 --proto udp --dst 10.1.0.11 --sport 65441 --dport 5060 udp 17 86 src=77.247.110.173 dst=10.1.0.11 sport=65441 dport=5060 src=10.1.0.11 dst=77.247.110.173 sport=5060 dport=65441 [ASSURED] mark=0 secctx=system_u:object_r:unlabeled_t:s0 use=2 conntrack v1.4.5 (conntrack-tools): 1 flow entries have been shown. And finally killing that specific connection: # conntrack -D --src 77.247.110.173 --proto udp --dst 10.1.0.11 --sport 65441 --dport 5060 conntrack v1.4.5 (conntrack-tools): Operation failed: such conntrack doesn't exist I reported this to the Fedora bugzilla as https://bugzilla.redhat.com/show_bug.cgi?id=1721473 I have tried these kernels (and newer, if it matters): kernel-5.0.9-301.fc30.x86_64 kernel-5.1.7-300.fc30.x86_64 kernel-5.1.9-300.fc30.x86_64 I would be very grateful for any ideas or hints about what I am doing wrong. Thank you! Benny Lyne Amorsen
