ugrás a tartalomhoz

Van-e PHP és milyen verzió?

mind1 valami név · 2019. Jan. 11. (P), 09.38
Kívülről hogy lehet megállapítani egy web szerverről, hogy van-e rajta PHP és ha van, akkor milyen verzió?
Kívülről alatt azt értem, hogy böngészőből/curl/wget/egyéb segédeszköz segítségével.
Van erre valami bevett módszer?

Az a baj, hogy nem tudom eltalálni a megfelelő keresőkifejezést, így a nyomorult google csupa olyan találattal szórakoztat, hogy hozzak létre egy .php file-t...
 
1

Fejlécek

Endyl · 2019. Jan. 11. (P), 10.32
Ha a szerver hirdetni akarja, hogy milyen PHP-t futtat, akkor érdemes megnézni vagy a Server, vagy pedig az X-Powered-By fejléceket. Ezen felül nincs ötletem.
2

Köszi. Végül is reverse

mind1 valami név · 2019. Jan. 11. (P), 10.35
Köszi.
Végül is reverse engineering is bevethető :)
Felrakok egy PHP-t és megnézem, mennyiben változik a fejléc a PHP nélkülihez képest.
3

Kiemelném a feltételes módot,

Pepita · 2019. Jan. 11. (P), 10.40
mert sokszor nem akarja ("Ha a szerver hirdetni akarja").
4

Na jó... akkor mesélek...

mind1 valami név · 2019. Jan. 11. (P), 10.47
Na jó... akkor mesélek... :D

Látom már évek óta a routerek logjában, hogy folyamatosan próbálkoznak mindenféle botok 80-as, 443-as, 23-as, 22-es portokon.
Gondoltam, megnézem, hogy ha beengedem egy konténerbe ezen forgalom egy részét és mondjuk egy python szkriptből eljátszom, hogy ez egy PHP szerver, akkor mit reagálnak a próbálkozók. :)
Ha csak pár header beállítás kell hozzá, hogy elhitessem velük, ez egy PHP-s szerver miközben nincs rajta semmi... szórakoztató lehet a logja... :)
5

Szerintem még valami

inf · 2019. Jan. 11. (P), 21.55
Szerintem még valami joomla/drupal/wordpress beléptető oldalt is heggesszél nekik oda Pythonnal, lehetőleg olyat, ami sosem lép be, aztán lesznek ott nyalánkságok. Arra figyelj, hogy rotáld a logokat, mert hamar el tud fogyni a tárhely. Nekem volt már, hogy betelt a C meghajtó, mert valaki hekkelte az itthoni dyndns szervert.
6

Na annyira azért nem megy a

mind1 valami név · 2019. Jan. 11. (P), 22.14
Na annyira azért nem megy a dolog. Ahhoz, hogy ezeket beszopják ténylegesen, elég komoly tudás kellene.
A docker log egyébként hová megy? Mert nekem úgy tűnt, csak memóriába, ha nem rendelkezek másképp...
8

Melyik log?

Pepita · 2019. Jan. 12. (Szo), 15.43
Ha valamilyen webszervert üzemeltetsz, akkor - konténeren belül - meg van a logjainak a helye. Ez nem (csak) a memóriában van, hanem van egy virtual disc az image-ek számára, ebből egy adott terület az adott konténeré.
(windowson default C:\Users\Public\Documents\Hyper-V\Virtual Hard Disks\MobyLinuxVM.vhdx)
Ha ki linkeled, akkor a gazdagépről is tudsz benne túrkálni.
Pl. egy apache-php konténer esetén:
services:

  apache-php:

    build:
      context: ./docker/apache_php
      dockerfile: Dockerfile
    container_name: apache-php
    ports:
      - 80:80
    environment:
      APP_ENV: "dev"
    volumes:
      - ./:/var/www/
      - ./log:/var/log/
      # this takes advantage of the feature in Docker that a new anonymous
      # volume (which is what we're creating here) will be initialized with the
      # existing content of the image at the same location
Így a teljes (konténeren belüli) /var/log/ tartalmát láthatod és módosíthatod a gazda gépről. (Plusz ha build-kor van a "kinti" ./log könyvtárban valami, akkor azzal együtt jön létre és indul el a konténer, de a kérdésed szempontjából ez lényegtelen, inkább configokat szokás betolni vele.)
9

Hülyeség volt a kérdés.

mind1 valami név · 2019. Jan. 12. (Szo), 16.02
Hülyeség volt a kérdés. Automatikusan --rm kapcsolóval futtatom a konténereket, ez meg ugye amint leáll a konténer, eltüntet mindent, ami hozzá tartozik.
10

Ja bocs,

Pepita · 2019. Jan. 12. (Szo), 16.28
ezt compose fájlból másoltam ki, de ha kézzel indítod, szerintem akkor is lehet mountolni, de nem tudom hogy.
--rm - mel is ugyanazon a virtual disken van, így viszont csak futás közben tudsz belépni a konténerbe és belül nézelődni.
Mondjuk ha lesz konkrét ötlet, hogy milyen konténerrel akarod, akkor javaslom a compose használatát.
11

Azt hiszem 1/2-reértesz: azt

mind1 valami név · 2019. Jan. 12. (Szo), 16.41
Azt hiszem 1/2-reértesz: azt hittem, hogy a konténer logja csak a memóriában őrződik meg, mert utólag sohasem tudtam megnézni, csak az kiment a fejemből, hogy azért nem tudom megnézni a docker logs segítségével, mert már nem létezik a konténer, miután leállt.
Egyébként az "official" nginx konténer a stdout-ra küldi az nginx logot - legalábbis abból ítélve, hogy ha "docker run --it --name xx nginx" paranccsal indítom, akkor ott látom a konzolon, élőben.
12

Jaja, már értem :)

Pepita · 2019. Jan. 12. (Szo), 17.13
ha "docker run --it --name xx nginx"

az --it miatt van, ezzel "mondod meg", hogy interaktív legyen és konzol a stdout. Mondjuk picit csodálkozom, hogy stdout-ra logol, nem direkt fájlba..

Ha olyasmit csinálsz, mint a fentebbi docker-compose.yml részlet, akkor a build: helyett image: nginx, a parancs pedig
docker-compose up -d.
Így viszont nem fog törölni semmit, neked kell (docker-compose down). Ja és a volume-okat a Te konténerednek megfelelően kell belőni.
Én biztos így "lesnék" logokat, konténerbe lépve tényleg csak olvasni lehet, már a másolás is bajos. :)
13

# cd /var/log/nginx# ls

mind1 valami név · 2019. Jan. 12. (Szo), 17.24
# cd /var/log/nginx
# ls -l
total 0
lrwxrwxrwx 1 root root 11 Dec 29 03:31 access.log -> /dev/stdout
lrwxrwxrwx 1 root root 11 Dec 29 03:31 error.log -> /dev/stderr

Egy rejtély megfejtve. :)
Ez akkor is ilyen, ha "docker run -d nginx" indítja.
14

Hehe,

Pepita · 2019. Jan. 12. (Szo), 18.29
akkor ha compose-zal buildelsz, nem is lesz elég megadni a "hivatalos" image-et, hanem (valószínű) saját Dockerfile - ban ide bele kell nyúlnod. :-D

Bár az is lehet egy út, hogy megnézzük a hivatalos oldalt, itt én a legelső Dockerfile-ba néztem bele, a vége felé meg is találtam a két symlinket:
# forward request and error logs to docker log collector
RUN ln -sf /dev/stdout /var/log/nginx/access.log \
	&& ln -sf /dev/stderr /var/log/nginx/error.log
Valahogy a hostot is biztos meg lehet tanítani, hogy mit kezdjen az átadott logokkal, de én biztos inkább a két symlinket semmisíteném meg.
Itt viszont elgondolkodtam, hogy melyik a kevésbé csúnya megoldás:
- Leszármazni ebből az image-ből és törölni a már létrehozott linkeket, vagy
- Lemásolni a Dockerfile-t és törölni azt a két sort.

Na ettől szép az élet. :-D
7

Úgy is rápróbálnak ezekre az

BlaZe · 2019. Jan. 12. (Szo), 01.33
Úgy is rápróbálnak ezekre az url-ekre, hogy nem hirdeti magát :) Nekünk a saját szerverünkön, amin pár baráttal vagyunk rendszeresen tele az access.log wp-admin.php és társai próbálkozásokkal. Pedig még csak hasonló sem volt fent soha :)