Hi Community,
I don’t know about you, but as an ISP we’ve always faced the problem of crazy DHCP clients (v4 and v6) flooding our servers. While at Quickline we have a DHCP server with anti-flood mechanisms it might not the case for everyone.
This is why I wrote DHCP Protect. DHCP Protect works with the userspace API of Netfilter (iptables/ip6tables) and will treat each DHCP(v4/v6) packet and decide if it should be forwarded or not.
Don’t worry, iptables can be configured in a way that if the program is not working, it will ACCEPT the packets by default.
There are no packages available, but don’t be scared, it’s really simple to install and it will do all the systemd stuff for you! After make install it will already be running (you can also make uninstall which will delete everything and remove it from systemd).
git clone https://git.home.spale.com/dhcp_protect.git cd dhcp_protect sudo apt-get install build-essential uthash-dev libnetfilter-queue-dev make all sudo make install
That’s it.
And then you need the iptables/ip6tables rule:
iptables -A INPUT -p udp -m udp --dport 67 -j NFQUEUE --queue-num 67 --queue-bypass ip6tables -A INPUT -p udp -m udp --dport 547 -j NFQUEUE --queue-num 67 --queue-bypass
(SAME queue number! the program can treat v4/v6 at the same time)
The program will log to syslog when it blacklists.
I’ve tested this with 10kpps and the CPU load of the program was about 4-6% on one core (AMD Ryzen 7 2700X).
There’s also a flooding perl client in the repository to test the performance. It can do pseudo DHCPv4/DHCPv6, but since it’s pseudo, don’t use the perftest.pl again a real DHCP server.
More information in the README -> https://git.home.spale.com/public/dhcp_protect
I’d be glad on feedback! It is useful? what additional features would you like to see?
Thanks for reading See you at Swing#36
Pascal
I just realised there’s a error in the git path:
it should be https://git.home.spale.com/public/dhcp_protect.git
Sorry about that. Pascal
This is why I wrote DHCP Protect. DHCP Protect works with the userspace API of Netfilter (iptables/ip6tables) and will treat each DHCP(v4/v6) packet and decide if it should be forwarded or not.
Don’t worry, iptables can be configured in a way that if the program is not working, it will ACCEPT the packets by default.
In case anyone is not familiar with userspace filters, here is a good overview of how nftables works: https://www.slideshare.net/azilian/nftables-the-evolution-of-linux-firewall (I found something even better a few years ago, but I lost the link...)
There are no packages available, but don’t be scared, it’s really simple to install and it will do all the systemd stuff for you! After make install it will already be running (you can also make uninstall which will delete everything and remove it from systemd).
Your Gitea instance doesn't seem to like this link when accessed from a web browser. This works better: https://git.home.spale.com/public/dhcp_protect Perhaps you should even put the project on a public collaboration platform to allow for easy pull/merge requests. ;)
Anyway, thanks for sharing!
Good evening,
Gregor Riepl onitake@gmail.com writes:
[...] you should even put the project on a public collaboration platform to allow for easy pull/merge requests. ;)
Gregor, if I understand you correctly, you are implicitly saying "please put your stuff on one of the big sites like github/gitlab/bitbucket".
I personally think that this is the wrong direction to move, as it makes the Internet more dependent on a few entities. That makes it less robust, as we have seen in the censorship case at github related to nationality.
Instead I recommend to decentralise and actually provide your code from your own system.
I understand your point that it should be easy to contribute, but maybe it is a more sustainable way to fire up your own git service and have your code pulled in from your machine, preferable via IPv6?
Just my 5 Rappen,
Nico
-- Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch
Gregor, if I understand you correctly, you are implicitly saying "please put your stuff on one of the big sites like github/gitlab/bitbucket".
I personally think that this is the wrong direction to move, as it makes the Internet more dependent on a few entities. That makes it less robust, as we have seen in the censorship case at github related to nationality.
IMHO, this does not apply to Git repositories. It is very easy to leave public forks in several places, and there are even ways to automate pulling from one repository to the other.
Private Git hosting has its merits, but it makes it more difficult to send patches or improvements. There are ways around that of course (good example: the Linux kernel), but they rely on a lot more effort than is usually necessary for a small open-source project.
Of course, it is everybody's own choice to not use public collaboration platforms, but there is also not much harm in doing so. Should one of them shut down, crash & burn, or change their terms of service, there are always other ways to share repositories.
This is a very different matter than social networks that rely on proprietary protocols and infrastructure.
I understand your point that it should be easy to contribute, but maybe it is a more sustainable way to fire up your own git service and have your code pulled in from your machine, preferable via IPv6?
That sound like a tremendous amount of effort in coordination and setup compared to the benefit and will probably put off 99% of all potential contributors... Well, notwithstanding everybody on this mailing list, of course. ;)
On 2019-10-30 22:09, Gregor Riepl wrote:
Gregor, if I understand you correctly, you are implicitly saying "please put your stuff on one of the big sites like github/gitlab/bitbucket".
I personally think that this is the wrong direction to move, as it makes the Internet more dependent on a few entities. That makes it less robust, as we have seen in the censorship case at github related to nationality.
IMHO, this does not apply to Git repositories.
Git repo is only part of that solution.
The primary reason for difficulty switching to another 'git host' (gitlab, github, https://git.sr.ht/, or self hosted) is issue tracking...
As those issues are not stored/tracked in the .git repo you can clone, and thus 'taking out' or 'moving' that data is near impossible.
And that.... is why projects on Github won't leave github easily.
Yes, some of the platforms have 'import' scripts to tackle this, but it is not a universal given that one can export/import these issues.
And issues can contain a lot of data about a project (discussion about a bug, why it was solved, why not etc).
Of course, this could partially be solved with better commit messages, but who has time for that eh ;)
Greets, Jeroen (who mirrors his projects on github, but has a private original of the repo self hosted; issue tracking thus is public and private...).
Git repo is only part of that solution.
The primary reason for difficulty switching to another 'git host' (gitlab, github, https://git.sr.ht/, or self hosted) is issue tracking...
That is true, but it's also not something that is essential or needs to live on Github. I've seen projects that direct users to Launchpad for issue tracking, but accept PRs on Github, for example.
In the worst case, you will lose issue discussions, but you will never lose the code.
And that.... is why projects on Github won't leave github easily.
Sure, but do they need to? I thought it was simply ridiculous when projects left for gitlab.com after Microsoft acquired Github. Admittedly, Gitlab is better software, but I don't think this played a big part.
If the project maintainers really cared about not being hosted by one of the biggest data empires on the planet, they should have moved away from proprietary services altogether. But that would have reduced visibility and ease of use for contributors.
Of course, this could partially be solved with better commit messages, but who has time for that eh ;)
Well, you should consider writing these anyway. Just like good code comments. Think about much easier it will be to understand your own code after 2 years. ;)
(who mirrors his projects on github, but has a private original of the repo self hosted; issue tracking thus is public and private...).
I think this is the best of both worlds.
On 2019-10-31 08:27, Gregor Riepl wrote:
Git repo is only part of that solution.
The primary reason for difficulty switching to another 'git host' (gitlab, github, https://git.sr.ht/, or self hosted) is issue tracking...
That is true, but it's also not something that is essential or needs to live on Github. I've seen projects that direct users to Launchpad for issue tracking, but accept PRs on Github, for example.
In the worst case, you will lose issue discussions, but you will never lose the code.
Launchpad is just another centralization, you just moved your problem there.
And really, a single interface for code insight and review is really handy.
And that.... is why projects on Github won't leave github easily.
Sure, but do they need to?
They need to be in a place where people can contribute and where code does not go missing.
I thought it was simply ridiculous when projects left for gitlab.com after Microsoft acquired Github. Admittedly, Gitlab is better software, but I don't think this played a big part.
Is it really 'better'? Also politically they are under fire...
Everything has pro/cons there, and they are all centralized platforms.
Check the Subject line ;)
If the project maintainers really cared about not being hosted by one of the biggest data empires on the planet, they should have moved away from proprietary services altogether. But that would have reduced visibility and ease of use for contributors.
You mentioned launchpad (more an Ubuntu thing), Debian has self-hosted Gitlab, and many projects have their own instances of repo.
Pick what you want to maintain and works for you.... but remember those backups / private copies...
Of course, this could partially be solved with better commit messages, but who has time for that eh ;)
Well, you should consider writing these anyway. Just like good code comments. Think about much easier it will be to understand your own code after 2 years. ;)
I do so... others will not.
(who mirrors his projects on github, but has a private original of the repo self hosted; issue tracking thus is public and private...).
I think this is the best of both worlds.
It is a balance, not every programmer is willing to afford that amount of effort...
Many programmers are not sysadmins, or network folks.... and some claim to be 'devops', but that is just using a git-style tool to track changes, they are not programmers and sysadmins at the same time either.
([1] Defining programmer as somebody who can crank out a fully working system, not a few scripts or modification, as the distinction there).
Greets, Jeroen
Addendum, a possible solution for better collaboration between privately hosted Git platforms could be something like this: https://github.com/forgefed/forgefed (also based on https://github.com/go-gitea/gitea/issues/184 )
It doesn't solve the issue tracking part, however.
And in other news: https://www.theregister.co.uk/2019/10/31/notepad_china_spam/ Using code for political protest is taking things one step further...
On 2019-10-31 08:47, Gregor Riepl wrote:
Addendum, a possible solution for better collaboration between privately hosted Git platforms could be something like this: https://github.com/forgefed/forgefed (also based on https://github.com/go-gitea/gitea/issues/184 )
You might want to look again what the bottom of Pascal's server shows as a version ;)
It doesn't solve the issue tracking part, however.
One can allow people to open accounts on private instances.
Greets, Jeroen
-
Gregor Riepl -
Jeroen Massar -
Nico Schottelius -
Pascal Gloor