Linux-security

Sziasztok!

Mindenféle próbálgatások jönnek az egyik szerveremre. Például (Logwatch-ból idézve az egyszerűség kedvéért.):

[...]http://1.x.1.x.1:80/2phpmyadmin/: 1 Time(s)
http://1.x.1.x.1:80/MyAdmin/: 1 Time(s)
http://1.x.1.x.1:80/PMA/: 1 Time(s)
http://1.x.1.x.1:80/PMA2011/: 1 Time(s)
http://1.x.1.x.1:80/PMA2012/: 1 Time(s)
http://1.x.1.x.1:80/admin/: 1 Time(s)
http://1.x.1.x.1:80/admin/db/: 1 Time(s)
http://1.x.1.x.1:80/admin/pMA/: 1 Time(s)
http://1.x.1.x.1:80/admin/phpMyAdmin/: 1 Time(s)
http://1.x.1.x.1:80/admin/phpmyadmin/: 1 Time(s)
http://1.x.1.x.1:80/admin/sqladmin/: 1 Time(s)
[...]

Sok-sok ilyen van. (Van, hogy másodpercenként 10-20 kérés, van, hogy 3-4 percenként 1-1 kérés.) A fail2ban kézenfekvő lenne, de a .local fail2ban fájlban nem találtam erre vonatkozó leírást, sem a dokumentációban mert ez az apache.log-ban jelenik meg, nem az errorban.
Kényelmesebb lenne a fail2ban-t felhasználni erre.
Van tippetek a fail2ban konfigra? Vagy inkább iptabples lesz a megoldás?

A válaszokat előre is köszönöm.

Sziasztok!

Érdeklődni szeretnék, hogy valaki használ -e valami más technológiát apache szerver domain auth-ra?
Igazából valami olyasmi kellene, hogy a felhasználó a böngészőjével belépne egy weboldalra és automatikusan felküldi a domain name és password párost, viszont ha nem tartományi gép lépne be a felületre, akkor az kézzel beírja a felhasználói név és jelszópárost, aztán kész :)

Idáig a apache kerberos moduljával szívtam, de az istennek sem jön össze :(

Valakinek ötlete?

Köszönöm szépen

Kedves Fórumozók! Néha hozzászólok, néha kérdezek. Most ez utóbbi...

Alapfelállás, hogy a CentOS7 szervereink tűzfalában a 22-es port egy fix IP-ről érhető el. Néha az itthoni munkához jó lenne belépni. Alternatív megoldás az irodai gépemre RDP, ott putty, tűzfal ki+be, közben belépés itthonról.

(Korábban próbáltam átrakni 2222-re vagy 32876-ra, de akkor sem kevesebb a próbálkozás. Jelszó elég erős, nem jutottak még be, de rossz volt látni login után a "7653 unsuccessful login attempt..." feliratot. Próbálkoztam a THome IP tartományával a tűzfalban, de elég gyakran változik az eleje is és egyébként jó lenne elérni egy freewifi-ről is)

Az alternatív megoldások helyett jó lenne valami szép. Találtam olyat, hogy OTPW (one time password: http://xmodulo.com/secure-ssh-login-one-time-passwords-linux.html) és two factor by google (http://xmodulo.com/two-factor-authentication-ssh-login-linux.html). Mindkettő jópofa, de akkor is látom/látnám a próbálkozásokat. A google two-way-re még hajlanék is, szép megoldás, de: "When change your phone-device there is no way to actually move all your saved Authenticator accounts to your new device. You have to re-link them one by one." Továbbá jó lenne ha az irodából (munka 99%-a ott van), nem kellene semmi különös.

Ezért a tűzfal nyitogatásra szavaznék, elég 30mp-re kinyitni, amíg elindítom az SSH sessiont.

Kérdésem: találkozott-e valaki kész megoldással SMS vagy e-mail kiküldés formájában, benne egy link, amire kattintva kinyílik? Úgy általában mi a véleményetek erről a megoldásról?

Köszönöm!

RHEL7.2-n:

# pkaction -v -a org.freedesktop.login1.power-off
org.freedesktop.login1.power-off:
  description:       Power off the system
  message:           Authentication is required for powering off the system.
  vendor:            The systemd Project
  vendor_url:        http://www.freedesktop.org/wiki/Software/systemd
  icon:
  implicit any:      auth_admin_keep
  implicit inactive: auth_admin_keep
  implicit active:   yes

A polkit manualja szerint:

allow_active
   Implicit authorizations that apply to clients in active sessions on local consoles. Optional.

Azaz ha user bejelentkezik konzolról, akkor poweroff-fal le tudja állítani a gépet (ha épp nincs senki bejelentkezve). Ha meg igen, akkor is nyomhat egy systemctl poweroff -i parancsot, erre még tippet is ad neki a rendszer.

Ez nekem nem tetszik... RH kiadott rá egy KB cikket, hogy lehet 'javítani'. Amit nem értek, hogy ez defaultban miért van engedélyezve (más egyéb tevékenységekkel együtt, ld. pkaction -v). Oké, hogy van konzol hozzáférése, de ne segítsünk még neki, szerintem.

polkit.addRule(function(action, subject) {
  if (action.id == "org.freedesktop.login1.power-off" ||
      action.id == "org.freedesktop.login1.power-off-multiple-sessions" ||
      action.id == "org.freedesktop.login1.reboot" ||
      action.id == "org.freedesktop.login1.reboot-multiple-sessions" ||
      action.id == "org.freedesktop.login1.inhibit-block-shutdown" ||
      action.id == "org.freedesktop.login1.inhibit-delay-shutdown" ||
      action.id == "org.freedesktop.login1.suspend" ||
      action.id == "org.freedesktop.login1.suspend-multiple-sessions" ||
      action.id == "org.freedesktop.login1.suspend-ignore-inhibit" ||
      action.id == "org.freedesktop.login1.hibernate" ||
      action.id == "org.freedesktop.login1.hibernate-multiple-sessions")
  {
    return polkit.Result.NO;
  }
});

Az utóbbi vanilla kernelek ilyen időközökkel jöttek ki egymás után:

10 nap
5 nap
4 nap
2 nap

Mindegyikhez egyben tartozott egy-egy longterm kiadás is, sőt, longtermben volt olyan, hogy az adott verzió megjelenését egy nappal követte a következő. Mindezt november elejétől nézem. A changelogok mérete sem elhanyagolható, nem egy-egy patch-ről van szó.

Valaki tud valamit? Auditálják a kódot? Több szem többet lát?

Nem szoktam minden CVE bejegyzest kovetni, de azert ez megdobbentett.
Tegnap ki is probaltam, es fekszik a story.

Ami engem zavar, ez a panic mode. Barmilyen gond adodik az initramfs noramal futsa soran, dob egy root emergency shellt.
Mintha single userkent inditottuk volna a gepet. Es ami a legrosszabb, hogy switchroot sem szukseges.

Könnyednek szánom a felvetést, mert nem jártam alaposabban utána a kérdésnek, így lehetnek tévedéseim. Mégis megosztok egy érdekes tapasztalatot.

Van egy live Fedorám, amelyet virtuális gépben magamnak készítek. A /home tmpfs-re van téve, s induláskor tömörített file-ból tar-olom ki a legutóbb mentett profilt, illetve, ha ez nincs, egy default profilt rsync-kel másolok ide. A legújabb image-em elkészítése után nem tudtam bejelentkezni. Nézem, nincs a /home alatt a felhasználónak alkönyvtára, a selinux megakadályozta az rsync-et abban, hogy itt létrehozzon bármit is. A script, amelyik az rsync-et futtatta, az rc.local-ból induló, majd háttérben futó shell script volt root joggal.

Gondoltam egyet, s az rc.local-ba ezt írtam:

chcon -t tmp_t /home

Majd, amikor az rsync bemásolta a felhasználói profilt, fusson ez:

restorecon -F /home

Ezzel visszaállítottam a home_root_t típust.

Nem tudom, hogy szándékos-e az, hogy ugyan nem tudok alkönyvtárat létrehozni a scriptemből futó rsync által - permission denied -, ugyanakkor a típust megváltoztathatom, majd megcsinálhatom, amit szeretnék, végül a típust visszaállíthatom. Mert ez így inkább a népek bosszantása, mintsem valós biztonság.

A megfigyelésem annyiban nem korrekt, hogy a chcon az rc.local-ból fut, míg az rsync az rc.local által indított, majd háttérben futó scriptből.

Sziasztok!

Az lenne a kérdésem, hogy miért írja ezt squid, mikor sem virustotal, sem nod nem jelez az adott oldalra?

The requested URL http://trackitonline.ru/?action=login contains a virus
Virus name: SecuriteInfo.com.JS.Privatelife-1.UNOFFICIAL

Sziasztok!

Meglévő Wifi hálózatot kellene kiegészítenem egy captive portal-lal, ami egy jelszó után engedné a netet. Úgy olvastam talán a Pfsense a legmegfelelőbb erre.
Hülye kérdésem az lenne, hogy a fizikai kiépítés hogy nézne ki? A meglévő wifi routeren le kéne tiltani a wifi-t és a pfsense-et futtató gépbe kellene egy wireless kártya? Vagy maradhat a router a wifi kiszolgáló?
Vagy két hálókártya a pfsense-be, egyikbe a net, másikba a router?

Köszönöm!

Sziasztok,

Nemrég napvilágra látott a Win.Exploit.CVE_2016_3316-1, az amavisd pedig a levelezőszerveren szépen elkezdte a word docokat megfoni, nem továbbengedni. Infected, kész.

Kérdésem lenne, hogy hogy lehetne azt az amavisdnak megmondani pl egy regexppel, hogy milyen virusokat engedjen át? ez globális lenne, nem domainhez, vagy sender köthetően.

Talán másnál is aktuális (lesz) a probléma.

köszönöm.