So we've all heard how awesome firewall distros like IPFire, pfSense, etc. are. But a lot of things are claimed to be awesome, and don't life up to it in reality. I wanted to verify those claims. Thus, yesterday I set this up: Two VMs running Puppy Linux ( ), one running IPFire, all on top of Backbox on my AMD A2 workstation. That's Armitage (a Metasploit frontend) in the background. - IPFire was configured with one virtual NIC on an internal net, the other on a bridge - Puppy Control was on a bridge - Puppy Test was on the internal net, seeing the world through an IPFire periscope So, first: establish that the control can be successfully attacked. This sounds obvious - Puppy being, by all appearances, the most insecure distro ever - but it actually isn't. From what I've seen, even supposedly applicable exploits usually fail on TahrPup. I suspect the PAE/NX enabled kernel is largely responsible, especially in combination with ASLR and Ubuntu-issue PIE binaries... Anyway, we know that the "fake XPI extension" social engineering attack will work, if the XPI is in fact clicked on. And indeed: Now with that out of the way, let's try the test VM. We'll start with a typical iptables firewall config. ... Yay. Alright, now let's try with the squid proxy enabled. Proxy is in transparent mode, all traffic forced through it. On to the next post...
So, here's the proxy config. Note I'm not letting through TLS, because it's just not needed for this experiment. Unfortunately, this does not help at all. Not that I expected it to. With all ports still allowed, traffic can just bypass the proxy. But what if we block everything except proxy traffic? And this time, it looks like we might have something. Huh: Victory? We'll see in the next post.
... No, not victory, because we're still using weird ports and now the firewall is blocking them. What happens when we switch to ports allowed by the proxy? The answer is, "not much different!" The reverse shell doesn't start. Wait, you say, is this the proxy blocking it? Or is it actually the firewall? Nope, nothing in the firewall logs. It's the proxy. And our test VM is still uncompromsied. Victory!
Bonus: for extra measure, let's see if ClamAV scanning on squid can block the XPI, not just the reverse shell. Yup... A bit iffy though, insofar as it blocks the download every time, but only displays the banner after the first time. Whoops. Also, I'm gonna guess that this is not a generic detection. Might still be worthwhile, I've seen differing opinions on that.
So, conclusions. What happened here? My guess: the proxy understands protocols - HTTP and FTP. A reverse TCP shell is not part of those protocols, even when it's on the correct port, so the proxy will not pass it through... My guess, anyway. Can it be relied upon? Probably not. A reverse shell based on HTTP, or (gods forbid) HTTPS, would in the above case go right past it. But at least it limits an attacker's options a bit. What about ClamAV scanning? Maybe. Malware detection is probably more important for end users... and ClamAV malware detection is frankly rubbish in my experience. OTOH, Clam detection of PUAs, and of generally weird program characteristics, is pretty good IMO. It might be helpful, but again I don't think I'd rely on it. Should I set up a firewall/proxy box? Not my place to say, really... It does seem to me like a better bet than just an outbound firewall. However, I'd strongly caution against using HTTPS MITM capabilities with a proxy. That creates a single point of failure, that an attacker could use to really mess you up.
