cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sanjeev N <sanj...@apache.org>
Subject Re: [Blocker] Default ip table rules on VR
Date Mon, 03 Aug 2015 09:38:00 GMT
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 <sanjeev@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 <sanjeev@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: <dev@cloudstack.apache.org> <dev@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 <daan.hoogland@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 <sanjeev@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
> >>>>>
> >>>>
> >>>>
> >>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message