25 Oct
2019
25 Oct
'19
12:57 p.m.
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
25 Oct
25 Oct
1:44 p.m.
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
7:24 p.m.
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).
git clone https://git.home.spale.com/dhcp_protect.git
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!
8:20 p.m.
New subject: Decentralisation vs. centralisation [was: new project: DHCP Protect]
Good evening,
Gregor Riepl <onitake(a)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
30 Oct
30 Oct
10:09 p.m.
New subject: Decentralisation vs. centralisation [was: new project: DHCP Protect]
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. ;)
31 Oct
31 Oct
2:15 a.m.
New subject: Decentralisation vs. centralisation [was: new project: DHCP Protect]
On 2019-10-30 22:09, 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...
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...).
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.
8:27 a.m.
New subject: Decentralisation vs. centralisation [was: new project: DHCP Protect]
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.
8:34 a.m.
New subject: Decentralisation vs. centralisation [was: new project: DHCP Protect]
On 2019-10-31 08:27, Gregor Riepl wrote:
Launchpad is just another centralization, you just moved your problem there.
And really, a single interface for code insight and review is really handy.
They need to be in a place where people can contribute and where code
does not go missing.
I do so... others will not.
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
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.
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. ;) (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.
8:47 a.m.
New subject: Decentralisation vs. centralisation [was: new project: DHCP Protect]
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...
9:56 a.m.
New subject: Decentralisation vs. centralisation [was: new project: DHCP Protect]
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
1314
days inactive
1320
days old
9 comments
4 participants
participants (4)
-
Gregor Riepl -
Jeroen Massar -
Nico Schottelius -
Pascal Gloor