moonpiedumplings
@moonpiedumplings@programming.dev
- Comment on Wireguard easy and third party von service. 2 days ago:
randomise your web interface port
Randomized interface ports change nothing except for stopping automated scanners. They don’t really help. Just lock it behind ssh, physical access or similar, and then never worry about it again.
Yeah only if you enable their cloud api
No, all of the local web interfaces have had problems too. Literally every router or network appliance has had similar issues.
ts not an isp or consumer router
ISP, consumer, and enterprise routers have all the same issues due to the same architecture. All of them.
have also pen tested my router remotley.
Me too. But it’s just not about my router being secure today, it’s about it being secure tomorrow. I want to be able to rest easy knowing that if a new vulnerability appears in xyz component then I don’t have to worry about it.
- Comment on Wireguard easy and third party von service. 2 days ago:
Every issue with tp link has been. You need to have acces to the router physically to implement.
Come on, this is not true and you know it. Finding a counterexample was easy:
anavem.com/…/tp-link-patches-critical-router-flaw…
Auth bypass + auth rce flaw. Literal remote code execution, instant own.
The problem with network appliances/routers is that they all have web ui’s, and management api’s or something of the sort. Web UI’s are extremely complex services, with lots of difficult to secure attack surface. In a router, that attack surface is now running as root (because it has to be, to manage linux (or freebsd, routers are usually based on one of the two) kernel routing and networking.
So literally every single network appliance and router has had it’s own critical vulnerabilities, even open source ones like openwrt.
The real solution here is to recognize that web interfaces are a security nightmare, and to either disable them or lock them behind ssh.
(Open)ssh, is known for having extremely few vulnerabilities, only 2.5 critical ones over it’s 25+ years of existence. That’s a big difference compared to some of these network appliances/routers with have 2+ critical vulns every quarter.
- Comment on How about creating a new protocol for a project ? · TheOdinProject/curriculum · Discussion #31140 1 week ago:
No, I just keep an eye on this and similar projects in order to recommend them when people ask.
- Comment on How about creating a new protocol for a project ? · TheOdinProject/curriculum · Discussion #31140 1 week ago:
The linked resources, are free, yes.
They have a site with paid courses, but that site doesn’t cover creating your own network stack/protocol yet. I’m guessing the resources I linked were them savings stuff so they could eventually make their own course.
- Comment on How about creating a new protocol for a project ? · TheOdinProject/curriculum · Discussion #31140 1 week ago:
github.com/codecrafters-io/build-your-own-x#build…
This site, a similar site dies have resources for that as a course. It’s very difficult, though.
- Comment on Easiest to set up IAM solution? (OIDC, OAuth2, SSO, etc.) 2 months ago:
Void auth, or kanidm look like easier alternatives.
- Comment on NaiHe – lightweight E2E encrypted chat over any self-hosted MQTT broker 2 months ago:
You and your peer agree on an encryption key (any string).
This is unacceptably unsecure for the usecases you mention. There is a reason why the most secure messaging apps don’t use symettric encryption, don’t use passphrases, and they also possess forward secrecy.
It’s pointless to push this as a censhorship circumvention method
I appreciate the projects, but use of this to bypass