Open .git global scan

 ( Oregon | 2018. augusztus 21., kedd - 9:13 )

Lehet a témában nem én vagyok az egyetlen aki elfelejti levédeni a ".git" könyvtárát. Történetesen az egyik hobbi projektemnél így jártam. "Szerencsémre" egy fehérkaplapos nyomot egy global scan-t ami küldött egy emailt nekem az incidensről. Talán a napokban más is kapott ilyen levelet tőle: https://smitka.me/

Mivel én Apache-t használok és a probléma általános, így értelmesebb lett volna globális szinten levédeni ezeket a könyvtárakat.

Így kellett volna Apache esetén:

#  /etc/apache/apache2.conf
< Directorymatch "^/.*/\.git/" >
Order deny,allow
Deny from all
< /Directorymatch >

A formázás miatt vannak benne felesleges space-k < itt > )

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

erdekes koncepcio a documentroot ala klonozni...

--
"dolgozni mar reg nem akarok" - HZuid_7086 'iddqd' zoli berserk mode-ba kapcsol

Sok opensource dolgot leklónoz az ember, mert a konfig alapból üres, a forrás meg amúgy is nyílt.

Érdekelne, hogy nálad mi a metódus.

Sokféle deploy megoldás létezik, én pl. egy pár soros Fabric szkriptet használok, ami végül is egy sima Python-szkript pár extra ficsőrrel. A releváns részlet (egy Django apphoz):

@task
def deploy(ctx):
    """Deploy current version"""
    c = Connection(HOST)
    current_commit = c.local("git log -n 1 --format=%H", hide="out").stdout

    c.run(f'mkdir -p {APP_DIR}')
    total = 7

    with c.cd(APP_DIR):
        header(f'Step 1/{total}: Get latest source code from the repository')
        _get_latest_source(c, current_commit)

        header(f'Step 2/{total}: Update the virtualenv using Poetry')
        _update_virtualenv(c)

        header(f'Step 3/{total}: Update JavaScript modules')
        _update_javascript_modules(c)

        header(f'Step 4/{total}: Create JavaScript bundles')
        _update_javascript_bundles(c)

        header(f'Step 5/{total}: Collect static files')
        _update_static_files(c)

        header(f'Step 6/{total}: Make migrations')
        _update_database(c)

        header(f'Step 7/{total}: Reload uWSGI application server')
        _reload_uwsgi(c)

Egyszerű, átlátható, könnyen bővíthető, ha kell egy új lépés, és egy $ fab deploy paranccsal futtatható.

Esetedben (feltételezem, hogy PHP-ben írt programot akarsz használni, mert máshol nincs ez a probléma) két lépcsős lehetne a deploy, az elsőben frissíted a szerveren a git repót, a másodikban pedig átmásolod a megfelelő helyre a megfelelő fájlokat. Egyszer kell csak ezt expliciten definiálnod egy Fabric fájlban (vagy egy másik, $kedvenc_nyelv-ben készült megoldásban).

Köszi. Közben utána néztem és szerintem ez helyesebb és kényelmesebb lenne nekem:

 git archive --remote=ssh://USER@server.tld/GITREPOS/somethingProject.git --format=tar master | tar -xv

Nagyjából igen :-)

Nem illik gitből deployolni. Minek? A szerverre csak az a file kerül fel, aminek ott a helye. Gyakorlatilag te az egész projekt történetét kitetted a szervere, ami attack vector is lehet nagyon könnyen.

Jogos. :S

Sok helyen - sajnos - git-et használnak deploymentre. Tipikusan KKV szektorban láttam erre példát, PHP-s környezetben. Mivel ezeknél tipikusan nincs CI meg deployment process, a muki beSSHzik a szerverre és hát ez a legegyszerűbb módja a dolognak. Java stacknél megint más, ott inkább odafigyelnek az ilyesmire, meg ott eleve 1 artifact van (war, jar...).

Attól, hogy sok helyen csinálják, meg ez a legegyszerűbb, még nem lesz jó.
És van deployment processz, pont te írtad le SSH + git pull :) Csak épp nem automatizált.
És ez most amúgy független attól, hogy egy (vagy több) bináris artifact van, vagy éppen forrásfile-ok vannak csak. Ez totál stackfüggetlen. Deploymentet mindenhol lehet szarul csinálni. Meg mindenhol lehet jól. És aki rájött arra (vagy megmutatták neki), hogyan jó csinálni, annak utána már derogál rosszul csinálni.
Abból is lehet ZIP-et készíteni, mielőtt deployolsz.

Jól sejtem, hogy KKV-ban dolgozol, esetleg PHP-vel? :) Leírtad ugyanazt, amit én, csak látszólag védekezel.

Java stacknél pl. elég gáz, ha verziókövetve van a buildelt artifact. Biztos van rá példa. PHP-nél viszont azt kell kirakni, ami ott van gitben, adja magát, hogy a legkényelmesebb - és egyben az egyik legrosszabb - megoldást használják.

Dehogy védekezem. Pont azt mondom, hogy attól még, hogy sokan csinálják, nem lesz jó.
Javas fejlesztő vagyok, mióta dolgozom.
De pont volt egy PHP-s legacy projekt, aminél rendbe kellett tenni a deploymentet, kézzel ment. Lett belőle szép Jenkins jobos deployment, automatikusan.

"PHP-nél viszont azt kell kirakni, ami ott van gitben"
Miért is? Azt kell kirakni, ami átment tesztelésen, jóvá van hagyva. gitben benne van a kód.
Ebből készül buildelés során (mert minden szoftvernél van értelme buildelni, még akkor is, ha scriptekből áll) egy telepíthető csomag, ami tartalmazza a konfigurációt (php.ini eltérő lehet környezetenként), meg a környezetfüggő dolgokat, urambocsá' akár containerben. Láttam már olyat is, ahol a PHP kódból rpm készült, és a megfelelő RPM terítési módszerrel került ki a szerverre. Hiszen például a verziókezelt php.ini helyzete is lehet, hogy a git repositoryban a config/ alatt van, miközben a szerveren máshová kell tenni.

Sőt, pont a PHP verziók meg különféle php.ini-k és extensionök miatt még annak is van értelme, hogy build során Docker container készül, amiben benne van a kód (immutable), és deploykor ez a container indul el.

Lehet ezt normálisan is csinálni, és nem igaz az, hogy "PHP-nél viszont azt kell kirakni, ami ott van gitben". Ez pont ugyanaz, minthogy azt mondanád, hogy Javanal is azt kell kitenni, ami ott van gitben. Persze, csak ahhoz, hogy a szerver számára értelmezhető legyen, kell futtatni javacot, jar-t meg még pár toolt. Amit persze lehetne kézzel is, egy git pull után, de lehet ezt eszközzel is csinálni. Mint ahogy PHP-nél is.

"Java stacknél pl. elég gáz, ha verziókövetve van a buildelt artifact."
Ennek is ellent tudok mondani. Az igaz, hogy forráskódkezelőben nincs helye bináris artifactnak. A forráskódkezelő a forráskód verziókövetésére való.
Viszont attól még verziókezelve vannak a buildelt artifactok is, erre valók a különféle bináris repositoryk, amik a lebuildelt artifactot tárolják. Nexus, Artifactory, stb. Ennek oka van, és jól is van így. És ez is azt csinálja, hogy verziókezeli a bináris artifactokat. Minden kiadás elérhető viszamenőlegesen.

Arra érdekelne egy példa, mi az ami benne van a git-ben és nem kell az éles szerverre. (Szerintem ilyennek nem szabadna léteznie.)

Például a dev/test/uat környezet php.ini-je, illetve az alkalmazás konfigurációja (mások mondjuk dev környezetben az elérési utak, mint élesben), ami ugyanúgy verziókezelve meg kell legyen. Mert az ugye alap, hogy a konfiguráció is verziókezelt, a gépekre is a verziókezelőből (csomagkezelőből) kerül ki, akár automatizálva (ansible, puppet, bármi), akár a deployment során.

És míg mondjuk dev/test/uat környezetben más a maximum memória, mint prodban, vagy más a maximum request time, mint élesen, ezért ez egy teljesen valid szituáció.

Ugyanígy például a nem API leíró fejlesztői dokumentáció (markdown vagy asciidoc) formában is verziókezelten megvan, ugye? Az is gitben van, a forráskód mellett, mégsem kerül ki az éles szerverre.

A másik ok, hogy miért térhet el a szerveren futó PHP file, és a gitben lévő, az pedig az, hogy előírás lehet, hogy élesben csak obfuszkált kód futhat, eltávolítva belőle a kommentek stb., mert mondjuk az ügyfélnek nem akarod kiadni a (továbbfejleszthető) forrást, csak a működő szoftvert, mert a forráskódra fenntartod a copyrightot.

Csak a buildhez és/vagy teszteléshez szükséges komponensek, doksik...

magad irtad: pl. a .git konyvtar :-)

--
"dolgozni mar reg nem akarok" - HZuid_7086 'iddqd' zoli berserk mode-ba kapcsol

Java stacknél pl. elég gáz, ha verziókövetve van a buildelt artifact.

binary repository nem rulez?

--
"dolgozni mar reg nem akarok" - HZuid_7086 'iddqd' zoli berserk mode-ba kapcsol

sajat kodot semmikeppen nem egy altalanos celu webszerveren osztanek meg a documentroot alatt. Ha olyan a dolog, akkor github/-lab vagy hasonlo helyre tennem fel. Az is megoldhato ezeknel, hogy privat legyen a projekt.

Weboldalon max. a repo url-t adnam meg, esetleg a forras tar.gz-t, opcionalisan a build-elt artifact-okat, pl. deb, rpm, iso, ...

--
"dolgozni mar reg nem akarok" - HZuid_7086 'iddqd' zoli berserk mode-ba kapcsol

export GIT_DIR=/www/sitenev_git
export GIT_WORK_TREE=/www/sitenev
git fetch && git reset --hard origin/master && git clean -d -f -q

a git_dir persze barhol lehet, mi ezt szoktuk meg

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Vagy akár lehet így:

git archive master --prefix /www/sitenev --remote ... | tar xvf -

edes mind1, ha a git eleri a remote repot, akkor a haxxor clone-olni is tud, ugyanugy latja a historyt
raadasul a tar nem tunteti el a torolt fajlokat, ha meg mindig uj konyvtarba tesszuk a fajlokat akkor meg a configokat kell oda masolni, meg a "www storage" mappat atrakni, stbstb. ez is macera.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Igen, a webszerverre "húzzuk" a tartalmat nem a biztonságos megoldások mintapéldája. A törlést/könyvtármókolást lehet trükközni, a konfig meg szintén jöhet git-ből; az viszont tény, hogy az illendő módszer a verziókezelő felől "tolni" a tartalmat a webszerverre.

milyen olyan cucc van ami akkor is tudja tolni a webserverre a cuccot, amikor a webserver epp allt (ugy ertem jon a trigger hogy deployolni kene, de az egyik webserver epp all. majd ugy fel ora mulva visszajon, na akkor gyorsan ki kene tolni ra az uj verziot)?

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Az a cucc, hogy elfailel a deploy. És ezt szépen lehet követni is a CD rendszerben, hogy mi miért nem sikerült. Teljesen normális dolog. Pull mód esetén meg az igaz, hogy mi van akkor, ha a szerver nem éri el a repositoryt? Ott is egy sikertelen deploy van.
Amúgy az előbbi dolog (server felé push) azért jobb, mint a másik (amikor a server pullol), mert az utóbbi esetben a tűzfalon csak kifelé irányuló szabályt kell megadnod, továbbra is igaz marad, hogy kívülről nem engedsz be semmi olyat, ami ne belülről irányuló requestre lenne válasz.

-1

a koncepcio fucked by design...

--
"dolgozni mar reg nem akarok" - HZuid_7086 'iddqd' zoli berserk mode-ba kapcsol