Mailinglist Archive: opensuse-security (26 mails)

< Previous Next >
Re: _ Re: [opensuse-security] packet labeling & routing decision based on these labels
  • From: Dirk Schreiner <Dirk.Schreiner@xxxxxxx>
  • Date: Mon, 16 Jul 2007 17:21:14 +0200
  • Message-id: <469B8CEA.4090008@xxxxxxx>
Hi,

Philipp Snizek schrieb:
>> Philipp Snizek schrieb:
>>     
>>>> On Monday 16 July 2007 15:17:53 Philipp Snizek wrote:
>>>>
>>>>         
>>>>> Hi
>>>>>
>>>>> I have this scenario:
>>>>>
>>>>> Subnet A
>>>>> Hosts n  ----- Gateway ----- Fileservers NFS
>>>>>
>>>>> Hosts n: mark packets
>>>>> Gateway: uses mark to make routing desicion
>>>>>           
>>>>> [...]
>>>>>           
>>>>> Or how would you do it?
>>>>>
>>>>> Thanks for your attention
>>>>>
>>>>>           
>>>> Hi,
>>>>
>>>> How are you using the marks? If a client can spoof the IP and MAC
>>>> address,
>>>> it
>>>> could do so with the marks too.
>>>>
>>>>         
>>> Yes, it could, but then the attacker somehow has to learn what the mark
>>> looks like. If the attacker doesn't know the gateway will notice the
>>> spoofing with the first incoming packet. And thus, alerting the spoofing
>>> will not be a problem anymore.
>>> The only way I can think of would be a man-in-the-middle attack (e.g.
>>> with
>>> a notebook that has 2 interfaces set up as a linux bridge).
>>>
>>>       
>> Which is not too difficult.
>>     
>
> No, it isn't.
>
>   
>>> I also thought about using SECMARK with SELinux but that is too much of
>>> a
>>> pain and therefore too expensive to build. Also, I do not know whether
>>> SECMARK painted packets are painted permanently.
>>>
>>>
>>>       
>>>> Securing your network from MAC or IP address spoofing may be done by
>>>> configuring the switches (if they are manageble, of course) - for
>>>> example
>>>> by
>>>> staticly assigning allowed MAC addresses on specific switch ports. If a
>>>> malicious client can connect to your network and spoof a valid identity
>>>> it
>>>> is
>>>>
>>>>         
>> This is not working! Every Script Kiddie can fake MAC-Addresses.
>>     
>
> ACK
>
>   
>> If you want to leave Security to the Switch use 802.1x Port based
>> Authentication
>> with a secure Protocol.
>>     
>
> Yes. That would help it and also stop man in the middle at least between
> the switch and the Hosts n.
> have you got experience what performance impact 802.1x has on 1GBit/s
> ethernet?
>
>   

As i understand 802.1x you can use it to only authenticate the Client,
Traffic unencrypted, which should be no real Performance Impact.
(And maybe thats enough for you.)

If you want to encrypt the whole Communication, the Performance
Impact on the Network itself will also be not too much harm.
Performance Impact is mainly caused in KeyNegotiation, which ist
normaly done every 5 Minutes for every Connection.
You can set a longer Time, which will be less secure, but anyway,
fare more secure as clear Text. You will need some CPU for KeyNegotiation,
and little CPU for shifting and xor-ing Payload.

Just compare it as HTTP to HTTPS, but more effective due to the
long term connections.


Maybe this Link helps.
http://iase.disa.mil/stigs/whitepaper/802.1x_primer.doc

>   
>>>> already too late to secure protocols like NFS, which are not designed
>>>> to
>>>> be
>>>> used on an insecure network.
>>>>
>>>>         
>>> This is the design flaw in the network that currently cannot be fixed.
>>> That is also why I'm coming up with the idea of marking the packets.
>>>
>>>       
>> If you have control  over Client and Server, why not using AFS instead
>> of NFS?
>> AFS supports strong authentication and _encryption_ of transported Data.
>>     
>
> Because we use AFS and we know abouts its security features. However,
> experiences show that it never has been working really reliably. Imagine
> that Hosts n may be several hundred machines most probably mounting more
> than a total of 2000 NFS shares. Even NFS3 has a problem with this sort of
> load. We thought about using NFS4 but other colleagues made bad
> experiences. The last alternative would be Samba and CIFS.
>
> But that's all too much work.
>
> Philipp
>
>   
Nice Environment. ;-)

Dirk


>
>
>   
>> Dirk
>>
>>     
>>> Thanks,
>>> PHilipp
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: opensuse-security+unsubscribe@xxxxxxxxxxxx
>>> <mailto:opensuse-security+unsubscribe@xxxxxxxxxxxx>
>>> For additional commands, e-mail: opensuse-security+help@xxxxxxxxxxxx
>>> <mailto:opensuse-security+help@xxxxxxxxxxxx>
>>>
>>>
>>>       
>> --
>>
>> TRIA IT-consulting GmbH
>> Joseph-Wild-Straße 20
>> 81829 München
>> Germany
>> Tel: +49 (89) 92907-0
>> Fax: +49 (89) 92907-100
>http://www.tria.de
>>
>> Registergericht München HRB 113466
>> USt.-IdNr. DE 180017238 Steuer-Nr. 802/40600
>> Geschäftsführer: Rosa Igl
>>
>> --------------------------------------------------------------------------------
>> Nachricht von: Dirk.Schreiner@xxxxxxx
>> Nachricht an: opensuse-security@xxxxxxxxxxxx
>> # Dateianhänge: 0
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: opensuse-security+unsubscribe@xxxxxxxxxxxx
>> For additional commands, e-mail: opensuse-security+help@xxxxxxxxxxxx
>>
>>
>>     
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: opensuse-security+unsubscribe@xxxxxxxxxxxx
> For additional commands, e-mail: opensuse-security+help@xxxxxxxxxxxx
>
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-security+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-security+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups
References