Am 05.06.2014 07:44, schrieb Alexandre DERUMIER:
>
>>> something like:
>>>
>>> -A tap100i0-OUT -m mac ! --mac-source 0E:0B:38:B8:B3:21 -j DROP # we
>>> already have this
>>> -A tap100i0-OUT --m set ! --match-set PVEFW-100-allowed-ips src -J DROP
>
> I can make a patch if you want.
Would be
Am 04.06.2014 17:24, schrieb Dietmar Maurer:
> I am unable to apply this patch:
>
> error: patch failed: debian/patches/series:28
> error: debian/patches/series: patch does not apply
> Patch failed at 0001 fix another aio bug
> 0001-aio-fix-qemu_bh_schedule-bh-ctx-race-condition.patch
>
>
my f
Signed-off-by: Stefan Priebe
---
...ix-qemu_bh_schedule-bh-ctx-race-condition.patch | 55
debian/patches/series |1 +
2 files changed, 56 insertions(+)
create mode 100644
debian/patches/0001-aio-fix-qemu_bh_schedule-bh-ctx-race-condition.
>>something like:
>>
>>-A tap100i0-OUT -m mac ! --mac-source 0E:0B:38:B8:B3:21 -j DROP # we already
>>have this
>>-A tap100i0-OUT --m set ! --match-set PVEFW-100-allowed-ips src -J DROP
I can make a patch if you want.
- Mail original -
De: "Dietmar Maurer"
À: "Stefan Priebe - Pro
I am unable to apply this patch:
error: patch failed: debian/patches/series:28
error: debian/patches/series: patch does not apply
Patch failed at 0001 fix another aio bug
0001-aio-fix-qemu_bh_schedule-bh-ctx-race-condition.patch
___
pve-devel mailing
> > The 'allowed_ips' ipset idea is very easy to implement ...
> >
>
> OK so adding option IP to each netX.
No, I talk about an IPSet defined inside the .fw file.
> Just don't know how to implement the
> firewall rule to only allow packets from this MAC and IP combination.
something like:
-A t
Am 04.06.2014 14:19, schrieb Dietmar Maurer:
>> I'm just afraid about the current situation which has no security at all. So
>> everybody can configure any ip he wants and send packets with it.
>
> The 'allowed_ips' ipset idea is very easy to implement ...
>
OK so adding option IP to each netX.
Am 04.06.2014 14:19, schrieb Dietmar Maurer:
>>> The attacker is inside the VM.
>>>
>> inside the VM where your DHCP live?
>
> no, inside a VM which used dhcp.
That doesn't matter. Normally you don't accept DHCP replies from this VM
only requests.
>> Then he already has control over all your DHC
> > The attacker is inside the VM.
> >
> inside the VM where your DHCP live?
no, inside a VM which used dhcp.
> Then he already has control over all your DHCP network.
Besides, we need to handle security for VM which does not use DHCP at all,
so this does not really help.
___
> I'm just afraid about the current situation which has no security at all. So
> everybody can configure any ip he wants and send packets with it.
The 'allowed_ips' ipset idea is very easy to implement ...
___
pve-devel mailing list
pve-devel@pve.proxmox
Am 04.06.2014 14:13, schrieb Dietmar Maurer:
>>> What happen in case of a malicious hacker, which send false dhcp response
>> over the network ?
>>
>> Where / at which point? Normally you have a trusted MAC and IP for DHCP
>> Server.
>>
>> Then on the switches itself you also use DHCP Snooping. So
> > What happen in case of a malicious hacker, which send false dhcp response
> over the network ?
>
> Where / at which point? Normally you have a trusted MAC and IP for DHCP
> Server.
>
> Then on the switches itself you also use DHCP Snooping. So how could an
> attacker send wrong packets throug
Am 04.06.2014 13:58, schrieb Alexandre DERUMIER:
>>> There's also:
>>> https://github.com/michael-dev/ebtables-dhcpsnooping/
>>>
>>> which monitors simply the dhcp traffic and automatically add the
>>> relevant rules to ebtables.
>
> What happen in case of a malicious hacker, which send false
>>There's also:
>>https://github.com/michael-dev/ebtables-dhcpsnooping/
>>
>>which monitors simply the dhcp traffic and automatically add the
>>relevant rules to ebtables.
What happen in case of a malicious hacker, which send false dhcp response over
the network ?
- Mail original -
> > I think it depend how do you want to manage security.
> > Do you want that only superadmin specify ip/mac allowed for example ?
> > in this case, maybe in a external config is better.
>
> I think if someone is allowed to configure network devices, he should also be
> able to assign IPs.
In fu
> I think it depend how do you want to manage security.
> Do you want that only superadmin specify ip/mac allowed for example ?
> in this case, maybe in a external config is better.
I think if someone is allowed to configure network devices, he should also be
able to assign IPs.
_
> which monitors simply the dhcp traffic and automatically add the relevant
> rules
> to ebtables.
And what if there is no dhcp traffic (manually configured ip)?
BTW, I will be out of office till next Tuesday, and will not have internet
access all the time...
___
Am 04.06.2014 13:39, schrieb Alexandre DERUMIER:
>>> But dietmar correctly comments on how do we know the IP. Or just as a
>>> textfield set in the creation wizard? Makes this sence.
>
> I think it depend how do you want to manage security.
> Do you want that only superadmin specify ip/mac allowed
>>But dietmar correctly comments on how do we know the IP. Or just as a
>>textfield set in the creation wizard? Makes this sence.
I think it depend how do you want to manage security.
Do you want that only superadmin specify ip/mac allowed for example ?
in this case, maybe in a external config is
Am 04.06.2014 13:10, schrieb Alexandre DERUMIER:
> net0: e1000=0E:0B:38:B8:B3:21,bridge=vmbr0,firewall=1,ip=192.168.2.3
> It is then easy to implement such filter.
>>
>> also a good idea.
>>
>> Alexandre - any suggestions?
>
> I like this one ;) also, could be use when we'll implement
net0: e1000=0E:0B:38:B8:B3:21,bridge=vmbr0,firewall=1,ip=192.168.2.3
It is then easy to implement such filter.
>
>also a good idea.
>
>Alexandre - any suggestions?
I like this one ;) also, could be use when we'll implement dhcp server inside
proxmox.
- Mail original -
De
> For snooping there is no ip list neeeded. You just monitor DHCP ACK packets
> from specific MAC and IP and then generate the entries.
How do you do that if you do not know the IP?
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox
>> net0: e1000=0E:0B:38:B8:B3:21,bridge=vmbr0,firewall=1,ip=192.168.2.3
>> It is then easy to implement such filter.
also a good idea.
Alexandre - any suggestions?
Am 04.06.2014 12:19, schrieb Stefan Priebe - Profihost AG:
> Am 04.06.2014 12:10, schrieb Dietmar Maurer:
>>> i'm starting to deplo
Am 04.06.2014 12:10, schrieb Dietmar Maurer:
>> i'm starting to deploy the pve-firewall code on a test cluster.
>>
>> Something i really would like to have is dhcp snooping on the linux bridge
>> so that
>> VMs controlled by somebody else can't use fake / wrong ip adresses.
>>
>> Is something like
> > Is something like this possible with the current firewall code?
>
> Not implemented, because we do not have/store a list of IPs.
>
> One option would be to store the list of allowed IP in the VM network config:
>
> net0: e1000=0E:0B:38:B8:B3:21,bridge=vmbr0,firewall=1,ip=192.168.2.3
>
> It
> i'm starting to deploy the pve-firewall code on a test cluster.
>
> Something i really would like to have is dhcp snooping on the linux bridge so
> that
> VMs controlled by somebody else can't use fake / wrong ip adresses.
>
> Is something like this possible with the current firewall code?
No
Hi,
i'm starting to deploy the pve-firewall code on a test cluster.
Something i really would like to have is dhcp snooping on the linux
bridge so that VMs controlled by somebody else can't use fake / wrong ip
adresses.
Is something like this possible with the current firewall code?
Stefan
_
Am 04.06.2014 11:17, schrieb Dietmar Maurer:
>>> Do you talk about add/remove a CDROM device, or changing/eject CDROM
>> media?
>>>
>>
>> add remove a cdrom device. Adding is possible but removing isn't.
>
> I think adding a device should not be possible?
>
It depends - i think adding a cdrom i
> > Do you talk about add/remove a CDROM device, or changing/eject CDROM
> media?
> >
>
> add remove a cdrom device. Adding is possible but removing isn't.
I think adding a device should not be possible?
___
pve-devel mailing list
pve-devel@pve.proxmox
Am 04.06.2014 11:13, schrieb Dietmar Maurer:
>> currently adding a new CDROM is allowed if you have VM.Config.CDROM rights.
>> But you can't delete it with these rights.
>>
>> You get an exception regarding missing VM.Config.Disk rights.
>>
>> Is this correct?
>
> Do you talk about add/remove a CD
> currently adding a new CDROM is allowed if you have VM.Config.CDROM rights.
> But you can't delete it with these rights.
>
> You get an exception regarding missing VM.Config.Disk rights.
>
> Is this correct?
Do you talk about add/remove a CDROM device, or changing/eject CDROM media?
_
Signed-off-by: Stefan Priebe
---
...ix-qemu_bh_schedule-bh-ctx-race-condition.patch | 55
debian/patches/series |1 +
2 files changed, 56 insertions(+)
create mode 100644
debian/patches/0001-aio-fix-qemu_bh_schedule-bh-ctx-race-condition.
Am 04.06.2014 11:07, schrieb Dietmar Maurer:
>> so everything is forced to be encrypted otherwise the browser won't load it
>
> AFAIK we always encrypt anyways, so what it the advantage?
>
> Also, we use self-signed certificates by default.
>
Was just an idea - to be sure that everything is alw
> so everything is forced to be encrypted otherwise the browser won't load it
AFAIK we always encrypt anyways, so what it the advantage?
Also, we use self-signed certificates by default.
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.p
Am 04.06.2014 10:55, schrieb Dietmar Maurer:
>> wouldn't it make sense if pveproxy generally set the
>> Strict-Transport-Security
>> Header?
>
> Why?
>
so everything is forced to be encrypted otherwise the browser won't load it
___
pve-devel mailing l
> wouldn't it make sense if pveproxy generally set the Strict-Transport-Security
> Header?
Why?
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Hi,
wouldn't it make sense if pveproxy generally set the
Strict-Transport-Security Header?
--
Stefan
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
37 matches
Mail list logo
