z3bra

@z3bra@lemmy.sdf.org
13 Post – 207 Comments
Joined 1 years ago

ELI5

So it's saturday afternoon, a very hot one, so you ask your daddy for an ice cream (hosted service). The shop you go in is very bizarre though, as there is one vendor (TCP port) for each flavor (docker service/virtualhost). But it's tricky because they're all roaming in the shop, and you don't know who's responsible for each flavor. Your dad is also not very comfortable paying these vendors directly because they only accept cash and do not provide any receipt (self-signed certificate/no TLS).

Hopefully, there is the manager (reverseproxy) ! This girl is right where you expect her: behind the counter (port 80/443), accept credit cards and has a receipt machine (Domain name + associated certificate). She also knows everyone on her team, and who's responsible for each flavor !

So you and your dad come to see the nice lady, ask for a strawberry + chocolate ice cream, and pay her directly. Once done, she forwards your request directly to the vendors responsible for each flavor, and give you back your ice cream + receipt. Life is good, and tasty !

5 more...

Weight your words my friend! GNU's a behemoth !

GCC alone is almost as big as Linux. Add core/binutils, the Hurd, ... And you easily outclass the kernel itself !

~ $ du -sh linux-6.4.12/ gcc-13.2.0/                    1.5G    linux-6.4.12/                                   1.1G    gcc-13.2.0/

Oh, and Emacs.

6 more...

Because other people might have restricted environment which might not suit their preference is not a good reason to level it down IMO.

Also, I think 9 is the best size for indent (matter of preference), do you think I should switch to space so everyone can enjoy this wonderful view I have ?

10 more...

Tabs for indent, spaces for alignment. This is the way, I can't believe people are still fighting that ?

37 more...

You don't need to access a .onion instance to use Tor. You can simply perform your day-to-day web usage through Tor directly.

On your phone, you can even use Tor natively with most of your apps.

IPv4 and IPv6 are two different network stacks. Your IPv4 stack is hidden behind wireguard, but not the IPv6 one.

The correct way to fix your issue is to setup a second witeguard tunnel for IPv6, and route IPv6 traffic through it.

Edit: many comments advise to block outbound IPv6 traffic. Don't do that! It will add latency to all your requests as you will have to wait for them to timeout.

3 more...

endlessh was pretty cool and a more modern version is even better ! I'll give it a shot !

On a side note, I found a way to trap HTTP connections too while working on my cyb.farm project. The go implementation is ridiculously simple: tarpit.go. It works by providing an endless stream of custom headers to the client, which it is supposed to ingest before getting to the content itself.

I get what you say, and you're definitely not wrong to do it. But as I see it, you only saved ~80Kib of ingress and a few lines of logs in the end. From my monitoring I get ~5000 failed auth per day, which account for less than 1Mbps average bandwidth for the day.

It's not like it's consuming my 1Gbps bandwidth or threatening me as I enforce ssh key login. I like to keep things simple, and ssh on port 22 over internet makes it easy to access my boxes from anywhere.

7 more...

I'm reading all the comments and I'm shocked... In France, with uncapped access and 1Gbps down/600Mbps up (theorical) I pay 40€/mo (30€ every six month when I call to complain that it's too expensive). And it's definitely not the cheapest provider.

That's insane !

3 more...

Congratulations! A mail server is quite demanding in terms of initial setup, but it's also very rewarding !

Here are a few pointers I can give you:

  • Using a good domain is important, some provider block entire TLDs for cheap domains (eg. .tk or .pw). I learnt it the hard way...
  • Set your MX records to A records, not CNAME
  • Ensure your PTR records match your A records for the mail server
  • Learn about SPF and DKIM
  • Set them up, and verify with mxtoolbox
  • Use the ip4: and/or ip6: selectors for SPF
  • Setup a spamfilter (I like spamassassin)
  • Leave it all running for a few weeks/months
  • Publish a DMARC policy on your DNS, and verify with mxtoolbox

This should limit a lot your likeliness to end up in spam folders (which is usually the hardest part about running your mail server)

1 more...

Don't even bother with a SWAP partition. Create an empty file on your / partition so you can grow/shrink it as needed.

did if=/dev/zero of=/SWAP bs=1024m count=4
mkswap /SWAP
swapon /SWAP
2 more...

I mean, it's not a big deal to have crawlers and bots poking at our webserver if all you do is serving static pages (which is common for a blog).

Now if you run code on server side (eg using PHP or python), you'll want to retrieve multiple known lists of bad actors to block them by default, and setup fail2ban to block those that went through. The most important thing however is to keep your server up to date at all times.

struct Ident arr = [
{
.id
= 0,
.name
= "Bob",
.pubkey
= "",
.privkey
= ""
},
{
.id
= 1,
.name
= "Alice",
.pubkey
= "",
.privkey
= ""
}
];
10 more...

It's not about GNU being wrong or not, it's about having the choice.

Deb support will come later, but:

If the same piece of software exists in the Ubuntu repository and the snap store the new store will only make it possible to install the snap version.

So the title is on point IMO.

I've been a crux user for over 10 years now. I switched to it from Archlinux because it uses a port tree system for packages (think of it as the AUR but for everything) and because the package "recipes" are very simple and easy to write.

At the time I was packaging a lot of stuff on Arch and the PKGBUILD format felt too bulky, complex and constraining for my needs. I switch to crux and found one of the simplest distro out there, and sticked to it. It's also the Linux distro that feels the most like OpenBSD, which is neat as well.

Also the mascot.

2 more...

I'm on the boring side...

PS1="% "

I like it though, it gives me more room for commands !

4 more...

This title is a ridiculous clickbait. Read the original article from La Quadrature du net for actual context.

I do agree that this case takes way too many shortcuts about privacy/encryption to flag these people as terrorists. However, the people depicted in this case are not just using an adblocker. They run Tails, Tor and signal "by default" and at all times, which I doubt is the case of anyone calling themselves a "terrorist" in this thread. Doing so require a huge commitment in one's life, and that's what the police is using as "proofs" for their suspicions. And that's the part that is fucked up, because it's basically duck typing applied in a court. They have no proof of anything, and just suspect these people because they take a lot of extra steps to protect their privacy and anonymity.

As a French people myself, I'm glad that La Quadrature is stepping in to prevent the judge to take this ridiculous shortcuts as proofs. However, as someone using Signal, Tor and adblockers daily, I don't feel like I have anything to fear. Yet.

"Ability to reboot without breaking a sweat"

I've just started digging into it myself ! Here's my current setup (I'll see how it scales in the long term):

  • syslog on every host
  • Telegraf collects and parse logs
  • InfluxDB stores everything
  • Grafana for dashboards

I run OpenBSD on all my servers, and configure all the services to log via syslog.

Then I configuré syslog to send only those I care about (https, DNS, ...) to a central telegraf instance, using the syslog protocol (RFC3164).

On this collector, telegraf gets all these logs and parse them using custom grok patterns I'm currently building, to make sense out of every log line it receives. The parsed logs are in turns stored in Influxdb, running on the same host.

I then use Grafana to query InfluxDB and create dashboards out of these logs. Grafana can also display the logs "as-is" so you can search through them (it's not ideal though as you simply search by regex from the full message, so it's on par with grep at least).

This setup is fairly new and seem to work very well. Telegraf is also very low on resource usage for now. I'll have to continue adding grok patterns and send more application logs to it to see how it handles the load. I do have a few questions still unanswered for now, but time will tell:

Q: Should I first collect via a central syslog before sending to telegraf ?
This would let syslog archive all logs in plain text, rotate and compress them. I would also only have a single host to configure for sending logs to telegraf. However this would eat up space, and could hide the original sending hostname for each log. I might try that someday.

Q: Should I run telegraf on each host ?
This would distribute the load of the grok parsing amongst all hosts, and then all telegraf processes will send directly to the central one for collection, or even directly into influxdb. I would also benefit from telegraf being install on each host to collect more data (CPU, network stats, ...). However it makes the configuration more complex to handle.

Q: What is a good retention period ?
For now, influxDB doesn't expire any data, as I don't have much yet. In the long run, I should probably delete old data, but it's hard to tell what is "old" in my case.

Q: Do I need an interface to read logs ?
I use this setup mostly for graphs, as grafana can make sense of fields like "http_verb", "http_code" and such. However, it is much more practical for me to dig into the logs right on the server, in /var/log. Having an interface like chronograf or graylog seems practical, but I feel like it's overdoing it.

Bonus: unbound dashboard

3 more...

The point here is that anyone can just spin up their own instance, federate with others, and see these information by inspecting their database.

Having a clear understanding of what is public, what's local to your instance and what's private is very important in this context.

1 more...

To be honest, Ed.

When I'm forced to edit text on my phone (eg. to fix a broken server while on the go), I ssh in and fire up ed. This is what takes the less screen space on my already to small screen, and because it's line oriented the screen doesn't bounce/resize/screw up when the keyboard appears/disappear.

For it to always work, you should put it in /bin. Every other solution may fail in some corner case.

Don't do this though.

The correct way to install a command is to package it for your distro, and put it in a place that's suitable for its usage.

Yggdrasil, an IPv6 end to end encrypted networking proof of concept. There's something about it that I find so innovative that I want it to succeed so badly !

7 more...

You're missing a chance to help cool tech moving forward :)

I've made something that's both fun and challenging: https://cyb.farm

It's a tech adventure featuring many challenges about computer science stuff (crypto, stegano, protocols, development, ...). It starts on the 31^st^ of October, and will probably can keep you busy for a few weeks ^^

C, definitely.

As a hobbyist programmer, I can write code just the way I want, in my own style and without any legacy code. In that context I find writing C relaxing, as I like to understand how things work internally and avoid abstractions levels as much as I can. ASM requires too much discipline though 😅

Or just set tabsize to 9, that's the point :)

1 more...

Sure we do, but you cannot expect everyone to simply run their own DNS and call it a day.

The vast majority of people don't even know that DNS even exist, let alone that your ISP can monitor/alter your traffic through it.

2 more...

That one is easy ! Because in a few years (remember, you're 5), you'll be a scout ! And to collect a few dollars for your summer camp, you'll sell pastries to the neighborhood. It's easier than ever because it's 2030, and everyone can just order the pastries on your website, and pay online. All you have to do now is hop on your bike, and deliver the pastries (network connections) to your neighbors (online servers). So you grab the first package, and read the label on it:

  • Mrs. Britneak

And that's it ! You have no idea who this person is, or where they live ! So you call out your leader (DNS server):

  • Hi Mr. Leader !
  • ... (nobody ever get my UDP jokes)
  • So I got this package to deliver to mrs. Brtineak. But I don't know where she lives
  • Oh sure, let me lookup the register (zone file). Hold on for a sec... Alright, she's here: 62.644888, -160.194309

And then he hangs up immediately (this is UDP, remember?).

You write it down (local caching DNS server), and look it up. You're a scout, so you're trained to read and find GPS coordinates. You go there in a few minutes and deliver the package in time ! Mrs Britneak is happy, and you go on to the next package:

  • Mr. Tomburgh

Time to call leader again !

So many things !

  • torrent tracker (to serve what?)
  • IRC server (I'm alone!)
  • Matrix server (ok, I tried this one... But I'm alone)
  • An SSO server (definitely overkill)
  • CI/CD system with vmd(1) (even more overkill!)
  • A package repository for binaries I build
  • A distributed package building system
  • ...

The list goes on and grows everyday haha

2 more...

Setup a local DNS server in your local network, and configure it to forward everything to an external DNS provider over TLS (port 853 usually). This is known as DNS over TLS (or DoT as other people mentioned).

I personally like https://cyberia.is

That's kind of the point though, as it's now used as a base for many containers ;)

OpenBSD for all of them.

4 more...

A VPN is easy to setup (and I have it setup by the way), but no VPN is even easier. SSH by itself is sufficiently secure if you keep it up to date with a sane configuration. Bots poking at my ssh port is not something that bother me at all, and not part of any attack vector I want to be secure against.

Out of all the services I expose to the clear web, SSH is probably the one I trust the most.

3 more...

I'm not sure how you understand the 3-2-1 rule given how you explained it, even though you're stating the right stuff (I'm confused about your numbered list..) so just for reference for people reading that, it means that your backups need to be on:

  • 3 copies
  • 2 mediums
  • 1 offsite location

A good headlight. I lend it to a friend for the last 2 weeks, and now I realize how much I use it.

Also my penny skateboard. This thing is light, small, and doesn't fear the rain. Being forced to walk because I don't have a skateboard is so frustrating to me!

Short answer: Don't bother, it's too complex to setup (unless your app is HTTP or supports the PROXY protocol). You better read your proxy logs instead.

Long answer: What you want is called "IP transparency" and require your proxy to "spoof" the IP address of the client when forwarding packets to the remote server. Some proxies do it (Nginx plus, Avi Vantage, Fortinet) but are paid services. I don't know for free solutions as I only ever implemented it with those listed above.

This require a fairly complex setup though:

0. IP address spoofing

The proxy must rewrite all downstream request to spoof the client IP address, making it look like the traffic originates from the client at the TCP layer.

1. Backend server routing

As the packet will most likely originate from random IP on the internet, your backend server must have a way to route back the traffic to the proxy, instead of it's default gateway. Otherwise you'd implement what is called "Direct Server Return*, which won't work in your case (packet will be dropped by the client as originating from your backend server directly, and not from the proxy).

You have two solutions here:

  • set your default gateway to the proxy over its VPN interface (don't do that unless you truly understand all the implications of such a setup)
  • use packet tagging and VRF on the backend server to route back all traffic coming from the VPN, back to the VPN interface (I'm not even sure this would work with an IPsec VPN though because of ACL...)

3. Intercept and route back return traffic

The proxy must be aware that it must intercept this traffic targeted at the destination IP of the client as part of a proxied request. This require a proxy that can bind on an IP that is not configured on the system.

So yeah, don't do that unless you NEED to do that (trust me as I had to do it, and hated setting it up).

Edit: apparently haproxy supports this feature, which they call transparent mode

2 more...

SOCKS is just a generic proxy protocol. It lets you tunnel TCP traffic between two hosts transparently. SSH can be use to setup this kind of tunnel using -D.

I'm a huge fan of cwm, but I must say you're not advocating for it in this shot ^^