6

I understand the need for putting a web server in a DMZ and blocking inbound traffic to all ports except 80 and 443. I can also see why you should probably also block most outbound traffic in case the server is compromised.

But is it necessary to block outbound HTTP traffic over port 80? If so, why? A lot of web applications these days rely on sending/retrieving data from external web services and APIs, so blocking outbound traffic over port 80 would prevent this capability. Is there a security concern that's valid enough to justify this?

Bobby Jack
  • 15,689
  • 15
  • 65
  • 97
Richard Davies
  • 429
  • 2
  • 4
  • 9

7 Answers7

7

The only reason I can think of is if your machine is somehow compromomised remotely then it won't be able to DDoS another website on port 80. It's not something I normally do though.

Steven Robbins
  • 26,441
  • 7
  • 76
  • 90
0

First - I agree with @vartec on throttling "Rather then blocking it, throttle it. Use iptables -m limit" as at least part of the solution.

However I can offer another reason to not block port 80 outbound at all times. If you have automatic security updates turned on the server can't reach out to PPAs over port 80 to initiate a security update. Thus if you have automatic security updates set up they won't run. On ubuntu auto-security updates are turned on in 14.04 LTS with:

 sudo apt-get install unattended-upgrades update-notifier-common && \
 sudo dpkg-reconfigure -plow unattended-upgrades
 (then select "YES")

More graceful solutions would be ansible scripts opening the port automatically, possibly also modifying an AWS security group rule via the CLI in addition to iptables if you are at AWS. I prefer modifying my outbound rules temporarily via AWS CLI initiated by a stealth box. This forces logging the update up in my AWS S3 log buckets but never shows up in the logs on the server itself. Further the server that initiates the update doesn't even have to be in the private subnet ACL.

Maybe do both? You have to figure at times an attack is going to relay off an internal IP in your subnet so there is merit to doubling down while preserving the ability to automate backups and security updates.

I hope this helps. If not reply and provide more code examples to be more specific and exact. #staysafe !

eschipul
  • 176
  • 4
0

If the machine is compromised and outbound traffic on port 80 is allowed, it would make it easier for intruders to send back harvested data to themselves. Allowing outbound traffic means you can initiate a connection from your machine to the outside world. A better approach would be allowing outbound traffic only to certain web sites/addresses that you trust (i.e. Microsoft Windows Update, Google reCAPTCHA) rather than any destination in the world.

Tony
  • 1,827
  • 1
  • 22
  • 23
0

Rather then blocking it, throttle it. Use iptables -m limit.

vartec
  • 131,205
  • 36
  • 218
  • 244
0

I have several web apps that invoke external web services, so I would say it's a bad idea to block output HTTP traffic. If you're concerned with security, you could block it and allow for only certain destinations.

Adam Crume
  • 15,614
  • 8
  • 46
  • 50
  • A whitelist is a good suggestion, but it won't work with OpenID, which requires that the web server be able to request any URL used as an OpenID. – Richard Davies Apr 03 '09 at 16:51
  • Not only that, it won't work with any website that ever changes IP address. That's how the firewall that I need to request changes for works - at the IP level, not the domain level (I take it this is for efficiency purposes?) It's a real pain since some IPs change a lot. – Bobby Jack Apr 06 '09 at 16:08
  • Also, won't there always be some service that could, conceivably, be used to DDOS another host? For example, on my outbound-HTTP-locked-down host, ping can still contact any host. – Bobby Jack Apr 06 '09 at 16:11
0

Depending on your SQL version, you could have certificate authentication time out issues with SQL server 2005.

Dave Harding
  • 1,280
  • 2
  • 16
  • 31
-2

what do you mean with blocking outbound traffic over port 80.

You have two possibilities. Gernerate Dynamic Rules which allow communication from client to your webserver for this session. Search for Stateful firewall rules.

Or you generally allow established Connections to communicate in and outgoing with each other.

If you generally block all outbound traffic over Port 80 your Webserver could not reply to any client.

The other way around, if your Webserver needs to get some API, e.g. a jquery library he wont use port 80 as his Port to communicate with the Webserver who holds the API.

Your Webserver would normally choose a port > 1024 and use it for his request to get the API from the remote Server.

So blocking all traffic over port 80 (as your port you connecting from) would not prevent your Server from sending any requests for apis and such things. because he doesnt use port 80 when he acts as a client.

evildead
  • 4,607
  • 4
  • 25
  • 49
  • I'm talking about allowing the web server to initiate outbound HTTP connections (port 80) to other servers on the internet. For example, you might have a PHP page that has a weather widget on it. That script would need to request the weather data from an external web service. – Richard Davies Apr 03 '09 at 16:32
  • ah ok, I thought you mean blocking Port 80 as the initiating port. If you block this, then you cannot load apis and such thing from other pages. You can probably add some Sites you trust in to your rules. But I would say blocking Port 80 generally makes not much sense. – evildead Apr 03 '09 at 16:36
  • from an other point of view, if your server gets hacked and you block that traffic it can`t load abituary code from other sites. But who garantees that the hacker/robot/whatever is using port 80 for his request :) – evildead Apr 03 '09 at 16:39