79
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 30 May 2026
79 points (100.0% liked)
Cybersecurity
10060 readers
19 users here now
c/cybersecurity is a community centered on the cybersecurity and information security profession. You can come here to discuss news, post something interesting, or just chat with others.
THE RULES
Instance Rules
- Be respectful. Everyone should feel welcome here.
- No bigotry - including racism, sexism, ableism, homophobia, transphobia, or xenophobia.
- No Ads / Spamming.
- No pornography.
Community Rules
- Idk, keep it semi-professional?
- Nothing illegal. We're all ethical here.
- Rules will be added/redefined as necessary.
If you ask someone to hack your "friends" socials you're just going to get banned so don't do that.
Learn about hacking
Other security-related communities !databreaches@lemmy.zip !netsec@lemmy.world !securitynews@infosec.pub !cybersecurity@infosec.pub !pulse_of_truth@infosec.pub
Notable mention to !cybersecuritymemes@lemmy.world
founded 3 years ago
MODERATORS
Things like this that play games scare me. This itself opens a wider attack vector on your server. I'm thinking of possibilities:
In Linux, each TCP connection is a file descriptor. PortTripper holds connections to waste scanner threads, which means it's holding file descriptors. This could be a good DDOS attack vector. Hit every port with connection requests, requiring a slew of file descriptor creations, and boom, you cause the server to hit the server ulimit cap. New connections cannot be made. The server is half dead.
Memory and CPU consumption. Maintaining thousands of open TCP states takes RAM and CPU. A massive flood can consume all memory. And for what? To annoy a hacker?
Interestingly enough, just these 2 things can make PortTripper a hacker's tool.
If a service crashes or reboots, is down for maintenance, or is slow to come up, PortTripper might grab the port before the application comes back up. And then it can't come back up.
Who's to say there won't be vulnerabilities in PortTripper that can cause a buffer overflow, memory leak, or parsing vulnerability in PortTripper's code or a library it uses? Playing this game opens another attack vector into your server.
If PortTripper can bind to ports 1 through 1023, then it's running as root or has elevated capabilities. If an attacker exploits a bug in PortTripper or a library it uses, they can get high-level control of the server.
While PortTripper "discards datagrams without replying" in a reflected DDOS attack, millions of discarded packets come in, which means millions of CPU interrupts at the kernel level. This can choke the NIC.
I think PortTripper is too risky to run just to become a nuisance to someone, IMHO.
I can understand caution before adding something new in case it causes problems, but I think most of your concerns are addressed on the github page.
I'd prefer this to be written in a compiled language as that would be less likely to fail due to external issues, but I think this would work for someone trying to slow down anyone once they've found an open port... and that's probably the root issue.
Go isn't compiled?
It is.
I think my wording wasn't the best... I was implying that I preferred a compiled application over something interpreted to address the points.
There's nothing wrong with interpreted languages. And go is in fact compiled so...
I agree with both of your statements.
For security applications, I prefer a compiled application as it's more difficult to alter in situ.