Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

When an exploit was successfully executed, is there a way to block the user from bouncing back a shell?

I would like to know about this on both Windows and Linux machines.

share|improve this question
up vote 1 down vote accepted

On a production web server, you should prevent outbound TCP connections from being created, excepted for trusted addresses. Any stateful firewall should allow you to create rules for this kind of scenario.

If you're using iptables, try something like this:

iptables -A OUTPUT -p tcp --tcp-flags ALL SYN -m state --state NEW -j DROP

My iptables-fu is a bit rusty, so excuse any errors in that command.

This drops all outbound TCP packets that belong to a new TCP connection, with only the SYN flag set. In other words, it completely prevents outbound TCP connections.

share|improve this answer
Wont this also prevent any web-surfing, antivirus updates that rely on HTTP, patching over HTTP and so on? – Chris Dale Sep 26 '12 at 10:40
@Karrax Websurfing on a commandline-only linux server? Updates is the only issue, but they can be pushed instead of polled for. – Luc Sep 26 '12 at 10:42
I didn't read anywhere that this was for linux only and servers only :) If it were for servers only I'd agree that blocking outbound port 80 would be ideal, and instead use a web proxy for patches and such. – Chris Dale Sep 26 '12 at 11:02
Hence why I said "on a production web server" - you absolutely do not want to be browsing the web on your production boxes! And, as I mentioned, you should whitelist certain IPs, e.g. anti-virus update servers. – Polynomial Sep 26 '12 at 11:24

If you are talking about reverse shells this can be quite tricky to try preventing. For example the attacker successfully exploits target and uses the client to connect back to attacker on port 80 delivering a shell. Outbound port 80 should of course be allowed. Trying to prevent shell signature over port 80 would probably create a whole lot of false positives.

I would rather aim for detection rather than prevention.

share|improve this answer
I'm not sure I agree with "outbound port 80 should be allowed". Outbound traffic, yes. Creation of outbound TCP connections, no. – Polynomial Sep 26 '12 at 9:56
That depends. Pretty sure yum update or apt-get update uses http, no? Wordpress's auto-update code certainly does. I can see a number of scenarios where allowing outbound connections might be needed, to arbitrary addresses - clearly best avoided, but it does depend on your scenario. – user2213 Sep 26 '12 at 10:19
@Ninefingers You could make a script that pushes updates over ssh every 12 hours or so, then cron to run them. Not really ideal, but neither is it ideal to get exploited... – Luc Sep 26 '12 at 10:41

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.