You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Wilder Rodrigues <WR...@schubergphilis.com> on 2015/08/03 11:30:21 UTC
Re: [Blocker] Default ip table rules on VR
Hi Sanjeev,
I added some comments to the issue on Jira, but will share it here as well since not many people are watching the issue:
I updated the CsAddress.py file and deployed a KVM datacenter, with new agent/common RPM packages. The router has now INPUT/FORWARD with DROP instead of ACCEPT.
However, it seems to block communication with the host, since the router stays stuck on "starting" state on ACS management server.
I managed to access the router via libvirt console command. See details below:
[root@kvm2 ~]# virsh console 4
Connected to domain r-4-VM
Escape character is ^]
root@r-4-VM:~# iptables --list
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere tcp dpt:10086
NETWORK_STATS all -- anywhere anywhere
ACCEPT all -- anywhere vrrp.mcast.net
ACCEPT all -- anywhere 225.0.0.50
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT icmp -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere vrrp.mcast.net
ACCEPT all -- anywhere 225.0.0.50
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT icmp -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT udp -- anywhere anywhere udp dpt:bootps
ACCEPT udp -- anywhere anywhere udp dpt:domain
ACCEPT tcp -- anywhere anywhere tcp dpt:domain
ACCEPT tcp -- anywhere anywhere tcp dpt:http state NEW
ACCEPT tcp -- anywhere anywhere tcp dpt:http-alt state NEW
Chain FORWARD (policy DROP)
target prot opt source destination
NETWORK_STATS all -- anywhere anywhere
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere state NEW
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
NETWORK_STATS all -- anywhere anywhere
Chain NETWORK_STATS (3 references)
target prot opt source destination
all -- anywhere anywhere
all -- anywhere anywhere
tcp -- anywhere anywhere
tcp -- anywhere anywhere
root@r-4-VM:~#
I will compare the new iptables configuration with the old iptables-vpcrouter/iptables-router files.
Cheers,
Wilder
> On 31 Jul 2015, at 06:03, Sanjeev N <sa...@apache.org> wrote:
>
> Thanks for working on it Wilder !!
>
> On Thu, Jul 30, 2015 at 6:05 PM, Wilder Rodrigues <
> WRodrigues@schubergphilis.com> wrote:
>
>> Hi,
>>
>> We discussed that one yesterday and I already assigned the issue to myself
>> on Jira. I will fix it.
>>
>> Cheers,
>> WIlder
>>
>>
>>
>>> On 30 Jul 2015, at 14:09, Sanjeev N <sa...@apache.org> wrote:
>>>
>>> Agree with Kishan Kavala and Jayapal.
>>>
>>> On Thu, Jul 30, 2015 at 2:13 PM, Kishan Kavala <Kishan.Kavala@citrix.com
>>>
>>> wrote:
>>>
>>>> This is a security issue with high impact.
>>>> We should treat it as a blocker.
>>>>
>>>> -----Original Message-----
>>>> From: Jayapal Reddy Uradi [mailto:jayapalreddy.uradi@citrix.com]
>>>> Sent: 30 July 2015 02:07 PM
>>>> To: <de...@cloudstack.apache.org> <de...@cloudstack.apache.org>
>>>> Subject: Re: [Blocker] Default ip table rules on VR
>>>>
>>>> I see VR ingress traffic is blocked by default from iptables mangle
>> table.
>>>> But on the guest interface all the traffic is accepted.
>>>> Also egress firewall rule will break because of FORWARD policy.
>>>>
>>>> Thanks,
>>>> Jayapal
>>>>
>>>> On 30-Jul-2015, at 12:53 PM, Jayapal Reddy Uradi <
>>>> jayapalreddy.uradi@citrix.com> wrote:
>>>>
>>>>>
>>>>> It is security concern on the VR. All the ingress traffic onto the VR
>> is
>>>> accepted.
>>>>> Let it be blocker.
>>>>>
>>>>> Thanks,
>>>>> Jayapal
>>>>>
>>>>> On 30-Jul-2015, at 12:28 PM, Daan Hoogland <da...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> I changed it to critical. It is only a blocker if we agree on this
>>>>>> list that it is.
>>>>>>
>>>>>> On Thu, Jul 30, 2015 at 6:44 AM, Sanjeev N <sa...@apache.org>
>> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> In latest ACS builds, the ip table rules in VR have ACCEPT as the
>>>>>>> default policy in INPUT and FORWARD chains, instead of DROP.
>>>>>>>
>>>>>>> Created a blocker bug for this issue
>>>>>>> https://issues.apache.org/jira/browse/CLOUDSTACK-8688
>>>>>>>
>>>>>>> Can somebody please fix it?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Sanjeev
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Daan
>>>>>
>>>>
>>>>
>>
>>
Re: [Blocker] Default ip table rules on VR
Posted by Wilder Rodrigues <WR...@schubergphilis.com>.
HI,
VPC routers (used by single and redundant VPCs) already fixed. Now testing shared/isolated routers.
PR will be available in a few hours.
Cheers,
Wilder
> On 03 Aug 2015, at 11:47, Wilder Rodrigues <WR...@schubergphilis.com> wrote:
>
> Yep… that bit I know and it was already in the code.
>
>
> What I just found out was that the DROP was put before there, in a probably first run of the code. What I changed now was to have the DROP added only after the control nic is configured. It should work, but I still need to test it - new RPMs, etc.
>
> I’m now looking for the place where the port 3922 is added in the case of a VPC router.
>
> Hope to get it working still today so I can create a PR.
>
> Cheers,
> Wilder
>
>
>> On 03 Aug 2015, at 11:38, Sanjeev N <sa...@apache.org> wrote:
>>
>> I think we need to allow tcp port 3922 in INPUT chain for the host to ssh
>> to VR.
>>
>> On Mon, Aug 3, 2015 at 3:00 PM, Wilder Rodrigues <
>> WRodrigues@schubergphilis.com> wrote:
>>
>>> Hi Sanjeev,
>>>
>>> I added some comments to the issue on Jira, but will share it here as well
>>> since not many people are watching the issue:
>>>
>>> I updated the CsAddress.py file and deployed a KVM datacenter, with new
>>> agent/common RPM packages. The router has now INPUT/FORWARD with DROP
>>> instead of ACCEPT.
>>>
>>> However, it seems to block communication with the host, since the router
>>> stays stuck on "starting" state on ACS management server.
>>>
>>> I managed to access the router via libvirt console command. See details
>>> below:
>>>
>>> [root@kvm2 ~]# virsh console 4
>>> Connected to domain r-4-VM
>>> Escape character is ^]
>>>
>>> root@r-4-VM:~# iptables --list
>>> Chain INPUT (policy DROP)
>>> target prot opt source destination
>>> ACCEPT tcp -- anywhere anywhere tcp dpt:10086
>>> NETWORK_STATS all -- anywhere anywhere
>>> ACCEPT all -- anywhere vrrp.mcast.net
>>> ACCEPT all -- anywhere 225.0.0.50
>>> ACCEPT all -- anywhere anywhere state
>>> RELATED,ESTABLISHED
>>> ACCEPT icmp -- anywhere anywhere
>>> ACCEPT all -- anywhere anywhere
>>> ACCEPT all -- anywhere vrrp.mcast.net
>>> ACCEPT all -- anywhere 225.0.0.50
>>> ACCEPT all -- anywhere anywhere state
>>> RELATED,ESTABLISHED
>>> ACCEPT icmp -- anywhere anywhere
>>> ACCEPT all -- anywhere anywhere
>>> ACCEPT udp -- anywhere anywhere udp
>>> dpt:bootps
>>> ACCEPT udp -- anywhere anywhere udp
>>> dpt:domain
>>> ACCEPT tcp -- anywhere anywhere tcp
>>> dpt:domain
>>> ACCEPT tcp -- anywhere anywhere tcp dpt:http
>>> state NEW
>>> ACCEPT tcp -- anywhere anywhere tcp
>>> dpt:http-alt state NEW
>>>
>>> Chain FORWARD (policy DROP)
>>> target prot opt source destination
>>> NETWORK_STATS all -- anywhere anywhere
>>> ACCEPT all -- anywhere anywhere state
>>> RELATED,ESTABLISHED
>>> ACCEPT all -- anywhere anywhere state NEW
>>> ACCEPT all -- anywhere anywhere state
>>> RELATED,ESTABLISHED
>>> ACCEPT all -- anywhere anywhere state
>>> RELATED,ESTABLISHED
>>>
>>> Chain OUTPUT (policy ACCEPT)
>>> target prot opt source destination
>>> NETWORK_STATS all -- anywhere anywhere
>>>
>>> Chain NETWORK_STATS (3 references)
>>> target prot opt source destination
>>> all -- anywhere anywhere
>>> all -- anywhere anywhere
>>> tcp -- anywhere anywhere
>>> tcp -- anywhere anywhere
>>> root@r-4-VM:~#
>>>
>>> I will compare the new iptables configuration with the old
>>> iptables-vpcrouter/iptables-router files.
>>>
>>> Cheers,
>>> Wilder
>>>
>>>
>>>> On 31 Jul 2015, at 06:03, Sanjeev N <sa...@apache.org> wrote:
>>>>
>>>> Thanks for working on it Wilder !!
>>>>
>>>> On Thu, Jul 30, 2015 at 6:05 PM, Wilder Rodrigues <
>>>> WRodrigues@schubergphilis.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> We discussed that one yesterday and I already assigned the issue to
>>> myself
>>>>> on Jira. I will fix it.
>>>>>
>>>>> Cheers,
>>>>> WIlder
>>>>>
>>>>>
>>>>>
>>>>>> On 30 Jul 2015, at 14:09, Sanjeev N <sa...@apache.org> wrote:
>>>>>>
>>>>>> Agree with Kishan Kavala and Jayapal.
>>>>>>
>>>>>> On Thu, Jul 30, 2015 at 2:13 PM, Kishan Kavala <
>>> Kishan.Kavala@citrix.com
>>>>>>
>>>>>> wrote:
>>>>>>
>>>>>>> This is a security issue with high impact.
>>>>>>> We should treat it as a blocker.
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Jayapal Reddy Uradi [mailto:jayapalreddy.uradi@citrix.com]
>>>>>>> Sent: 30 July 2015 02:07 PM
>>>>>>> To: <de...@cloudstack.apache.org> <de...@cloudstack.apache.org>
>>>>>>> Subject: Re: [Blocker] Default ip table rules on VR
>>>>>>>
>>>>>>> I see VR ingress traffic is blocked by default from iptables mangle
>>>>> table.
>>>>>>> But on the guest interface all the traffic is accepted.
>>>>>>> Also egress firewall rule will break because of FORWARD policy.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Jayapal
>>>>>>>
>>>>>>> On 30-Jul-2015, at 12:53 PM, Jayapal Reddy Uradi <
>>>>>>> jayapalreddy.uradi@citrix.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> It is security concern on the VR. All the ingress traffic onto the VR
>>>>> is
>>>>>>> accepted.
>>>>>>>> Let it be blocker.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Jayapal
>>>>>>>>
>>>>>>>> On 30-Jul-2015, at 12:28 PM, Daan Hoogland <da...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> I changed it to critical. It is only a blocker if we agree on this
>>>>>>>>> list that it is.
>>>>>>>>>
>>>>>>>>> On Thu, Jul 30, 2015 at 6:44 AM, Sanjeev N <sa...@apache.org>
>>>>> wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> In latest ACS builds, the ip table rules in VR have ACCEPT as the
>>>>>>>>>> default policy in INPUT and FORWARD chains, instead of DROP.
>>>>>>>>>>
>>>>>>>>>> Created a blocker bug for this issue
>>>>>>>>>> https://issues.apache.org/jira/browse/CLOUDSTACK-8688
>>>>>>>>>>
>>>>>>>>>> Can somebody please fix it?
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Sanjeev
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Daan
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
Re: [Blocker] Default ip table rules on VR
Posted by Wilder Rodrigues <WR...@schubergphilis.com>.
Yep… that bit I know and it was already in the code.
What I just found out was that the DROP was put before there, in a probably first run of the code. What I changed now was to have the DROP added only after the control nic is configured. It should work, but I still need to test it - new RPMs, etc.
I’m now looking for the place where the port 3922 is added in the case of a VPC router.
Hope to get it working still today so I can create a PR.
Cheers,
Wilder
> On 03 Aug 2015, at 11:38, Sanjeev N <sa...@apache.org> wrote:
>
> I think we need to allow tcp port 3922 in INPUT chain for the host to ssh
> to VR.
>
> On Mon, Aug 3, 2015 at 3:00 PM, Wilder Rodrigues <
> WRodrigues@schubergphilis.com> wrote:
>
>> Hi Sanjeev,
>>
>> I added some comments to the issue on Jira, but will share it here as well
>> since not many people are watching the issue:
>>
>> I updated the CsAddress.py file and deployed a KVM datacenter, with new
>> agent/common RPM packages. The router has now INPUT/FORWARD with DROP
>> instead of ACCEPT.
>>
>> However, it seems to block communication with the host, since the router
>> stays stuck on "starting" state on ACS management server.
>>
>> I managed to access the router via libvirt console command. See details
>> below:
>>
>> [root@kvm2 ~]# virsh console 4
>> Connected to domain r-4-VM
>> Escape character is ^]
>>
>> root@r-4-VM:~# iptables --list
>> Chain INPUT (policy DROP)
>> target prot opt source destination
>> ACCEPT tcp -- anywhere anywhere tcp dpt:10086
>> NETWORK_STATS all -- anywhere anywhere
>> ACCEPT all -- anywhere vrrp.mcast.net
>> ACCEPT all -- anywhere 225.0.0.50
>> ACCEPT all -- anywhere anywhere state
>> RELATED,ESTABLISHED
>> ACCEPT icmp -- anywhere anywhere
>> ACCEPT all -- anywhere anywhere
>> ACCEPT all -- anywhere vrrp.mcast.net
>> ACCEPT all -- anywhere 225.0.0.50
>> ACCEPT all -- anywhere anywhere state
>> RELATED,ESTABLISHED
>> ACCEPT icmp -- anywhere anywhere
>> ACCEPT all -- anywhere anywhere
>> ACCEPT udp -- anywhere anywhere udp
>> dpt:bootps
>> ACCEPT udp -- anywhere anywhere udp
>> dpt:domain
>> ACCEPT tcp -- anywhere anywhere tcp
>> dpt:domain
>> ACCEPT tcp -- anywhere anywhere tcp dpt:http
>> state NEW
>> ACCEPT tcp -- anywhere anywhere tcp
>> dpt:http-alt state NEW
>>
>> Chain FORWARD (policy DROP)
>> target prot opt source destination
>> NETWORK_STATS all -- anywhere anywhere
>> ACCEPT all -- anywhere anywhere state
>> RELATED,ESTABLISHED
>> ACCEPT all -- anywhere anywhere state NEW
>> ACCEPT all -- anywhere anywhere state
>> RELATED,ESTABLISHED
>> ACCEPT all -- anywhere anywhere state
>> RELATED,ESTABLISHED
>>
>> Chain OUTPUT (policy ACCEPT)
>> target prot opt source destination
>> NETWORK_STATS all -- anywhere anywhere
>>
>> Chain NETWORK_STATS (3 references)
>> target prot opt source destination
>> all -- anywhere anywhere
>> all -- anywhere anywhere
>> tcp -- anywhere anywhere
>> tcp -- anywhere anywhere
>> root@r-4-VM:~#
>>
>> I will compare the new iptables configuration with the old
>> iptables-vpcrouter/iptables-router files.
>>
>> Cheers,
>> Wilder
>>
>>
>>> On 31 Jul 2015, at 06:03, Sanjeev N <sa...@apache.org> wrote:
>>>
>>> Thanks for working on it Wilder !!
>>>
>>> On Thu, Jul 30, 2015 at 6:05 PM, Wilder Rodrigues <
>>> WRodrigues@schubergphilis.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> We discussed that one yesterday and I already assigned the issue to
>> myself
>>>> on Jira. I will fix it.
>>>>
>>>> Cheers,
>>>> WIlder
>>>>
>>>>
>>>>
>>>>> On 30 Jul 2015, at 14:09, Sanjeev N <sa...@apache.org> wrote:
>>>>>
>>>>> Agree with Kishan Kavala and Jayapal.
>>>>>
>>>>> On Thu, Jul 30, 2015 at 2:13 PM, Kishan Kavala <
>> Kishan.Kavala@citrix.com
>>>>>
>>>>> wrote:
>>>>>
>>>>>> This is a security issue with high impact.
>>>>>> We should treat it as a blocker.
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Jayapal Reddy Uradi [mailto:jayapalreddy.uradi@citrix.com]
>>>>>> Sent: 30 July 2015 02:07 PM
>>>>>> To: <de...@cloudstack.apache.org> <de...@cloudstack.apache.org>
>>>>>> Subject: Re: [Blocker] Default ip table rules on VR
>>>>>>
>>>>>> I see VR ingress traffic is blocked by default from iptables mangle
>>>> table.
>>>>>> But on the guest interface all the traffic is accepted.
>>>>>> Also egress firewall rule will break because of FORWARD policy.
>>>>>>
>>>>>> Thanks,
>>>>>> Jayapal
>>>>>>
>>>>>> On 30-Jul-2015, at 12:53 PM, Jayapal Reddy Uradi <
>>>>>> jayapalreddy.uradi@citrix.com> wrote:
>>>>>>
>>>>>>>
>>>>>>> It is security concern on the VR. All the ingress traffic onto the VR
>>>> is
>>>>>> accepted.
>>>>>>> Let it be blocker.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Jayapal
>>>>>>>
>>>>>>> On 30-Jul-2015, at 12:28 PM, Daan Hoogland <da...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I changed it to critical. It is only a blocker if we agree on this
>>>>>>>> list that it is.
>>>>>>>>
>>>>>>>> On Thu, Jul 30, 2015 at 6:44 AM, Sanjeev N <sa...@apache.org>
>>>> wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> In latest ACS builds, the ip table rules in VR have ACCEPT as the
>>>>>>>>> default policy in INPUT and FORWARD chains, instead of DROP.
>>>>>>>>>
>>>>>>>>> Created a blocker bug for this issue
>>>>>>>>> https://issues.apache.org/jira/browse/CLOUDSTACK-8688
>>>>>>>>>
>>>>>>>>> Can somebody please fix it?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Sanjeev
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Daan
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
Re: [Blocker] Default ip table rules on VR
Posted by Sanjeev N <sa...@apache.org>.
I think we need to allow tcp port 3922 in INPUT chain for the host to ssh
to VR.
On Mon, Aug 3, 2015 at 3:00 PM, Wilder Rodrigues <
WRodrigues@schubergphilis.com> wrote:
> Hi Sanjeev,
>
> I added some comments to the issue on Jira, but will share it here as well
> since not many people are watching the issue:
>
> I updated the CsAddress.py file and deployed a KVM datacenter, with new
> agent/common RPM packages. The router has now INPUT/FORWARD with DROP
> instead of ACCEPT.
>
> However, it seems to block communication with the host, since the router
> stays stuck on "starting" state on ACS management server.
>
> I managed to access the router via libvirt console command. See details
> below:
>
> [root@kvm2 ~]# virsh console 4
> Connected to domain r-4-VM
> Escape character is ^]
>
> root@r-4-VM:~# iptables --list
> Chain INPUT (policy DROP)
> target prot opt source destination
> ACCEPT tcp -- anywhere anywhere tcp dpt:10086
> NETWORK_STATS all -- anywhere anywhere
> ACCEPT all -- anywhere vrrp.mcast.net
> ACCEPT all -- anywhere 225.0.0.50
> ACCEPT all -- anywhere anywhere state
> RELATED,ESTABLISHED
> ACCEPT icmp -- anywhere anywhere
> ACCEPT all -- anywhere anywhere
> ACCEPT all -- anywhere vrrp.mcast.net
> ACCEPT all -- anywhere 225.0.0.50
> ACCEPT all -- anywhere anywhere state
> RELATED,ESTABLISHED
> ACCEPT icmp -- anywhere anywhere
> ACCEPT all -- anywhere anywhere
> ACCEPT udp -- anywhere anywhere udp
> dpt:bootps
> ACCEPT udp -- anywhere anywhere udp
> dpt:domain
> ACCEPT tcp -- anywhere anywhere tcp
> dpt:domain
> ACCEPT tcp -- anywhere anywhere tcp dpt:http
> state NEW
> ACCEPT tcp -- anywhere anywhere tcp
> dpt:http-alt state NEW
>
> Chain FORWARD (policy DROP)
> target prot opt source destination
> NETWORK_STATS all -- anywhere anywhere
> ACCEPT all -- anywhere anywhere state
> RELATED,ESTABLISHED
> ACCEPT all -- anywhere anywhere state NEW
> ACCEPT all -- anywhere anywhere state
> RELATED,ESTABLISHED
> ACCEPT all -- anywhere anywhere state
> RELATED,ESTABLISHED
>
> Chain OUTPUT (policy ACCEPT)
> target prot opt source destination
> NETWORK_STATS all -- anywhere anywhere
>
> Chain NETWORK_STATS (3 references)
> target prot opt source destination
> all -- anywhere anywhere
> all -- anywhere anywhere
> tcp -- anywhere anywhere
> tcp -- anywhere anywhere
> root@r-4-VM:~#
>
> I will compare the new iptables configuration with the old
> iptables-vpcrouter/iptables-router files.
>
> Cheers,
> Wilder
>
>
> > On 31 Jul 2015, at 06:03, Sanjeev N <sa...@apache.org> wrote:
> >
> > Thanks for working on it Wilder !!
> >
> > On Thu, Jul 30, 2015 at 6:05 PM, Wilder Rodrigues <
> > WRodrigues@schubergphilis.com> wrote:
> >
> >> Hi,
> >>
> >> We discussed that one yesterday and I already assigned the issue to
> myself
> >> on Jira. I will fix it.
> >>
> >> Cheers,
> >> WIlder
> >>
> >>
> >>
> >>> On 30 Jul 2015, at 14:09, Sanjeev N <sa...@apache.org> wrote:
> >>>
> >>> Agree with Kishan Kavala and Jayapal.
> >>>
> >>> On Thu, Jul 30, 2015 at 2:13 PM, Kishan Kavala <
> Kishan.Kavala@citrix.com
> >>>
> >>> wrote:
> >>>
> >>>> This is a security issue with high impact.
> >>>> We should treat it as a blocker.
> >>>>
> >>>> -----Original Message-----
> >>>> From: Jayapal Reddy Uradi [mailto:jayapalreddy.uradi@citrix.com]
> >>>> Sent: 30 July 2015 02:07 PM
> >>>> To: <de...@cloudstack.apache.org> <de...@cloudstack.apache.org>
> >>>> Subject: Re: [Blocker] Default ip table rules on VR
> >>>>
> >>>> I see VR ingress traffic is blocked by default from iptables mangle
> >> table.
> >>>> But on the guest interface all the traffic is accepted.
> >>>> Also egress firewall rule will break because of FORWARD policy.
> >>>>
> >>>> Thanks,
> >>>> Jayapal
> >>>>
> >>>> On 30-Jul-2015, at 12:53 PM, Jayapal Reddy Uradi <
> >>>> jayapalreddy.uradi@citrix.com> wrote:
> >>>>
> >>>>>
> >>>>> It is security concern on the VR. All the ingress traffic onto the VR
> >> is
> >>>> accepted.
> >>>>> Let it be blocker.
> >>>>>
> >>>>> Thanks,
> >>>>> Jayapal
> >>>>>
> >>>>> On 30-Jul-2015, at 12:28 PM, Daan Hoogland <da...@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>>> I changed it to critical. It is only a blocker if we agree on this
> >>>>>> list that it is.
> >>>>>>
> >>>>>> On Thu, Jul 30, 2015 at 6:44 AM, Sanjeev N <sa...@apache.org>
> >> wrote:
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> In latest ACS builds, the ip table rules in VR have ACCEPT as the
> >>>>>>> default policy in INPUT and FORWARD chains, instead of DROP.
> >>>>>>>
> >>>>>>> Created a blocker bug for this issue
> >>>>>>> https://issues.apache.org/jira/browse/CLOUDSTACK-8688
> >>>>>>>
> >>>>>>> Can somebody please fix it?
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Sanjeev
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Daan
> >>>>>
> >>>>
> >>>>
> >>
> >>
>
>