#1 iptables compliance

Closed
opened 2 years ago by theonlydoo · 2 comments

hi there,

Great initiative. Quick question tho : why leave iptables out of the project scope? Is it a planned feature or a design choice?

(based on

nftables if IP address bans are to be managed; here)

hi there, Great initiative. Quick question tho : why leave iptables out of the project scope? Is it a planned feature or a design choice? (based on > nftables if IP address bans are to be managed; [here](https://yalis.fr/git/yves/pyruse/src/branch/master/doc/install.md))
yves commented 2 years ago
Owner

Hi theonlydoo,

Thanks for your interest in this software. The reason for leaving out iptables in favour of nftables is twofold:

  • First, nftables is the “next generation”, and with this whole project (of which Pyruse is only a part), I strive to stick to modern solutions, leaving out software for which there are newer and “better” (in my eye) alternatives.
  • Second and not least, nftables includes the ability to handle timeouts, an ability that iptables lacks to my —admittedly limited— knowledge. Indeed, you may have noticed that the Pyruse software is entirely “passive”, or rather reactive; for instance, it does not include a scheduler, and is thus poorly equipped to deal with clock-based events.

That said, there are several ways for including iptables support in Pyruse; here are a few:

  • The simplest way is probably to rely on the system’s scheduler (atd, or even better, systemd) to manage the timeouts.
  • Or Pyruse could include its own scheduler, that would run in a separate thread.
  • There might also be a solution using the ipset extension in conjunction with ConnTrack’s timeout policies (but I know next to nothing on this topic)…

Either way would probably be rather easy to implement, and I’d be willing to implement the first method, if you think it is useful. Cheers,

Hi theonlydoo, Thanks for your interest in this software. The reason for leaving out iptables in favour of nftables is twofold: * First, nftables is the “next generation”, and with this whole project (of which Pyruse is only a part), I strive to stick to modern solutions, leaving out software for which there are newer and “better” (in my eye) alternatives. * Second and not least, nftables includes the ability to handle timeouts, an ability that iptables lacks to my —admittedly limited— knowledge. Indeed, you may have noticed that the Pyruse software is entirely “passive”, or rather reactive; for instance, it does not include a scheduler, and is thus poorly equipped to deal with clock-based events. That said, there are several ways for including iptables support in Pyruse; here are a few: * The simplest way is probably to rely on the system’s scheduler (atd, or even better, systemd) to manage the timeouts. * Or Pyruse could include its own scheduler, that would run in a separate thread. * There might also be a solution using the [ipset](http://ipset.netfilter.org/iptables-extensions.man.html) extension in conjunction with ConnTrack’s timeout policies (but I know next to nothing on this topic)… Either way would probably be rather easy to implement, and I’d be willing to implement the first method, if you think it is useful. Cheers,
yves referenced this issue from a commit 2 years ago
yves commented 2 years ago
Owner

It is the third solution after all, as this solution benefits from automatic timeouts, the same way nftables does. Since I do not use iptables/ipset myself, I’d be grateful if someone could report back to me if the module works or not!

It is the third solution after all, as this solution benefits from automatic timeouts, the same way nftables does. Since I do not use iptables/ipset myself, I’d be grateful if someone could report back to me if the module works _or not_!
Sign in to join this conversation.
No Label
No Milestone
No Assignees
2 Participants
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
Cancel
Save
There is no content yet.