4 ms·

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. I

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.

saraid216 13y ago
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.
- sturadnidge 13y ago
  Yeh i know what you mean, see reply to the other similar comment :)
FooBarWidget 13y ago
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.
- sturadnidge 13y ago
  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.
jlkinsel 13y ago
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.
- readme 13y ago
  Or a non-privileged account is accessed and the kiddie just wanted to run an eggdrop bot. Plot foiled.
txutxu 13y ago
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.
jacquesm 13y ago
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.
- sturadnidge 13y ago
  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.
  - jacquesm 13y ago
    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.
nly 13y ago
Even an unprivileged compromised PHP script can open sockets and send email. Is it your intent that your server be able to send spam?
Zoomla 13y ago
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 )
kjs3 13y ago
Remote exploit of a non-privileged account that needs to phone home to collect the local exploit to get root (after figuring out which one will work for the environment)? Seen it many times.

saraid216 13y ago

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.

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

FooBarWidget 13y ago

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.

sturadnidge 13y ago
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.

jlkinsel 13y ago

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.

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

txutxu 13y ago

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.

jacquesm 13y ago

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.

sturadnidge 13y ago
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.
- jacquesm 13y ago
  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.

nly 13y ago

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

Zoomla 13y ago

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 )

kjs3 13y ago

Remote exploit of a non-privileged account that needs to phone home to collect the local exploit to get root (after figuring out which one will work for the environment)? Seen it many times.