[lug] Restoring my iptables

[Bear Giles]

(This message might have been put into gmail span hell if you only see
responses to it.)

The weird combination of flags *might* be due to a malicious kernel mode a
number of years ago. One of the conditionals was FLAG1 & FLAG2 instead of
FLAG1 && FLAG2. That would be a compiler error message that you can't use a
number (FLAG1 & FLAG2) as a boolean value but C doesn't care.

The result was that a packet with a certain nonsensical set of flags would
get special treatment by the kernel. Things like, you know, changing the
euid to 0 for the running process that sees that packet. It turns your bit
of browser malware that's a local exploit into one that gives you *root* access
as long as you can get them to download something from your own
webserver with a very special modification.

Obviously that bug was fixed a long time ago - and I don't even know if it
was this combination of flags - but it's easy to see it being added into a
configuration that you reuse widely. But now any vulnerable kernel would
have to be many years old. Decade?

Bear

On Tue, May 11, 2021 at 7:02 PM Jed S. Baer <blug at jbaer.cotse.net> wrote:

> After the last Ubuntu re-install, I thought I had managed to lose my saved
> iptables configuration. I've been running rdiff-back on important stuff for
> years, but apparently, I had saved the config somewhere where it wasn't
> getting backup up - still a mystery to me.
>
> So today though I should button that up, and looked briefly at ufw, and
> then decided I'd run the locate command one more time (I didn't before?)
> and huzzah, found a backup I'd made of /etc prior to some other upgrade.
>
> And now I'm wondering why I did what I did. Most of it, it's easy to
> recall, like opening ports for Samba. But I'm wondering why I did the DROP
> rule for only tcp. Maybe I wanted to be able to ping my machine from
> another? Maybe at one time, that mattered; maybe it will again.
>
> Anyways, here's what I'm doing now:
>
> *filter
> :INPUT ACCEPT [19927:1623720]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [21103:1725403]
> -A INPUT -i enp+ -m state --state RELATED,ESTABLISHED -j ACCEPT
> -A INPUT -i enp+ -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN -j DROP
>
> At one time, I probably found something that explained why to do it this
> way, but now I don't know why I would drop only TCP packets which have SYN
> set, and RST and ACK unset.
>
> I think I want to drop everything that doesn't match the first rule. I'll
> note that setting policy to DROP and then adding an ACCEPT rule like the
> first resulted in things such as apt-get install not working. As in:
> https://upcloud.com/community/tutorials/configure-iptables-ubuntu/
> except I didn't add any other ACCEPT rules, since I'm thinking I can just
> rely on the connstate ACCEPT, and add other rules only for explicit things
> I turn on, maybe if I enable sshd or samba again.
>
> Or maybe I should just go with ufw?
>
> --
> All operating systems suck, but Linux just sucks less
>  - Linus Torvalds
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20210512/b0701005/attachment.html>