security group rule listing doesn't show details by default : causes user confusion

[Robert Collins]

I have a new quantum environment, with default security groups - and they have blank protocol, ip prefix etc:
quantum security-group-rule-list
+--------------------------------------+----------------+-----------+----------+------------------+-------------
| id | security_group | direction | protocol | remote_ip_prefix | remote_group
+--------------------------------------+----------------+-----------+----------+------------------+-------------
| 028aec88-15db-4aef-aa6d-0882468b393a | default | egress | | |
| 316c8156-a804-4181-8a06-0d470eaf2612 | default | ingress | | | default
| 33049251-7a67-4efd-88bd-06bf05d05896 | default | ingress | | | default
| 55250bab-777f-4519-a330-760fdaa2b9b9 | default | egress | | |
| 586ffa9b-fe17-4a16-8e9b-61cdc2097a01 | default | egress | | |
| 58d618c0-19a4-4b20-ba64-f8a393db8def | default | ingress | | | default
| 5b11d13c-7e5a-424c-8364-b199dc07ef3b | default | egress | | |
| b3ad9ac9-56b2-4786-acca-359ff292d5cd | default | ingress | | | default
+--------------------------------------+----------------+-----------+----------+------------------+-------------

But when I check with iptables, one can see they are filtering ports (e.g. bootps/bootpc):

:quantum-filter-top - [0:0]
:quantum-openvswi-FORWARD - [0:0]
:quantum-openvswi-INPUT - [0:0]
:quantum-openvswi-OUTPUT - [0:0]
:quantum-openvswi-iaa210549-d - [0:0]
:quantum-openvswi-local - [0:0]
:quantum-openvswi-oaa210549-d - [0:0]
:quantum-openvswi-sg-chain - [0:0]
:quantum-openvswi-sg-fallback - [0:0]
-A INPUT -j quantum-openvswi-INPUT
-A FORWARD -j quantum-filter-top
-A FORWARD -j quantum-openvswi-FORWARD
-A OUTPUT -j quantum-filter-top
-A OUTPUT -j quantum-openvswi-OUTPUT
-A quantum-filter-top -j quantum-openvswi-local
-A quantum-openvswi-FORWARD -m physdev --physdev-out tapaa210549-df --physdev-is-bridged -j quantum-openvswi-sg-chain
-A quantum-openvswi-FORWARD -m physdev --physdev-in tapaa210549-df --physdev-is-bridged -j quantum-openvswi-sg-chain
-A quantum-openvswi-INPUT -m physdev --physdev-in tapaa210549-df --physdev-is-bridged -j quantum-openvswi-oaa210549-d
-A quantum-openvswi-iaa210549-d -m state --state INVALID -j DROP
-A quantum-openvswi-iaa210549-d -m state --state RELATED,ESTABLISHED -j RETURN
-A quantum-openvswi-iaa210549-d -s 192.0.2.32/32 -p udp -m udp --sport 67 --dport 68 -j RETURN
-A quantum-openvswi-iaa210549-d -j quantum-openvswi-sg-fallback
-A quantum-openvswi-oaa210549-d -m mac ! --mac-source FA:16:3E:7F:4F:76 -j DROP
-A quantum-openvswi-oaa210549-d -p udp -m udp --sport 68 --dport 67 -j RETURN
-A quantum-openvswi-oaa210549-d ! -s 192.0.2.33/32 -j DROP
-A quantum-openvswi-oaa210549-d -p udp -m udp --sport 67 --dport 68 -j DROP
-A quantum-openvswi-oaa210549-d -m state --state INVALID -j DROP
-A quantum-openvswi-oaa210549-d -m state --state RELATED,ESTABLISHED -j RETURN
-A quantum-openvswi-oaa210549-d -j RETURN
-A quantum-openvswi-oaa210549-d -j quantum-openvswi-sg-fallback
-A quantum-openvswi-sg-chain -m physdev --physdev-out tapaa210549-df --physdev-is-bridged -j quantum-openvswi-iaa210549-d
-A quantum-openvswi-sg-chain -m physdev --physdev-in tapaa210549-df --physdev-is-bridged -j quantum-openvswi-oaa210549-d
-A quantum-openvswi-sg-chain -j ACCEPT
-A quantum-openvswi-sg-fallback -j DROP
COMMIT

[Aaron Rosen (arosen)]

That's intended if it's blank that means it's a wild carded. By default all egress traffic is allowed and ingress traffic is allowed only from ports that are part of the same security group.

[Robert Collins (lifeless)]

Uhm, but its not wildcarded. See the iptables dump.

[Nachi Ueno (nati-ueno)]

Hi Robert

basically it is blank except some spoof preventing rules.

-A quantum-openvswi-oaa210549-d -m mac ! --mac-source FA:16:3E:7F:4F:76 -j DROP <-- prevents mac spoofing
-A quantum-openvswi-oaa210549-d -p udp -m udp --sport 68 --dport 67 -j RETURN <-- allow DHCP request
-A quantum-openvswi-oaa210549-d ! -s 192.0.2.33/32 -j DROP <-- prevents ip spoofing
-A quantum-openvswi-oaa210549-d -p udp -m udp --sport 67 --dport 68 -j DROP <-- prevents DHCP spoof

[Robert Collins (lifeless)]

Sure, I appreciate what the rules do - but the security-group-rule-list is showing no details, and the rules that are there are not described usefully. The port lists for DHCP in and out for instance, should be shown, but aren't. The IP addresses are wildcard for the most part - but not on the ip spoofing rule. So I don't understand why they shouldn't be shown in a useful manner.

[Aaron Rosen (arosen)]

Hi Robert,

I think the issue is that the python-quantumclient isn't printing ethertype for example if you do this it looks more clear what the rules do:

http://codepad.org/T9sichU8

Currently security groups allow all dhcp traffic in. I agree this is not ideal but this is the same way security groups were done in nova so we choose to do the same (sure we should probably change this).

The second thing is that in order to use security groups you need ip spoofing enabled. The reason for this is if ip spoofing was not enabled an instance could change it's source ip in order to get around a security group rule. IMO displaying the ip spoofing rules does us no good.

[Robert Collins (lifeless)]

Two things I guess show up here; the default rendering of security-group-rule-list is confusing. I'll retitle this. I think we should show more detail by default - or at least indicate there *is* more detail to show.

Secondly, ip spoofing is definitely important - but we can modify the DHCP rule like so:

-A quantum-openvswi-oaa210549-d -m mac --mac-source FA:16:3E:7F:4F:76 -s 0.0.0.0/32 -p udp -m udp --sport 68 --dport 67 -j RETURN

To be more tight: 0.0.0.0/32 is the address for DHCP requests; only that and the assigned address may be used.

[Robert Collins (lifeless)]

(Should I file a second bug about tightening up that rule?

[Aaron Rosen (arosen)]

I think that would be best to track this as a seperate issue.

[Akihiro Motoki (amotoki)]

The first thing is related to python-quantumclient. I will add python-quantumclient to this bug.

I agree it is useful if we have some information which indicates there's more detail.
Another option is to display rule list in more summarized way. One way is to merge ethertype/protocol/port_range_min/max into one field, for example: "IPv4;1000-1999/udp".

Regarding the second point, specifying the source MAC actually changes nothing since a rule preventing source mac spoofing is evaluated before DHCP request allow rule, but it is better to add the source mac since the rules becomes more robust (e.g., we can consider a case where there is no rule for source mac spoofing).

[Akihiro Motoki (amotoki)]

The second point is filed as neutron bug (bug 1427054).
It needs to be discussed in Neutron side.

Now this bug focuses on the first point:
security-group-rule-list does not show all information returned from the API.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/160770

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/160770
Committed: https://git.openstack.org/cgit/openstack/python-neutronclient/commit/?id=4829e25b6a68df0372a3b84c3cc7c9b680ced669
Submitter: Jenkins
Branch: master

commit 4829e25b6a68df0372a3b84c3cc7c9b680ced669
Author: Akihiro Motoki <email address hidden>
Date: Sun Mar 1 19:37:40 2015 +0900

    security-group-rule-list: show all info of rules briefly

    Previously security-group-rule-list does not display full
    information of rules by default (e.g., port ranges, ether types)
    and users need to use security-group-rule-show to check details.
    It is not convenient.

    This commit introduces some aggregated columns ("protocol/port" and
    "remote") to show infomration briefly and as a result full attributes
    of rules will be displayed.

    Closes-Bug: #1182629
    Change-Id: I047bf9a1ccba5b023d66f22ef5256f7786196113