Re: fajlrendszer titkositas

2016-01-22 bef zés Zs 

Hi!


Ami meg eszembe jutott: lvm-mel egyutt kell tudnia mukodni,
legalabb az online meretnoveles mukodjon.

Az LV-n található block device-t kell titkosítani, és menni fog a bövítés.

Es egy snapshot is csak a titkositott eszkozt fogja
"lefenykepezni", ugye? Tehat jelszo nelkul az sem lesz olvashato?

A snapshot arról a tartalomról készít pillanatképet, ami a snapshot
elkövetésének pillanatában van. Mivel a volume titkosított, minden,
ami az LV-re íródna, előbb átmegy a titkosító eljáráson, ezért a
snapshot csak a titkosított állapotról tud pillanatképet készíteni.
Az egyszavas válasz tehát: igen. :-)

Ezzel együtt az egy jó kérdés, hogy jelszóval olvasható lesz-e
egyáltalán, ugyanis a titkosító modulok is szeretik bejegyezni, hogy
a kötet épp meg van nyitva. Namost a snapshot erősen read only,
kérdés tehát, hogy erre mit lép pl. egy cryptsetup?
Mindezzel együtt ha valamit muszáj, akkor muszáj: az opció lehet,
hogy a snapshotot kimásolod egy külön valós LV kötetre, ott már nem
read only, így ha máshogy nem, akkor így olvasható lesz.


Üdv
Zsolt

_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Re: fajlrendszer titkositas

2016-01-22 bef zés Keller Viktor 
Zs  írta (2016. január 22. 0:41):
> precízen ki kell számolni a seek paraméter értékét, ellenkező esetben az
> öntökönlövés szigorú esetét állítjuk elő!!!

Csak kíváncsiságból, a partvonalról kérdem, hogy a méretnövelés után
dd-vel telirakni a titkosított kötetet egy óriásfile segítségével,
amit rögtön le is töröl, miben hoz eltérő eredményt? Az öntökönlövés
lehetőségének kihagyásán kívül. Azaz, miután rezie$FS $TITKOSKOTET,
csak azután futtatni a dd-t, de a mountolt, titkosított meghajtóba
írni:

dd if=/dev/zero of=$titkoskotet/oriasfile
sync
rm $titkoskotet/oriasfile


Mondjuk lehet, hogy le kell állítani ideiglenesen azokat a
szolgáltatásokat, amik a titkosított lemezt használták, ha nem tudják
kezelni azt a helyzetet, hogy pár tizedmásodpercig --amig a szkript
törli a dd által kreált fált--, nincs szabad helyük.

Ha nagyon amatőr a kérdés, akkor is örülnék válasznak.

Üdv:
Viktor
>
> Üdv
> Zsolt
>
>
> _
> linux lista  -  linux@mlf.linux.rulez.org
> http://mlf.linux.rulez.org/mailman/listinfo/linux
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Re: Iptables-kérdés

2016-01-22 bef zés BORBELY Zoltan 
Sziasztok!

On Fri, Jan 22, 2016 at 09:46:14AM +0100, Lajber Zoltan wrote:
> Ez azt jelenti, hogy ha mar lat kimeno kapcsolatot, akkor engedje be a
> valaszt (RELATED).

A RELATED lényege, hogy olyan új kapcsolatokat engedélyezzen, ami valami
módon kapcsolódik a jelenlegiekhez. Ilyen pl. az FTP protokoll adatcsatornája,
de ide sorolják az ICMP hibaüzeneteket is.

> udp-n nincs ertelmezve az ESTABLISHED.

Értelmezett, a kimenő UDP csomagra visszaengedi a választ.

A man iptables-extensions leírja ezeket.

Üdv
Bozo
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Re: Iptables-kérdés

2016-01-22 bef zés Zs 

Hi!




Asus router gyári firmware (Linux fut rajta) kiexportáltam a tűzfalat
és valamit nem értek:
Ez a sor:
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
Ez azt jelenti, hogy ha mar lat kimeno kapcsolatot, akkor engedje be a 
valaszt (RELATED). udp-n nincs ertelmezve az ESTABLISHED.

A lényegen nem változtat, csak kis pontosítás: én úgy emlékszem, hogy a
válasz beengedéséért az ESTABLISHED felel és a RELATED, ami nincs
értelmezve UDP esetén.
A lényeg: egy kapcsolat felépítésekor az első csomag NEW opcióval jön,
ha az nincs beengedve (és ez a szabály nem engedi be), akkor új kapcsolat
nem fog tudni létre jönni, de a már létezőket (valahol valamely másik
szabály beengedte, vagy a kapcsolat a másik irányból (OUTPUT) épült
fel,) nem bántja.

megoldaná az alábbit is és feleslegesen van engedélyezve, vagy 
rosszul gondolom?

-A INPUT -p udp -m udp --sport 67 --dport 68 -j ACCEPT

Ez a bejovo dhcp -t engedelyezi.
Ha nincs ez a sor, akkor dhcp klienskent fog mukodni, de nem tud dhcp 
szerver lenni.
Ez a konkrét magyarázat. Egyébként meg azt nézd meg, hogy itt mind a 
forrás-,
mind a cél port is meg van adva. Tehát nem elég, hogy UDP-n eltalálod a 
68-as
portot, de a csomagnak tőled a 67-es portról kell indulnia! Ez azért 
bőven nagyobbat

szűr, mint az előző szabály, ahol nincs semmilyen port korlátozás.


Mivel már kezdeményezett kapcsolatokra utal és nekem sima Linux alatt
soha nem volt bajom tűzfallal, ha csak ezt az egyetlen sort
tartalmazta és csak a related és established csomagokat engedtem, UDP
üzenetek is mentek, DNS lekérdezés stb.
Nem jelent kockázatot külön az UDP engedélyezése?
Nem. A portok szűkítése miatt minimális forgalmat engedélyezel, azt meg 
engedned
kell ahhoz, hogy a masina DHCP szerver legyen. Illetve ha ezt nem 
akarod, akkor

ezt a szabályt kiveheted.


Üdv
Zsolt

_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Re: fajlrendszer titkositas <linux@mlf.linux.rulez.org>

2016-01-22 bef zés Kiss Gabor 

On 01/22/2016 12:41 AM, Zs wrote:
> Az új terület random adattal feltöltése elhagyható, de security szempontból
> nem szerencsés - elkövetése esetén viszont *nagyon* észnél kell lenni és
> precízen ki kell számolni a seek paraméter értékét, ellenkező esetben az
> öntökönlövés szigorú esetét állítjuk elő!!!

Biztonságosabb, ha az LV növelése _előtt_ maszatoljuk össze az összes
szabad helyet a diszken, és csak utána engedjük rá a titkosítást.
Akkor nem festhetjük ki az elő filesystemeket.

g
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Re: Iptables-kérdés

2016-01-22 bef zés Lajber Zoltan 

On Fri, 22 Jan 2016, Géza Kovacs Géza wrote:


Sziasztok!

Asus router gyári firmware (Linux fut rajta) kiexportáltam a tűzfalat
és valamit nem értek:
Ez a sor:
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT


Ez azt jelenti, hogy ha mar lat kimeno kapcsolatot, akkor engedje be a 
valaszt (RELATED). udp-n nincs ertelmezve az ESTABLISHED.



megoldaná az alábbit is és feleslegesen van engedélyezve, vagy rosszul gondolom?
-A INPUT -p udp -m udp --sport 67 --dport 68 -j ACCEPT


Ez a bejovo dhcp -t engedelyezi.
Ha nincs ez a sor, akkor dhcp klienskent fog mukodni, de nem tud dhcp 
szerver lenni.



Mivel már kezdeményezett kapcsolatokra utal és nekem sima Linux alatt
soha nem volt bajom tűzfallal, ha csak ezt az egyetlen sort
tartalmazta és csak a related és established csomagokat engedtem, UDP
üzenetek is mentek, DNS lekérdezés stb.
Nem jelent kockázatot külön az UDP engedélyezése?

Üdv, G
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux


-=Lajbi=-
 LAJBER Zoltan
 engineer: a mechanism for converting caffeine into designs.

_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Re: fajlrendszer titkositas

2016-01-22 bef zés Kosa Attila 
On Thu, Jan 21, 2016 at 04:30:03PM +0100, Kiss Gabor wrote:
> On 01/21/2016 03:28 PM, Kosa Attila wrote:
> > Ami meg eszembe jutott: lvm-mel egyutt kell tudnia mukodni,
> > legalabb az online meretnoveles mukodjon.
> 
> Az LV-n található block device-t kell titkosítani, és menni fog a bövítés.

Es egy snapshot is csak a titkositott eszkozt fogja
"lefenykepezni", ugye? Tehat jelszo nelkul az sem lesz olvashato?

-- 
Udvozlettel
Zsiga
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Re: fajlrendszer titkositas

2016-01-22 bef zés Kiss Gabor 

On 01/22/2016 09:56 AM, Kosa Attila wrote:
> On Thu, Jan 21, 2016 at 04:30:03PM +0100, Kiss Gabor wrote:
>> On 01/21/2016 03:28 PM, Kosa Attila wrote:
>>> Ami meg eszembe jutott: lvm-mel egyutt kell tudnia mukodni,
>>> legalabb az online meretnoveles mukodjon.
>>
>> Az LV-n található block device-t kell titkosítani, és menni fog a bövítés.
> 
> Es egy snapshot is csak a titkositott eszkozt fogja
> "lefenykepezni", ugye? Tehat jelszo nelkul az sem lesz olvashato?

Blokkokat másol.
Függetlenül a tartalmuktól.
Az LVM csak azt tartja nyilván, hogy melyik blokkba írtál a snapshot
után, az nem érdekli, hogy mit.
A titkosítási réteg efelett van. Azon meg a filesystem.

Összefoglalva: igen, nyugodj meg! :-)

g
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Re: fajlrendszer titkositas <linux@mlf.linux.rulez.org> <linux@mlf.linux.rulez.org>

2016-01-22 bef zés Kiss Gabor 

On 01/22/2016 04:53 PM, Keller Viktor wrote:
>>> Csak kíváncsiságból, a partvonalról kérdem, hogy a méretnövelés után
>>> dd-vel telirakni a titkosított kötetet egy óriásfile segítségével,
>>> amit rögtön le is töröl, miben hoz eltérő eredményt? Az öntökönlövés
>>
>> -> Known plaintext attack
>> (Ismerem az óriásfile-t, ismerem a titkos leképzését. Minél hosszabb
>> a file, annál könnyebb kitalálni a kulcsot.)
> 
> OK, ezt értem, és jogos (mondjuk miután a listán feldobtam, olyan
> lenne, ha ilyet csinálok, mint pin kódnak az 1234). Akkor vegye a dd
> /dev/zero helyett a véletlenszám generátorról a bemenetét. Akkor is?

Akkor nincs semmi gond. Szokták is.

g
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Re: fajlrendszer titkositas

2016-01-22 bef zés Volarics István 



Csak kíváncsiságból, a partvonalról kérdem, hogy a méretnövelés után
dd-vel telirakni a titkosított kötetet egy óriásfile segítségével,
amit rögtön le is töröl, miben hoz eltérő eredményt? Az öntökönlövés


A VG szabad helyén csinálsz egy LV-t azt ezt telenyomod
dd if=/dev/random of=/dev/vg/lv
és ha végzett letörlöd az LV-t és így amíg új PV-t nem raksz be
nem is kell foglalkoznod a dologgal.
:Voli
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Re: Iptables-kérdés

2016-01-22 bef zés Ferenc Wagner 
Lajber Zoltan  writes:

> On Fri, 22 Jan 2016, Géza Kovacs Géza wrote:
>
>> Asus router gyári firmware (Linux fut rajta) kiexportáltam a tűzfalat
>> és valamit nem értek:
>> Ez a sor:
>> -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
>
> Ez azt jelenti, hogy ha mar lat kimeno kapcsolatot, akkor engedje be a
> valaszt (RELATED).

Nem, az UDP válasz az ESTABLISHED révén jöhet be
/proc/sys/net/netfilter/nf_conntrack_udp_timeout másodpercig.  A RELATED
megüzent portszámok választásakor lép be, pl. TFTP esetén, ha betöltöd a
megfelelő helper modult.
--
Feri.
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Re: fajlrendszer titkositas

2016-01-22 bef zés Kosa Attila 
On Thu, Jan 21, 2016 at 04:30:03PM +0100, Kiss Gabor wrote:
> On 01/21/2016 03:28 PM, Kosa Attila wrote:
> > Ami meg eszembe jutott: lvm-mel egyutt kell tudnia mukodni,
> > legalabb az online meretnoveles mukodjon.
> 
> Az LV-n található block device-t kell titkosítani, és menni fog a bövítés.
> 
> Tizensok éve a loop-aes a kedvencem, de már kivették a Debianból.
> A dm-cryptnek van kompatibilis üzemmódja, bár nem annyira kényelmes.

Az ecryptfs-t probaltam, de annal nem tudtam novelni a
fajlrendszer meretet online, csak ha "lecsatoltam" a titkositast.

Ugy sejtem, hogy ez normalis ebben az ecryptfs eseten, de azert
megkerdezem: nem jol csinaltam valamit, vagy tenyleg igy mukodik?

-- 
Udvozlettel
Zsiga
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Re: fajlrendszer titkositas <linux@mlf.linux.rulez.org>

2016-01-22 bef zés Keller Viktor 
Kiss Gabor  írta (2016. január 22. 12:59):
>
> On 01/22/2016 10:42 AM, Keller Viktor wrote:
>> Zs  írta (2016. január 22. 0:41):
>>> precízen ki kell számolni a seek paraméter értékét, ellenkező esetben az
>>> öntökönlövés szigorú esetét állítjuk elő!!!
>>
>> Csak kíváncsiságból, a partvonalról kérdem, hogy a méretnövelés után
>> dd-vel telirakni a titkosított kötetet egy óriásfile segítségével,
>> amit rögtön le is töröl, miben hoz eltérő eredményt? Az öntökönlövés
>
> -> Known plaintext attack
> (Ismerem az óriásfile-t, ismerem a titkos leképzését. Minél hosszabb
> a file, annál könnyebb kitalálni a kulcsot.)

OK, ezt értem, és jogos (mondjuk miután a listán feldobtam, olyan
lenne, ha ilyet csinálok, mint pin kódnak az 1234). Akkor vegye a dd
/dev/zero helyett a véletlenszám generátorról a bemenetét. Akkor is?
>

Üdv:
Viktor
> g
> _
> linux lista  -  linux@mlf.linux.rulez.org
> http://mlf.linux.rulez.org/mailman/listinfo/linux
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Re: fajlrendszer titkositas <linux@mlf.linux.rulez.org> <linux@mlf.linux.rulez.org>

2016-01-22 bef zés Keller Viktor 
Kiss Gabor  írta (2016. január 22. 18:03):
> Akkor nincs semmi gond. Szokták is.

Mindenkinek köszönöm a válaszokat.

Üdv:
Viktor
>
> g
> _
> linux lista  -  linux@mlf.linux.rulez.org
> http://mlf.linux.rulez.org/mailman/listinfo/linux
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

mappaszinkronizálás mivel gyors?

2016-01-22 bef zés Géza Kovacs Géza 
Sziasztok!

Miért van az, hogy Rsync esetén ha szinkronban szeretnék tartani
valamit, akkor - a könyvtárstruktúra nagyságától függően - akár egy
óráig is eltart, mire a már szinkronizált fájlokon végigmegy és a
módosított fájlokat szinkronizálja?
Gondolom: mindenegyes indításkor elejétől végéig átnézi, hogy nem
módosult -e az adott fájl, más elképzelésem nincs, hogy mi tarthat
ennyi ideig.
Sima, egyszerű, lokális fájlszinkronizációról van szó, nem SSH-n keresztül.

Nem tudom, azért van -e a belassulás, mert USB portra csatlakoztatott
merevlemezekre történik a szinkronizáció (forráskönyvtár és
célkönyvtár is egy-egy ilyen lemezen van) és ott - gondolom - hogy
lassabban tudja olvasni a fájlokat, mint kellene (USB 2.0).
rsync -t -r --progress /utvonal/konyvtar1/ /utvonal/konyvtar2
Más paramétert nem használok, esetleg valamit rosszul csinálok, van
egyszerűbb és gyorsabb módja is?
Én csak azt szeretném, ha a forrásban megváltozik valamelyik fájl,
vagy új fájlok lesznek ott, a célkönyvtárba is szinkronizálja.
Másra nincs szükségem.

Esetleg a rsync-et paramétereztem rosszul?

Üdv, G
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Re: Iptables-kérdés

2016-01-22 bef zés Géza Kovacs Géza 
Sziasztok!

Nagyon köszönöm mindenkinek a válaszokat.

Azt kérdezném még, hogy a "NAT áthaladás" menüpont alatt minden
alapértelmezetten be volt kapcsolva és pár portot NAT-olt befelé, ez
nagyon régóta így volt, most vettem észre.
El lehetett kapni valamilyen kártevőt pl. a Windows-os gépeknek? Sok
olyan kártevő program van, ami portszkenneléssel próbálkozik bejutni
vagy sebezhetőséget keresni és ha olyan porton próbálkozott, ami
NAT-olva volt befelé akkor akár be is juthatott valami?
Következő opciók voltak engedélyezve valamint alábbit írja erről a
web-es felület:

WAN - NAT áthaladás
A NAT áthaladás engedélyezése lehetővé teszi egy Virtuális
magánhálózati (VPN) kapcsolat számára az áthaladást a routeren a
hálózati kliensekhez.

PPTP áthaladás
L2TP áthaladás
IPSec áthaladás
IPTV áthaladás
H.323 áthaladás
SIP áthaladás
PPPoE közvetítés engedélyezése

Ezek mind engedélyezve voltak.

Nincs IPTV, VPN-hez sem szoktam csatlakozni.

Üdv, G
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux