Dotaz: BASH grep v proměnný nefunguje

[PD321]

Ahoj, mám skript, kde CATem vypisuju soubor a pomocí GREPu výsledek filtruju. Část s GREPama mám uloženou v proměnný.

prom="| grep srcip=192.168.1.10 | grep dstip=192.168.2.10 | grep dstport=8090"
cat /mnt/syslog/network/fg-int/fg-int.log $prom

Pokud to zadám takhle, tak se mi vypíše soubor celej bez ohledu na filtry.

Když to zadám v celku, bez použití promměný, tak to funguje a vypíše jenom řádky odpovídající filtrům:
cat /mnt/syslog/network/fw-int.log | grep srcip=192.168.1.10 | grep dstip=192.168.2.10 | grep dstport=8090

Nevíte kde je chyba? Dík.

---

---

Odpovědi

[debian+]

Je to o spracovani forend-oveho prikazu backend-om.

Ak chces aby ti to islo podla teba, tak:

prom="| grep srcip=192.168.1.10 | grep dstip=192.168.2.10 | grep dstport=8090"
bash -c "cat /mnt/syslog/network/fg-int/fg-int.log $prom"

Pozor v prom na obycajne uvodzovky alebo si to uprav.

[debian+]

Pokial nechces riesit uvodzovky, tak:

prom="| grep srcip=192.168.1.10 | grep dstip=192.168.2.10 | grep dstport=8090"
echo cat /mnt/syslog/network/fg-int/fg-int.log $prom | bash

[Andrej]

Používat k tomuhle proměnné je prasárna. Sice to za určitých okolností¹ můžeš přimět k tomu, aby to fungovalo, ale je to špatně:

$ x="uname -a"
$ $x
Linux osma 4.15.0-48-generic #51-Ubuntu SMP Wed Apr 3 08:28:49 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

$ x="uname -a | base64"
$ $x
uname: nadbytečný operand „|“
Více informací získáte příkazem „uname --help“.

$ bash -c "$x"
TGludXggb3NtYSA0LjE1LjAtNDgtZ2VuZXJpYyAjNTEtVWJ1bnR1IFNNUCBXZWQgQXByIDMgMDg6
Mjg6NDkgVVRDIDIwMTkgeDg2XzY0IHg4Nl82NCB4ODZfNjQgR05VL0xpbnV4Cg==

Bash umí funkce – a přesně pro tenhle účel se hodí.

$ mojeFunkce() { uname -a | base64; }
$ mojeFunkce 
TGludXggb3NtYSA0LjE1LjAtNDgtZ2VuZXJpYyAjNTEtVWJ1bnR1IFNNUCBXZWQgQXByIDMgMDg6
Mjg6NDkgVVRDIDIwMTkgeDg2XzY0IHg4Nl82NCB4ODZfNjQgR05VL0xpbnV4Cg==

Funkci pak můžeš používat stejně jako by to byl příkaz/program a propojovat je rourami s dalšími příkazy.

V tvém případě by to tedy vypadalo nějak takhle:

prohledejLog() { grep srcip=192.168.1.10 | grep dstip=192.168.2.10 | grep dstport=8090"; }
cat /mnt/syslog/network/fg-int/fg-int.log | prohledejLog

Roura | je součást syntaxe jazyka – to bys neměl míchat dohromady s daty (obsah proměnných).

_{[1] v tom bash -c "…", kde se proměnná vyhodnotí ještě před předáním tomu bashi a poslepuje se z ní kód}

[xkucf03]

První věc, sice off-topic, ale přece: cat má název podle slova concatenate — používat ho na jediný soubor je zbytečné.

Teď k tématu: Takové filtrování patří do funkce, ne do proměnné. Mít příkazy v proměnné s sebou pokaždé nese spoustu ošklivosti v podobě buď eval nebo spouštění shellu stylem něco | bash. Ve funkci se dá takový filtr nadefinovat a později spustit.

my_outdated_ip_address_filter() {
  grep 'srcip=192\.168\.1\.10' |\
  grep 'dstip=192\.168\.2\.10' |\
  grep 'dstport=8090'
}

my_outdated_ip_address_filter < /mnt/syslog/network/fw-int.log

[debian+]

Len domam, ze definici funkciu, prikazov a aliasov zistis cez:

set

Nieco sa da zistit aj cez napr:

type less

[PD321]

Díky debian+, funguje. Ještě bych jenom dodal, proč to mám v proměnný. Příklad jsem maximálně zjednodušil, aby bylo vidět, kde je problém. Ve skutečnosti skript GREPy nemá, ale dostává je ve formě parametru od PHP skriptu, kterej je podle potřeby sestavuje. Ve skriptu se pak nacházej v proměnný $2 (v $1 je uložen název souboru).

[xkucf03]

Ve skutečnosti skript GREPy nemá, ale dostává je ve formě parametru od PHP skriptu, kterej je podle potřeby sestavuje. Ve skriptu se pak nacházej v proměnný $2 (v $1 je uložen název souboru).

Pak tedy přeji hodně štěstí. Pravděpodobně se ti tam bude dít něco jako SQL injection, akorát se tam nebude injektovat SQL, ale kód v shellu. Takhle tam z toho PHP půjde podstrčit libovolný příkaz… a pokud se to slepuje ze vstupů od uživatele (potenciálního útočníka), tak to není dobré.

Už jsem takhle viděl třeba WiFi router, který měl ve webovém rozhraní funkci ping – zadal jsi IP adresu a ono to vypsalo výstup příkazu ping. Jenže pokud jsi do políčka s IP adresou dal ty správné uvozovky/apostrofy, tak to nejen spustilo ten ping, ale i tebou zadaný příkaz a vypsalo jeho výstup.

Vážně by bylo lepší to přepsat s těmi funkcemi a striktně oddělovat data a kód. Kód je spustitelný a měl bys ho mít plně pod kontrolou. Data jsou jen neživé datové struktury, které samy od sebe nic nedělají. Data můžou být třeba seznam položek oddělených znakem konce řádku nebo nulovým bajtem… V Bashi si z toho uděláš pole, bezpečně předáváš dál…

Ono jde v Bashi sice různě „kouzlit“ a dělat třeba proměnné proměnné (obdoba ukazatelů) nebo proměnné ukazující na funkce/příkazy, které se pak volají, nebo ten dynamicky spouštěný kód přes bash -c "…", co tam máš, a spoustu dalších hacků… ale pokud to vyloženě nepotřebuješ a nevíš přesně, co děláš, tak je lepší se tomu vyhnout a navrhovat ty skripty jednodušeji.

[PD321]

Útoku jsem si vědom. Vstup na HTML stránku je chráněn firewallem a přístup na ní mám jenom já. Pochopitelně se to budu snažit zjednodušit a víc zabezpečit.

[Andrej]

Nic z uvedeného není důvodem, proč by grepy nemohly být ve funkci.

[debian+]

Oboznam sa a nauc sa pripadne pouzivat /dev/shm.

[Kit]

V tom případě bych raději v tom PHP udělal i to filtrování.

Další možností je využití AWK, které zvládne sestavení podmínky i celé filtrování. Stačí pak jediný proces.

Pokud trváš na filtrování grepem, nechej si v PHP vygenerovat jednu podmínku na jednom řádku. Bude to flexibilnější.

[Andrej]

Ještě abych upřesnil, jak se lze vyhnout těm ošklivým grepům nebo výrazu pro pipeline v proměnné, tady je drobný příklad.

Co takhle mít skript, který dostane v "$1" název souboru a pak budou následovat regulární výrazy pro grep? Skript z regulárních výrazů automaticky sestaví filtrovací pipeline a soubor skrz ni protlačí. Zavolá se třeba takto:

./filters.sh /mnt/syslog/network/fw-int.log \
             'srcip=192\.168\.1\.10' \
             'dstip=192\.168\.2\.10' \
             'dstport=8090'

A celý filters.sh může vypadat například takto:

set -e -o pipefail -u

my_magic_filter() {
  local -r filters_name="$1"
  local -rn filters="$filters_name"
  local -ri current_filter="$2"
  local -ri last_filter="$(("${#filters[@]}" - 1))"
  if ((current_filter == last_filter)); then
    grep "${filters[current_filter]}"
  else
    grep "${filters[current_filter]}" |\
    my_magic_filter "$filters_name" "$((current_filter + 1))"
  fi
}

declare -r file_name="$1"
shift
declare -ar array_of_filters=("$@")

my_magic_filter 'array_of_filters' 0 < "$file_name"

Tam^^^ pochopitelně zoufale chybí ošetření chyb, například (1) špatného počtu a typu parametrů pro my_magic_filter(), (2) špatných indexů pole a podobně. Pro obecnější nasazení je třeba tohle doladit.

Jak už tady bylo řečeno, fakt je asi lepší udělat to přímo v PHP (nebo snad možná v awk). Já osobně bych to asi nakódil v PHP, kdybych musel. Bude to efektivnější než spouštět takhle Bash na každý požadavek.