LOG(0, " [hint] need to sudo or run as root or something\n");
LOG(0, " [hint] I've got some local priv escalation "
"0days that might work\n");
EDIT: I shall forget I ever looked in the code. There's no LICENSE file, but there's this...
/* Copyright: (c) 2009-2010 by Robert David Graham
** License: This code is private to the author, and you do not
** have a license to run it, or own a copy, unless given
** a license personally by the author. This is
** explained in the LICENSE file at the root of the project.
**/
I wonder what you mean by FOSS compatible? Copyright by default is rather restrictive; to make something free, you must explicitly grant these freedoms. A warranty disclaimer does not grant people the freedom to copy, modify, sell, redistribute, etc.
So this is a software DMZ? I haven't done this before, but it should be doable in netfilter or routing tables without an ip stack on the interface.
I should also add that choosing to rely on new, custom code for a specific purpose like this is much more dangerous than relying on the decades-old Linux netfilter and ip stack. One netfilter rule would prevent a DMZ'd host from fucking with the transparent firewall.
Easy to configure, simple functionality, niche-use.
I think it's a pretty cool idea, and definitely might come to use it if I ever get a machine in-house infected with something interesting and I want to just toy with it (/ keep an eye on what it's doing). I'm sure this would be useful for security professionals dealing with all kinds of network-required infections (or not, as all the "BadBIOS" talk suggests).
Pretty cool stuff, I'm wondering if one could simply set this up with a set of iptables rules (on a Linux router, i.e. DD-WRT). Just drop all packets that aren't destined to the open internet, and even control which ports the isolated machine has access to (i.e. cut off port 80 and see if the infection/process tries to reach out on port xyz or something else).
Just using iptables would be easier but has the disadvantage that the quarantined box "knows you're there" and could attack or behave differently. The advantage of this solution is that the firewall is almost (but not quite) fully transparent.
I dislike comments like this because you're not actually making a point. For all you know the parent did read the article. I did too - and I still took a minute to not have the same concern as the parent. If you read the article, why don't you enlighten everyone else reading your comment?
My first thought was similar - because I was picturing actively self-replicating malware, and you're right - if you don't want that on your own network you shouldn't be opening up everyone else's network to it. But I think the point is just to open up pockets inside your trusted network for less-trusted machines. It's not that you think they have viruses, it's that you just don't want them to have access to the rest of your internals. Most places have an entirely separate network for guests, but if this was reliable and robust enough, maybe it would be a nice alternative.
