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

Bug #1182629 reported by Robert Collins
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
python-neutronclient
Fix Released
Medium
Akihiro Motoki

Bug Description

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

Tags: sg-fw
Revision history for this message
Aaron Rosen (arosen) wrote :

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.

Changed in quantum:
status: New → Invalid
Revision history for this message
Robert Collins (lifeless) wrote :

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

Changed in quantum:
status: Invalid → New
Revision history for this message
Nachi Ueno (nati-ueno) wrote :

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

Revision history for this message
Robert Collins (lifeless) wrote :

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)
tags: added: sg-fw
Revision history for this message
Aaron Rosen (arosen) wrote :

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.

Changed in quantum:
status: New → Incomplete
Changed in quantum:
status: Incomplete → New
Revision history for this message
Robert Collins (lifeless) wrote :

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.

summary: - security group rule listing doesn't show details
+ security group rule listing doesn't show details by default : causes
+ user confusion
Revision history for this message
Robert Collins (lifeless) wrote :

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

Revision history for this message
Aaron Rosen (arosen) wrote :

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

Revision history for this message
Akihiro Motoki (amotoki) wrote :

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

Changed in python-quantumclient:
status: New → Confirmed
no longer affects: neutron
Revision history for this message
Akihiro Motoki (amotoki) wrote :

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.

Changed in python-neutronclient:
importance: Undecided → Medium
assignee: nobody → Akihiro Motoki (amotoki)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to python-neutronclient (master)

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

Changed in python-neutronclient:
status: Confirmed → In Progress
Kyle Mestery (mestery)
Changed in python-neutronclient:
milestone: none → 2.3.12
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to python-neutronclient (master)

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

Changed in python-neutronclient:
status: In Progress → Fix Committed
Kyle Mestery (mestery)
Changed in python-neutronclient:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.