Firebird / gdb védelem

Firebird / gdb védelem
2005-02-23T12:29:56+01:00
2005-03-20T19:02:55+01:00
2022-10-24T08:41:57+02:00
zozo01
Sziasztok!

Meg tudja nekem mondani valaki, hogy hogyan lehet egy GDB-t úgy
lejelszavasítani, hogy még a sysdba se tudja megnyitni, hanem csak egy konkrét USER? Tegyük fel, hogy akarok egy user:ALMA és
password:1234 kizárólagos hozzáférést.

Zozo
Mutasd a teljes hozzászólást!
Hozz létre benne egy SYSDBA nevű role-t...
Mutasd a teljes hozzászólást!

  • Sehogy...

    A SYSDBA-nak meg kell változtatni a jelszavát, illetve gondoskodni kell a "security.fdb" file eltakarásáról...

    Ugyanis a lánc annyíra erős, mint a leggyengébb láncszeme... ha lecserélem a security... már is az én SYSDBA jelszavam él...
    Mutasd a teljes hozzászólást!
  • Hozz létre benne egy SYSDBA nevű role-t...
    Mutasd a teljes hozzászólást!
  • Köszi a tippet, de ennél jobb kellene. Ugyanis ha jobban ért valaki hozzá, belemászik a GDB-be egy bináris editorral és nyom neki egy "replace all SYSDBA -rol SSYDBA-ra"... és máris hozzáférsz.. gondolom érted, hogy miért.. ezt már többször is kipróbáltam és működött...

    Azért köszi, rendi vagy hogy írtál..

    Zozo
    Mutasd a teljes hozzászólást!
  • KÖszi :(

    hát.. nagyon homorú vagyok..

    azt hittem, hogy van talán olyan megoldás amit nem ismerek...

    Azé köszi!!

    Zozo
    Mutasd a teljes hozzászólást!
  • Védelmet úgy lehet megoldani, hogy:
    1. Hálózat...
    2. Önálló adatbázisszerver (elzártan)/ vagy egyébb szerver
    3. A *.gdb, *.fdb -re nincs csak az adminak joga, hogy léssa, vagyis a kliens gépek nem látják file megosztásban...
    4. SYSDBA jelszó változtatás
    5. Csak hab: Egyedi user-rel létrehozni a db-t.
    Mutasd a teljes hozzászólást!
  • Szia .. Köszi a választ!

    >édelmet úgy lehet megoldani, hogy:
    >1. Hálózat...
    >2. Önálló adatbázisszerver (elzártan)/ >vagy egyébb szerver
    >3. A *.gdb, *.fdb -re nincs csak az >adminak joga, hogy léssa, vagyis a >kliens gépek nem látják file >megosztásban...

    Igazából amiket leírtál, azt én is tudom. (ettől függetlenül köszönöm) A helyzet az, hogy nem nagyon akartam a felvetett témában nagyon bő lére ereszteni a kérdést és magyarázkodást. A problámám gyökere az az, hogy az általam készített program bekonfigurálásához ne kelljen szakember; ne kellejen a hálózaton jogosultságokat szétosztani; lehetőleg ne tudjanak az adatbázisbe belepiszkálni..

    >4. SYSDBA jelszó változtatás
    Ezt már alkalmaztam egyéb helyeken.. de ha fut már másik FB alapú progija az illetőnek, akkor ez gáz.. már ezt ebben votl részem. Itt jött képbe a ROLE NAME-s megoldás, ami frappáns.. Bár erre írtam vissza, hogy hogyan lehet kilőni.. Tudod abban reménykedem, hogy azért az átlag user , vagy advanced user-ek még azért nem olyan rutinosak az ilyen trükkökben.

    >5. Csak hab: Egyedi user-rel létrehozni >a db-t.
    mivel a SYSDBA nem törölhető, ezért jutok vissza az előző válaszomhoz...

    Ne értsd félre, nem kötekedni akartam, és értékelem a válaszodat is. Abban reménykedtem, hogy van valamilyen megoldás amiről szegényes tudásom miatt még nem szereztem infot... Viszont ha majd nevem látod a közeljövőben, azért még írjál :) ! OK? bár úgy emlékszem , egyszer már segítettél valamiben, ami hasznos volt.. hm?
    Mutasd a teljes hozzászólást!
  • jaj... csak még egy kis pontosítás a 5. ponthoz írt válaszomhoz..

    Megcsináltam azt,hogy lérhoztam egy user:uborka password:12345 felhasználóval az atbázist, és hozzáadtam a SYSDBA-t ROLE NAME-ekhez.. így csak UBORKA fér hozzá és SYSDBA-nem.. még akkor is ha ismeri a SYSDBA jelszót.. de ha ügyi az emberünk a "SYSDBA"-t átírja a GDB-ben (egy editorral) valami másra, és hip-hop ki tudja nyitni az adatbázist..

    LÉgy jó!
    Zozo

    ui: azért még írjál
    Mutasd a teljes hozzászólást!
  • Mutasd a teljes hozzászólást!
  • És miért olyan nehéz letiltani, hogy a user ne férjen hozzá a file hoz ?? csak p3050 et hagyd meg neki.
    Ebben mi a bonyolult ?
    Mutasd a teljes hozzászólást!
  • Ha tényleg fontos, hogy csak az adott felhasználó használhassa az adatbázist, talán megfontolandó, hogy a táblák adatai titkosítva kerüljenek tárolásra, és csak a kliens ismerje a kódot hozzá. Ezzel ugyan nem korlátozódik a SYSDBA jogai, de legalább nem fog látni semmi értelmeset a tábláidban.
    Mutasd a teljes hozzászólást!
  • táblák adatai titkosítva kerüljenek tárolásra, és csak a kliens ismerje a kódot hozzá


    Hogyan oldanád meg a kivitelezését?
    Mutasd a teljes hozzászólást!
  • Pl.
    Lenne a felhasználónak egy 16-jegyű azonosítója. Ez pl. lehetnek számjegyek.
    Minden adatot ezzel a számsorozattal titkosítanék, akár int, string, blob az elem. A kódoló eljárás egyszerű ROR típusú művelet lenne valahogy így:
    Procedure EncodeData(pSource, pDest: PByte; iSize: Integer; const sCode: String); var iCodeSize: Integer; pROR: PByte; I: Integer; begin iCodeSize:= Length(Code); GetMem(pROR, iCodeSize); For I:=1 to iCodeSize do pROR[I-1] := Ord(sCode[I])-Ord('0'); try asm pushad mov edi, pDest mov esi, pSource mov edx, pROR mov ebx, iCodeSize @@1: mov al, [esi] mov cl, [edx] ror al, cl mov [edi], al inc esi inc edi inc edx dec iSize jz @@2 dec ebx jnz @@1 mov ebx, iCodeSize mov edx, pROR jmp @@1 @@2: popad end; finally Finally(pROR); end; end;
    A kódoló eljárás működése:
    A számjegyeknek megfelelő mértékben forgatja körbe a biteket az egyes bájtokban. Nem feltörhetetlen kódolás, de általánossában jó lehet.
    Érdemes külön Stream, String és Integer típusra is létrehozni kódolót.
    Csak a kódszámot kell titokban tartani valahogy.
    Mutasd a teljes hozzászólást!
  • Nem ezt kérdeztem... A kódoló eljárás tiszta sor, lehetne mégjobban is megcifrázni.

    De hogyan oldod meg a kezelését?? Ha egy SQL select-et futtatsz szerinted egyszerű lesz-e ezt implementálni. Nemmondom UDF-ekkel FB-ben megvalósítható, de:

    1. Nem monden körülmények között lehetne alkalmazni,
    2. Ahol lehet, ott rettenetesen nyűgössé teszi a programozást
    3. Halál lesz a sebesség. Szerinted mi fog történni egy egyszerű SELECT esetén is?? Az IB motor abszolút nincs ilyen szituációra optimalizálva.

    Szóval nem a kódolás mechanizmusa érdekel, az más kérdés, hanem a kivitelezési oldal.

    Mutasd a teljes hozzászólást!
  • Megvalósításra én így csinálnám:
    // ezeket tekintsünk adottnak Function EncodeInt(Value: Integer;const Code: String): Integer; Function EncodeString(const Value: String; const Code: String): String; Function EncodeStream(Source, Dest: TStream; const Code: String); Function DecodeInt(Value: Integer;const Code: String): Integer; Function DecodeString(const Value: String; const Code: String): String; Function DecodeStream(Source, Dest: TStream; const Code: String); // egy példa sCode := '78681605640759064541161'; with Query1 do begin Close; SQL.Clear; SQL.Text := 'SELECT id, text, image FROM tabla WHERE id=:id'; Parameters['id'].AsInteger := EncodeInt(1001, sCode); Open; First; Edit; FieldByName('text').AsString := EncodeString('Ez az új tartalom', sCode); BlobStream := CreateBlobStream(FieldByName('image'), bmWrite); MemoryStream.LoadFromFile('image.jpg'); EncodeStream(MemoryStream, BlobStream, sCode); BlobStream.Free; Post; ApplyChanges; CommitChanges; end;
    Talán az ID mezőt tök fölösleges kódolni.
    Mutasd a teljes hozzászólást!
  • Ez így mind szép és jó.....

    De:
    1. Aki így, ilyen körítéssel lekódol egy teljes proggit, annak csak gratulálni tudok. Egy bonyolultabb SQL szintaxist elég nehéz kezelni, pláne így.
    2. Szintén gratulálok azoknak a user-eknek, akik képesek kivárni, amíg a kódoló-dekódoló minden adatbázis-érintésnél eljátszik.
    3. Hogyan oldod meg, pl ezt:
    SELECT * FROM TABLA WHERE MEZO LIKE %AKARMI%

    4. Végül, de nem utolsó sorban: komolyabb adatbázis-programokban a műveletvégzés tárolt eljárásokban történik. Ekkor le kell vinned a kódolást-dekódolást db szintre. Ez önmagában is jó kis móka, de a lényeg az, hogy akkor a kódolás értelmét veszíti, mivel addig már eljutottunk, hogy a db-t nem lehet teljes mértékben levédeni. Ergo kiszedi a kódoló eljárást, vagy ha UDF-be teszed, lefuttatja az UDF-et az adatokon és máris tud mindent....

    Szóval ez nem alkalmazható a gyakorlatban.
    Mutasd a teljes hozzászólást!
  • Amit leírtál, az mind igaz.

    Akkor már csak a következőt tudom javasolni:

    A FireBird nyitott forrású. Fogod magad, és felülírod a táblák hozzáférését ellenőrző kódrészletet úgy, hogy kihagyod belőle a SYSDBA plussz jogait.

    Vagy válts pl Oracle-re. Ott annyi mindent (kell) beállítani, hogy kedved szerint zárhatsz ki akit csak akarsz.
    Mutasd a teljes hozzászólást!
  • Hát ja, az Oracle az más világ...

    Sajnos reálisan nem megoldható FB esetén ez a titkosításos módszer.

    Bezzeg a jó kis Paradox táblák!!! Ott egész elviselhető sebességgel be volt mindez építve a DB motorba. Tökéletes is lett volna, ha valami pihent agyú fejlesztő nem hagyott volna hozzá 2 backdoor password-öt....
    Mutasd a teljes hozzászólást!
  • Miket beszélek:

    Paradox táblák!!!

    Tökéletes


    Ez egy paradoxon...
    Mutasd a teljes hozzászólást!
  • Engem viszont az a BackDoor érdekel, amit írtál. Esetleg tudnál adni valami info-t róla? Imádom az ilyen rejtett passwordokat!
    Mutasd a teljes hozzászólást!
  • A világért sem tenném közzé... (jIGGAe)
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd