/tech/ - Technology★

So how do I do this with firewall-cmd?

>>1071191

The firewall-cmd is here: https://access.redhat.com/security/vulnerabilities/tcpsack

Question.. is Qubes OS (Linux distro) Really safer than Tails??? I keep seeing snowden's name popping around in whonnix etc.. if snowden is deep state and he supported and recommended Qubes.. does that make it a BS operating system?

I didn't want to create a new threat im kind of a newb here but if someone could tell me their thoughts on Qubes that would be greately appreciated :)

>>1071184 (OP)

>net/ipv4/tcp_sack

what is this setting for ?

>>1071606

I don't like Qubes because too heavy (memory and cpu) and systemd everywhere, whonix is better i guess

>>1071583

Qubes is safe. It's better for privacy if you want to mix tor and clearnet browsing on a single machine because every instance of an app can be put in it's own container (virtual machine). So it helps if your goal is compartmentalization, which is good against fingerprinting.

Neither system will protect you from hardware backdoors or flaws (Intel, HDD vendors, etc.).

Qubes won't help you if you're on an Intel CPU because there are ways to bypass VM isolation.

Both systems are using a fuck ton of bloat software so you're exposed to software vulnerabilities too.

You're all a bunch of fags imho

>>1071783

network namespaces are much simpler, it's easy to isolate a program in them so that they only can for example use/see a tor or VPN connection to talk with the world. Accidental or malicious ip leaks are impossible as they literally cannot see any other connection like the Ethernet card from that namespace, for example. It simply doesn't exist. You can even hide your LAN away from these programs that way. My login sits in a "nonetwork" namespace that only has a loopback device. That means all programs that spawn from it cannot access to the internet or even my LAN, as it isn't in their scope. They only get moved/spawned into other namespaces if they actually need network connectivity. I run two different instances of browsers, one using tor/vpn and one using my normal internet connection. (for online banking and shopping and such, where my identity is known anyways) I also run my browsers as different users with little privilege so that even if they get somehow compromised, they don't have access to anything interesting on the system. On top of that I use MAC, but it doesn't really even add a lot at this level and you could skip out on it. All this is simple, low overhead and doesn't require VMs.

network namespaces are function the linux kernel had for a long time and they are painfully underutilized, especially considering how simple and low-overhead they are.

>>1071687

>what is this setting for ?

It disables the selective acknowledgement (SACK) feature completely. In case of packet loss, TCP throughput will suffer because more data has to be retransmitted.

This part of the configuration should be enough already (for pure iptables, that's "iptables -I INPUT 1 …" instead).

-A ufw-before-input -p tcp -m tcpmss --mss 1:500 -j DROP

It drops all TCP SYN packets which are trying to initiate a connection with a suspiciously small MSS value that can be used to trigger this bug, without disabling SACK completely.

All I got in /etc/ufw is 'applications.d'

stupid intrigeri

>>1071800

could you make a tutorial for us

>>1071800

>network namespaces

thanks bro

>>1072370

>could you make a tutorial for us

the anon already said enough you lazy nigger.

Is anyone surprised that UNIX brain damage is responsible for remote vulnerabilities? It was already pathetic in 1991 when Multics and other operating systems that did it properly were around for decades. Linux (the kernel) wastes billions of dollars and countless years and still isn't as good as software made by much smaller groups in a much shorter time. That's because it's written in C, which sucks.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11477

>Jonathan Looney discovered that the TCP_SKB_CB(skb)->tcp_gso_segs value was subject to an integer overflow in the Linux kernel when handling TCP Selective Acknowledgments (SACKs).

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11478

>Jonathan Looney discovered that the TCP retransmission queue implementation in tcp_fragment in the Linux kernel could be fragmented when handling certain TCP Selective Acknowledgment (SACK) sequences.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11479

>Jonathan Looney discovered that the Linux kernel default MSS is hard-coded to 48 bytes. This allows a remote peer to fragment TCP resend queues significantly more than if a larger MSS were enforced.

Integer overflows, heap fragmentation, and hard-coded sizes, all problems that UNIX-Haters complained about back in 1991 that have been solved in various ways since the 60s. Another thing that sucks are all the bullshit overlapping configuration files UNIX/Linux use that are scattered everywhere. One of them, "before.rules" takes sets of command line options on lines. Another one, "sysctl.conf" uses something that looks like a UNIX file path but isn't. Another "sysctl.conf" looks almost the same but uses dots instead of slashes. How many configuration "formats" and pseudo-filesystem hierarchy "namespaces" does Linux have? I'd bet the code needed just to parse these files is larger than some entire operating systems.

Date: Mon, 7 Jan 91 23:09:32 EST
Subject: What you once thought was a brain-dead misimplementation is now the protocol definition!
  or, Unix Historical Revisionism At Work Again,
  or, IETF-approved RFC1196

    This whole thing is pretty sad, or pathetic, or depressing
or something.  

    Firstly, there's the rewriting of a protocol to conform
to a ubiquitous misimplementation -- the unix story over and
over.

    Then there's the growing Balkanisation (or
Multics-ification) of the net -- I remember laughing out
loud when I found that MIT-MULTICS refused finger service on
security grounds.

    Then, or course, there's the pathetic implementational
warnings about how one should be very very careful in
implementing this sensitive and dangerous protocol -- as if
this perilous protocol somehow innately offered a direct way
to shove fingers up unix' sockets.  Or something.

>>1072448

how come that everyone says these are very serious bugs but i have never seen anything about them being successfully used for something.. there sure isnt any automated tools for this because there would be so much unpatched shit that would constantly crash if there were. anything from consumer routers to phones and even internet connected servers run linuxes that are old enough to have one or more of these vulnerabilities.

>>1071882

>disabling SACK completely

You probably don't want to do that. It might sound convenient now, but you'll regret it in the long run when you eventually want kids.

>>1072448

So where's the PL/I compiler for Linux?