How to detect what's blocking my incoming traffic on Ubuntu 14.04 LTS, if it's NOT iptables and NOT EC2 Security Group?

Question

I have SSH root access to an EC2 instance.

It's Ubuntu 14.04 LTS.

I have nginx web server listening on all interfaces on port 80 TCP. It's accessible from this server but not from the outside.

Apparently all of my incoming traffic except 22 TCP is blocked - other TCP ports, all UDP and ICMP.

Yet my iptables on this server are empty:

root@ip-x-x-x-x:~# iptables -v -L
Chain INPUT (policy ACCEPT 3162 packets, 1472K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 4203 packets, 674K bytes)
 pkts bytes target     prot opt in     out     source               destination  

Here's the nmap scan output from my local machine:

grzegorz@MacBook-Pro-Grzegorz:~$ sudo nmap -v -Pn -p 22,80 x.x.x.x

Starting Nmap 6.47 ( http://nmap.org ) at 2015-01-31 20:40 CET
Initiating Parallel DNS resolution of 1 host. at 20:40
Completed Parallel DNS resolution of 1 host. at 20:40, 0.16s elapsed
Initiating SYN Stealth Scan at 20:40
Scanning ec2-x-x-x-x.eu-central-1.compute.amazonaws.com (x.x.x.x) [2 ports]
Discovered open port 22/tcp on 54.93.91.112
Completed SYN Stealth Scan at 20:40, 1.38s elapsed (2 total ports)
Nmap scan report for ec2-x-x-x-x.eu-central-1.compute.amazonaws.com (x.x.x.x)
Host is up (0.035s latency).
PORT   STATE    SERVICE
22/tcp open     ssh
80/tcp filtered http

Read data files from: /usr/local/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 1.58 seconds
           Raw packets sent: 3 (132B) | Rcvd: 1 (44B)

..so some kind of firewall is blocking my traffic.

Let's assume that it's NOT an EC2 Security Group.

What else can be blocking my traffic? Something that is running on the VPS itself? Something in the kernel or something in the user space?

UPDATE:

I tested apparmor:

root@ip-x-x-x-x:~# apparmor_status --verbose
apparmor module is loaded.
4 profiles are loaded.
4 profiles are in enforce mode.
   /sbin/dhclient
   /usr/lib/NetworkManager/nm-dhcp-client.action
   /usr/lib/connman/scripts/dhclient-script
   /usr/sbin/tcpdump
0 profiles are in complain mode.
1 processes have profiles defined.
1 processes are in enforce mode.
   /sbin/dhclient (607) 
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.

..and I interpret this output as it hadn't anything to do with the filtering but I have disabled it anyway:

root@ip-x-x-x-x:~# service apparmor stop
 * Clearing AppArmor profiles cache
   ...done.
All profile caches have been cleared, but no profiles have been unloaded.
Unloading profiles will leave already running processes permanently
unconfined, which can lead to unexpected situations.

To set a process to complain mode, use the command line tool
'aa-complain'. To really tear down all profiles, run the init script
with the 'teardown' option."
root@ip-x-x-x-x:~# service apparmor teardown
 * Unloading AppArmor profiles
   ...done.

..but it didn't help. nmap still shows filtered TCP 80, nginx still not accessible.

Answer 1

It might be that the hosting provider have a firewall service defaulting to only permit ssh traffic to the server. The purpose of such a default could be to limit exposure of the server until you have had time to install all security updates, harden your configuration, and in general ensure your server is ready to go live.

If such a service happens to be in place, there is likely going to exist a web interface through which it can be configured. There should also exist a place to disable it completely.

The steps I would recommend are the following:

1. Read documentation from the hosting provider to find out if a firewall service like the one described above happens to be in place.
2. Use tools to narrow down the location of any filters you haven't found documentation for.
3. Ask the provider

What you can do to narrow down the location of filters is to use the traceroute command. Ubuntu 14.04 has a traceroute command with flags that can send packets with specific protocol and port number. That way you can for example compare the output obtained from a trace to port 22 and port 80.

traceroute -n -T -p 22 server

Notice that different traceroute implementations exist. If for some reason the flags seem not to work, then try traceroute.db, which should give you the version with support for the above combination of flags.

Answer 2

Apparently there is no other firewall solution on Linux that doesn't in fact use iptables/netfilter. Also a simple SYN test is the proper way to check if your traffic is filtered by a firewall. You are right that looking for an "upstream" firewall, a Security Group of this EC2 instance in this example, is the only reasonable way to resolve this. Thank you for all your input that led to this answer.