Closing current connections based on ip address?

i want to limit the times that a client computer can access the red network. i did this by setting a firewall rule based on ip address to block access to red network and set the days and times of day. it works.

while reading up on this, i saw that connections that are open at the time the firewall rule becomes effective each day still allow traffic to flow. net new connections are not allowed, of course.

is there a way to close all connections at a specified time (to coincide with when the firewall rule kicks in) for a given client? this would result in a hard stop to red access for everything on the given client, which is what i am ultimately after.

The only thing I would know to do.
Is a scheduled reboot after rule to stop traffic is enabled.
Block traffic at 9
Reboot at 9:05

can’t reboot the firewall. i have thought of forcing logout of the client.

An option might be to run the following command from an fcron job

/etc/rc.d/init.d/firewall restart

Just set the fcron command to run a minute or two after the firewall rule change.

I think that restarting the firewall should start all connections from fresh but I am not 100% sure. You would need to test it out and see.

If it does work then you would want to define a new user that would own a separate frcontab so that the addition is not removed in an Core Update that contains a change to fcrontab.

The following documentation page gives details on doing that.
https://www.ipfire.org/docs/pkgs/fcron

2 Likes

From my experience on another distro, established connections survived a firewall restart. I had to use the conntrack command to flush existing connections.

2 Likes

Nick - I saw the conntrack --help and I see the -F to flush the table…

Can you add the arguments you used for [table]?

[root@ipfireAPU2 ~]# conntrack --help
Command line interface for the connection tracking system. Version 1.4.7
Usage: conntrack [commands] [options]

Commands:
  -L [table] [options]		List conntrack or expectation table
  -G [table] parameters		Get conntrack or expectation
  -D [table] parameters		Delete conntrack or expectation
  -I [table] parameters		Create a conntrack or expectation
  -U [table] parameters		Update a conntrack
  -E [table] [options]		Show events
  -F [table]			    Flush table
  -C [table]			    Show counter
  -S				        Show statistics
. . .

Have a look at chapter 5 at The conntrack-tools user manual (it is short).

I did not find anything related to “conntrack command to flush existing connections”

That allows you to be selective. conntrack -F resets the whole table and is a bit brutal…

1 Like

Ahhh! (lightbulb came on!) Deleting established connection(s) makes sense!

Hi all,
it should also be possible to kill specific connections via ss if the kernel has been compiled with CONFIG_INET_DIAG_DESTROY . By checking it on IPFire via

$ grep CONFIG_INET_DIAG_DESTROY /boot/config-6.6.15-ipfire
CONFIG_INET_DIAG_DESTROY=y

it looks good and should work.

Examples:
To check which connection should be killed, netstat can be helpful e.g. →
netstat -nap | grep ESTABLISHED
with an example output for an SSH connection to IPFire

tcp        0     36 192.168.7.1:222        192.168.7.2:45512      ESTABLISHED 25541/sshd: root@pt

. To kill the SSH connection via destination IP and destination port the following command was used →
ss --kill dst 192.168.7.2 dport = 45512
possible output of ss

Netid      State      Recv-Q       Send-Q             Local Address:Port              Peer Address:Port       
tcp        ESTAB      0            0                    192.168.7.1:222             192.168.7.2:45512

Since ss is part of the iproute2 package, it is part of IPFires core system. As another idea.

Best,

Erik

2 Likes

i haven’t gotten to trying to close open connections yet because something else isn’t working right.

here is what i’m trying to do:

  • sunday through monday i want red access available to a specific machine (i tried a firewall rule based on ip address of the machine) between 8:00 am and 8:00 pm.
  • friday and saturday i want the same machine to have red access between 8:00 am and 10:30 pm.

i have tried creating a single rule that blocks red access for the ip address between 8:00 pm and 8:00 am (yes, 8 pm first until 8 am) 7 days a week. this works as expected.

because i wanted a different time on friday and saturday, i modified the rule above to be active only sunday through thursday. i then created a second rule just like the first, made it active only on friday and saturday, and changed the 8:00 pm to 10:30 pm.

what i have found is that red access is not available on saturday beginning at 8 pm. and red access is available right now (a thursday night) at 9:27 pm. not the intention at all, so i’ve obviously misconfigured something.

how do accomplish what i’m trying to do? my thought is to create the following, in this order:

  • a second rule that allows red access for the ip address on sunday through thursday between 8 am and 8 pm.
  • a third rule that allow red access for the ip address on friday and saturday between 8 am and 10:30 pm.
  • a rule the blocks red access completely, all the time, for the given ip address.

will this work? is there any easier way? once i get this working as expected, i need to do similar (but with different times of day) for a few other ip addresses, so i’m trying to keep the configuration as simple as possible.

i got my desired configuration working for limiting access during specific times on specific days, however i’m pretty sure i found a bug in ipfire.

here is what i configured (in this order, not certain the order matters, my guess is it does):

  1. rule that allows access to red for the given ip on sun - thurs at the specified times.
  2. 2nd rule the allows access to red for the given ip on fri - sat as the desired times (different than the times on rule 1).
  3. a rule the blocks all access to red from the given ip address.

i found i had to alter the 2nd rule to include sunday as well. red access was being cut off on saturday at the time specified for the first rule. i thought this might be due to time zone conversion or day of conversion. i looked at the rules being created in iptables and found the following:

-A FORWARDFW -s 192.168.110.43/32 -o red0 -m time --timestart 19:00:00 --timestop 03:00:00 --weekdays Mon,Tue,Wed,Thu,Sun --datestop 2038-01-19T03:14:07 -j ACCEPT
-A FORWARDFW -s 192.168.110.43/32 -o red0 -m time --timestart 19:00:00 --timestop 05:30:00 --weekdays Fri,Sat,Sun --datestop 2038-01-19T03:14:07 -j ACCEPT
-A FORWARDFW -s 192.168.110.43/32 -o red0 -j DROP
-A INPUTFW -s 192.168.110.43/32 -m time --timestart 19:00:00 --timestop 03:00:00 --weekdays Mon,Tue,Wed,Thu,Sun --datestop 2038-01-19T03:14:07 -j ACCEPT
-A INPUTFW -s 192.168.110.43/32 -m time --timestart 19:00:00 --timestop 05:30:00 --weekdays Fri,Sat,Sun --datestop 2038-01-19T03:14:07 -j ACCEPT

so, the times are there with the days of the week included. if you are UTC timezone, this should work just fine. also, if you are close to UTC time zone, i suspect this will work well unless you set a start or end time close to midnight. when the time conversion happens to change from the UI time zone (entry of the times, in my case PT, -7 hours) to UTC, the date/day of week appears to not be considered. the time is being converted from 10:30 pm PT to 5:30 am UTC on the same day of the week. 10:30 pm PT is actually 5:30 am UTC tomorrow (relative to PT).

where can a bug be filed for this?

https://www.ipfire.org/docs/devel/bugzilla

The IPFire People username and password credentials work for logging in to the IPFire Bugzilla.

1 Like

Is this a bug? If it is it needs to be reported to the iptables maintainers.

… but I think part of the problem is that the rules are spanning midnight, so if you are allowing from 7pm to 3am the two times are on different days. If your rule, for example, was for mon only, a --timestart 19:00:00 would mean start at 7pm, Monday but a --timestop 03:00:00 would mean stop at 3am Monday and not 3AM Tuesday. This makes it a right royal pain to use this feature, especially coupled with the UTC “feature”. Also note that it does not cut existing connections, just new ones.

When I tried something like this, I ended up scripting it and using cron to inject or delete the rules and really had to knife and fork it to cater for firewall restarts. It was not pretty.

And I don’t remember ever having to use the --datestop parameter,

2 Likes

based on the ui in ipfire that allows entering of the days/times to have a rule active, combined with the timezone translation, i feel this is a bug in ipfire. iptables is doing what it’s told to do, and correctly. it’s being told the wrong thing to do though, as pointed out by you (and me in my prior message).

i’ll add a bug to bugzilla.

1 Like

Hmm. I think rules spanning midnight UTC are going to be a nightmare to program using this approach (the iptables time module).

1 Like

having worked on a product used globally that involved filtering data elements based on time and date, it requires some extra brain power.

It sounds like you have the capability to do the work with the time and date elements. You would be very welcomed in picking up the bug when you have raised it.

The following documentation gives details of how to go about making changes and then submit the patch(es) resulting from that in the IPFire format.

https://www.ipfire.org/docs/devel/submit-patches

1 Like

i am flattered and appreciate your confidence. i’m not a developer, although i tend to dabble in some basic coding activities out of my own curiosity. if i can find the time to have a look, i will. i’m not too confident in my ability to to fix this properly or in a timely manner, though.