Hacker News Reader

Comment by sturadnidge | Hacker News Reader

I've never understood the compulsion to restrict outbound traffic on an internet facing server that you do not intend to be used by other (untrusted) people.

If someone is good enough to own you with everything else locked down, they can change any firewall rules completely if they need to, or just tunnel out over an allowed port.

Creating a non-root user then giving them carte blanche sudo rights is similarly odd to me. I'd rather just use root and /etc/nologin (assuming no one else needed a login shell to run).

EDIT: Added paragraph about non-root users.

View on HN

I've seen more compromised boxes than one can shake a stick at. There's all sorts of reasons that blocking egress is a great idea. Compromises are usually automated bots, and no, they're not smart enough to bring down iptables. Even if it's a human that's pwned you, it's frequently a stupid human, or a lazy human. It's just good practice to practice security in depth.

Or a non-privileged account is accessed and the kiddie just wanted to run an eggdrop bot. Plot foiled.

The most important word in your comment is 'intend'. Unauthorized use is never intended (other than in honeypots, but even there it is somewhat intended...).

Egress filtering is important, if you think the chances are large that a user account is compromised a filter table can help. But an even more effective egress filter is one that you run on the router/hardware firewall just upstream from your machines. After all an egress filter on the machine can be disabled by someone that has compromised that machine.

Exactly right re: doing it downstream (or in the case of virtual machines, outside of the guest).

I didn't mean 'intend' in the context of unauthorised use, i was trying to differentiate between a 'single user' ( can't think of a better term, but i'm sure you know what i mean) application server and systems where you purposefully give shell access to other users but want to restrict egress.

Systems like that are only a privilege escalation away from being compromised and are much softer targets. Anything with shell access for multiple parties not known intimately to the owner of the box should be monitored with great zeal.

Even an unprivileged compromised PHP script can open sockets and send email. Is it your intent that your server be able to send spam?

Or maybe there's a vulnerability in your web app that grants people shell access. In that case you'll still want to lock down their limited normal-user privileges.

Yes but even then you're still not protecting much by allowing HTTP... said user would still be able to download attack tools locally and use them.

Agreed it will still stop a script kiddie (do ppl even use that word anymore? Showing my age!) from running random crap on high ports, but thats about it.

Blocking outgoing traffic for all applications except the ones that need the Internet can make a difference, especially under Windows. For example, some applications like to phone home for no benefit to the user and there is sometime no option to turn it off.

The option to block traffic per-application in Linux is no longer included in iptables (I think it was the switch --cmd-owner )

While I agree with your reasoning (and personally wouldn't bother with such a restriction), there is a good reason and it's that while they're likely good enough to get root, they might not be or simply can't for some reason. And if they can't, then that extra measure could be worth its cost in time and effort.

Yeh i know what you mean, see reply to the other similar comment :)

Not all automated scripts, or all the available scripts used in automated ways, can flush your rules before send things outside.

You're not going to be 24/7 at the keyboard of the system, there are going to be 0days, or unreleased vulnerabilities, etc.

Reply on news.ycombinator.com