Biztonsagos webszerver?

Linux-security

Biztonsagos webszerver?

  • 991 megtekintés

( meditor | 2005. 03. 27., v – 11:44 )

Ebbe a topikba írok, mert szerintem ide tartozik. A mellékelt sorokat
az apache loggolja ki: egy részlet az access.log-ból. Nem tudom
jóindulatúnak minősíteni, mert pl a /etc/password file-t is
piszkálgatni akarták és jvs-ek és cgi-k iránt is komoly érdeklődést
mutatott a delikvens. Úgy tűnik minden kezdeményezés 404-gyel
vissza lett vágva, de mégis mi ez? Láttatok már ilyet?

81.183.145.18 - - [25/Mar/2005:21:37:27 +0000] "GET /README/ HTTP/1.1" 404 278
81.183.145.18 - - [25/Mar/2005:21:37:27 +0000] "GET /ROADS/ HTTP/1.1" 404 277
81.183.145.18 - - [25/Mar/2005:21:37:27 +0000] "GET /Readme/ HTTP/1.1" 404 278
81.183.145.18 - - [25/Mar/2005:21:37:27 +0000] "GET /SilverStream/ HTTP/1.1" 404 284
81.183.145.18 - - [25/Mar/2005:21:37:27 +0000] "GET /Stats/ HTTP/1.1" 404 277
81.183.145.18 - - [25/Mar/2005:21:37:27 +0000] "GET /StoreDB/ HTTP/1.1" 404 279
81.183.145.18 - - [25/Mar/2005:21:37:27 +0000] "GET /Templates/ HTTP/1.1" 404 281
81.183.145.18 - - [25/Mar/2005:21:37:27 +0000] "GET /ToDo/ HTTP/1.1" 404 276
81.183.145.18 - - [25/Mar/2005:21:37:27 +0000] "GET /WebBank/ HTTP/1.1" 404 279
81.183.145.18 - - [25/Mar/2005:21:37:28 +0000] "GET /WebCalendar/ HTTP/1.1" 404 283
81.183.145.18 - - [25/Mar/2005:21:37:28 +0000] "GET /WebDB/ HTTP/1.1" 404 277
81.183.145.18 - - [25/Mar/2005:21:37:28 +0000] "GET /WebShop/ HTTP/1.1" 404 279
81.183.145.18 - - [25/Mar/2005:21:37:28 +0000] "GET /WebTrend/ HTTP/1.1" 404 280
81.183.145.18 - - [25/Mar/2005:21:37:28 +0000] "GET /Web_store/ HTTP/1.1" 404 281
81.183.145.18 - - [25/Mar/2005:21:37:28 +0000] "GET /XSL/ HTTP/1.1" 404 275
81.183.145.18 - - [25/Mar/2005:21:37:28 +0000] "GET /_ScriptLibrary/ HTTP/1.1" 404 286
81.183.145.18 - - [25/Mar/2005:21:37:28 +0000] "GET /_backup/ HTTP/1.1" 404 279
81.183.145.18 - - [25/Mar/2005:21:37:28 +0000] "GET /_derived/ HTTP/1.1" 404 280
81.183.145.18 - - [25/Mar/2005:21:37:28 +0000] "GET /_errors/ HTTP/1.1" 404 279
81.183.145.18 - - [25/Mar/2005:21:37:28 +0000] "GET /_fpclass/ HTTP/1.1" 404 280
81.183.145.18 - - [25/Mar/2005:21:37:28 +0000] "GET /_mem_bin/ HTTP/1.1" 404 280
81.183.145.18 - - [25/Mar/2005:21:37:28 +0000] "GET /_notes/ HTTP/1.1" 404 278
81.183.145.18 - - [25/Mar/2005:21:37:28 +0000] "GET /_objects/ HTTP/1.1" 404 280
81.183.145.18 - - [25/Mar/2005:21:37:28 +0000] "GET /_old/ HTTP/1.1" 404 276
81.183.145.18 - - [25/Mar/2005:21:37:29 +0000] "GET /_pages/ HTTP/1.1" 404 278
81.183.145.18 - - [25/Mar/2005:21:37:29 +0000] "GET /_passwords/ HTTP/1.1" 404 282
81.183.145.18 - - [25/Mar/2005:21:37:29 +0000] "GET /_private/ HTTP/1.1" 404 280
81.183.145.18 - - [25/Mar/2005:21:37:29 +0000] "GET /_scripts/ HTTP/1.1" 404 280
81.183.145.18 - - [25/Mar/2005:21:37:29 +0000] "GET /_sharedtemplates/ HTTP/1.1" 404 288
81.183.145.18 - - [25/Mar/2005:21:37:29 +0000] "GET /_tests/ HTTP/1.1" 404 278
81.183.145.18 - - [25/Mar/2005:21:37:29 +0000] "GET /_themes/ HTTP/1.1" 404 279
81.183.145.18 - - [25/Mar/2005:21:37:29 +0000] "GET /_vti_bin/ HTTP/1.1" 404 280

Előre is kösz az észrevételeket.

( andrej_ v | 2005. 03. 27., v – 12:51 )

- használj FreeBSD-t, azon pedig jaileket (sot van mar MAC framework is ide), securelevelt vagy linuxot grseces chroot-okkal
- apachehoz mod_security-t
- fektess le egy biztonsagi poliszit ami a T. Fejlesztokre, illetve a kodra vonatkozik es tedd le az orruk ele (pl. kodoljanak safe mode, openbasedir es reg globals tudataban, ellenorizzek a valtozookat stb)
- phpnal a phpinfo es shell hivasos es posix fuggvenyeket is tiltsad az elobb mondottak mellett
- lehetoleg ne hasznalj ftp-s feltoltes, scponly+winscp rulez (scponlyc tud chrootot, viszont nehezen managelheto ha sok a user)
- a webszervered minnel kevesebbet mondjon magaro: expose php off, servertokens prod es stb.
- csak kulcsos ssh kivulrol, nemstandard porton figyelo ssh-val es csak adott tartomanyokbol ateresztve a tuzfalon
- ha mindenfele admin okoskodas kell http, azt tereld https-re (pl. phpmyadmin) es ne defaultneveket hasznalj, https-t szinten csak adott tartomanyokbol ereszd be a tuzfalon ha lehet

Lehetne meg szerintem estig sorolni, de talan ezek a lenyegesebbek.

meditor: Pont ilyet meg nem, de valami defaulthekket probalt meg vmi robot. Ezek ellen nem sokat lehet tenni, plane hogy apache 404-el visszatolja mindet. Ha jobb szeretned ellenorizni a http kereseket akkor mod_security-t javaslom neked is.

( meditor | 2005. 03. 27., v – 13:17 )

[quote:268d041094="andrej_"]
Lehetne meg szerintem estig sorolni, de talan ezek a lenyegesebbek.

meditor: Pont ilyet meg nem, de valami defaulthekket probalt meg vmi robot. Ezek ellen nem sokat lehet tenni, plane hogy apache 404-el visszatolja mindet. Ha jobb szeretned ellenorizni a http kereseket akkor mod_security-t javaslom neked is.

Kössz Andrej. Amiket javasoltál, abból nekem sok meg van,
a slack defaultból szolgáltatja. Az ssh-t át fogom rakni a 22-es
portról. A robotokkal meg ugyebár nem nagyon lehet semmit
csinálni. Az azért elgondolkodtató, hogy kinyúlt az
/etc/password-ért.

Ja! volt egy másik ugyanilyen támadás ezt megelőzően egy nappal.
Mind a kettő az axelero vonaláról jött. Nem lehet ilyenkor megkérni
az axelerót, hogy nézzen már utána ki volt ez, mellékelve
a logfile-t?

( Dwokfur v | 2005. 03. 27., v – 14:02 )

[quote:6760cfccbd="meditor"][quote:6760cfccbd="andrej_"]
Lehetne meg szerintem estig sorolni, de talan ezek a lenyegesebbek.

meditor: Pont ilyet meg nem, de valami defaulthekket probalt meg vmi robot. Ezek ellen nem sokat lehet tenni, plane hogy apache 404-el visszatolja mindet. Ha jobb szeretned ellenorizni a http kereseket akkor mod_security-t javaslom neked is.

Kössz Andrej. Amiket javasoltál, abból nekem sok meg van,
a slack defaultból szolgáltatja. Az ssh-t át fogom rakni a 22-es
portról. A robotokkal meg ugyebár nem nagyon lehet semmit
csinálni. Az azért elgondolkodtató, hogy kinyúlt az
/etc/password-ért.

Ja! volt egy másik ugyanilyen támadás ezt megelőzően egy nappal.
Mind a kettő az axelero vonaláról jött. Nem lehet ilyenkor megkérni
az axelerót, hogy nézzen már utána ki volt ez, mellékelve
a logfile-t?

Én már track-eltem vissza user-t régebben a Datanet-nél. Csak mit csinálsz akkor, ha tudod, hogy ki a júzer?

Üdv,
Dw.

( ghost | 2005. 03. 27., v – 14:33 )

[quote:d051dfff83="Dwokfur"][quote:d051dfff83="meditor"][quote:d051dfff83="andrej_"]
Lehetne meg szerintem estig sorolni, de talan ezek a lenyegesebbek.

meditor: Pont ilyet meg nem, de valami defaulthekket probalt meg vmi robot. Ezek ellen nem sokat lehet tenni, plane hogy apache 404-el visszatolja mindet. Ha jobb szeretned ellenorizni a http kereseket akkor mod_security-t javaslom neked is.

Kössz Andrej. Amiket javasoltál, abból nekem sok meg van,
a slack defaultból szolgáltatja. Az ssh-t át fogom rakni a 22-es
portról. A robotokkal meg ugyebár nem nagyon lehet semmit
csinálni. Az azért elgondolkodtató, hogy kinyúlt az
/etc/password-ért.

Ja! volt egy másik ugyanilyen támadás ezt megelőzően egy nappal.
Mind a kettő az axelero vonaláról jött. Nem lehet ilyenkor megkérni
az axelerót, hogy nézzen már utána ki volt ez, mellékelve
a logfile-t?

Én már track-eltem vissza user-t régebben a Datanet-nél. Csak mit csinálsz akkor, ha tudod, hogy ki a júzer?

Üdv,
Dw.

Mondjuk írsz neki egy levelet és megkérdezed tőle, hogy mi szüksége lenne a te password filodra. Nyugodtan meg lehet kérdezni, hogy mikor látogatta meg utoljára a bsa? :D

( zsirfeka | 2005. 03. 27., v – 16:55 )

[quote:f6ba87a113="ghost"]Mondjuk írsz neki egy levelet és megkérdezed tőle, hogy mi szüksége lenne a te password filodra. Nyugodtan meg lehet kérdezni, hogy mikor látogatta meg utoljára a bsa? :D

aham, es szerencsetlen juzernek jo esellyel fogalma sem lesz rola, hogy mi tortent, mert vagy egy szejjeltort geprol futo bot csinalta, vagy valami agyatlan kiddie. persze lehet kemenykedni, csak eppen semmi ertelme.
(az ISP meg meg valoszinuleg egyebkent is le fogja szarni a kerest)
megint elkezdi valaki ugyanazt a kabaret, mint a bruteforce ssh tamadasoknal?

( nug | 2005. 01. 13., cs – 23:17 )

Sziasztok!

Hamarosan fel kell huznom egy webszervert ami tobb weboldalt szolgal ki (php/mysql/cgi).

Ti hogyan szoktatok elszeparalni egymastol a kulonbozo weboldalakat?
Egyaltalan erdemes-e, kell-e?

Gondolok itt en chroot-ra, http://user-mode-linux.sourceforge.net/-ra vagy egyeb megoldasra.

Tapasztalatom szerint a webfejlesztokben nem igazan lehet megbizni, komplexebb oldal eseten ugyis hagynak valami hibat a kodban. Ez ellen hogyan vedekeznetek?

Koszonottel fogadok minden otletet!

( Panther v | 2005. 03. 27., v – 18:11 )

Az IP címeket hamisítani is lehet, amit csak részben tudnak kiszűrni a routerek, tehát még az is kérdéses, valóban onnan jött-e.

Sokszor olyan ip címekről is támadnak, amihez nem létezik DNS bejegyzés (visszafelé legalábbis).

( meditor | 2005. 03. 27., v – 20:24 )

[quote:77f257440a="Panther"]Az IP címeket hamisítani is lehet, amit csak részben tudnak kiszűrni a routerek, tehát még az is kérdéses, valóban onnan jött-e.

Sokszor olyan ip címekről is támadnak, amihez nem létezik DNS bejegyzés (visszafelé legalábbis).

O.K., akkor hagyjuk. Ezzel úgylátszik együtt kell élni.
Tekintsük a rendszer zajának.

( drojid | 2005. 01. 14., p – 08:35 )

[quote:85499b4eb5="nug"]Tapasztalatom szerint a webfejlesztokben nem igazan lehet megbizni ... Ez ellen hogyan vedekeznetek?

1. Dolgozz megbízható webfejlesztőkkel
2. Ha elmész péknek, akkor nem lesz ilyen gondod :wink:

Ez olyan volt, mintha én azt mondanám, hogy a rendszergazdákban nem lehet megbízni, mert mindig hagynak valami biztonsági rést egy nagyobb rendszeren. (De ez butaság, úgyhogy nem mondom :) )

Eredeti kérdésedre, bár erre biztos lesz kimerítőbb válasz is, az a minimum, hogy jailbe zárod.

( Panther v | 2005. 03. 27., v – 20:36 )

[quote:5dc1b58e07="meditor"]O.K., akkor hagyjuk. Ezzel úgylátszik együtt kell élni.
Tekintsük a rendszer zajának.

Bár én az ilyen ip címeket tiltani szoktam, egy éles szerveren, mint pl a hup is, ez már nem megoldás. A vírusok, stb ellen nem lehet semmit tenni ilyen esetben - pl nimda szép bejegyzéseket produkált még pár hónapja is az apache logomba. Azért a kedvencem a kb 16 kbyos SEARCH kérés, amiben \x90 meg \xb1\x02 szerepel minden mennyiségben.

Szerintem is mod_securityt érdemes használni (ha kiszűr valamit, akkor 500 - internal server error-t dob, vagy más is beállítható neki)

( nug | 2005. 01. 14., p – 09:47 )

[quote:ed48167d30="drojid"][quote:ed48167d30="nug"]Tapasztalatom szerint a webfejlesztokben nem igazan lehet megbizni ... Ez ellen hogyan vedekeznetek?

1. Dolgozz megbízható webfejlesztőkkel

Dolgoznek en szivesen, de kepzeld el, lehet furan hangzik, de nem en hozom
az uzleti donteseket.

( bra | 2005. 03. 27., v – 21:46 )

[quote:81ac3b7098="meditor"][quote:81ac3b7098="andrej_"]
Lehetne meg szerintem estig sorolni, de talan ezek a lenyegesebbek.

meditor: Pont ilyet meg nem, de valami defaulthekket probalt meg vmi robot. Ezek ellen nem sokat lehet tenni, plane hogy apache 404-el visszatolja mindet. Ha jobb szeretned ellenorizni a http kereseket akkor mod_security-t javaslom neked is.

Kössz Andrej. Amiket javasoltál, abból nekem sok meg van,
a slack defaultból szolgáltatja. Az ssh-t át fogom rakni a 22-es
portról. A robotokkal meg ugyebár nem nagyon lehet semmit
csinálni. Az azért elgondolkodtató, hogy kinyúlt az
/etc/password-ért.

Ja! volt egy másik ugyanilyen támadás ezt megelőzően egy nappal.
Mind a kettő az axelero vonaláról jött. Nem lehet ilyenkor megkérni
az axelerót, hogy nézzen már utána ki volt ez, mellékelve
a logfile-t?

abuse@axelero.hu
De bármilyen információt csak rendőrségi feljelentésre fognak tudni adni.

( drastik | 2005. 01. 14., p – 09:51 )

en pl virtualhostokban kulonitem el a kulonfele weboldalakat
:)

( lipilee | 2005. 01. 14., p – 10:10 )

[quote:7cb98e6e91="drastik"]en pl virtualhostokban kulonitem el a kulonfele weboldalakat
:)

attól még vidáman cross-site scriptelhetnek a gonosz csúf hókuszpúkok.
nug: ha nem akarsz usermode linuxot tolni, és nem akarsz minden ügyfélnek külön chrootolt web/dbszervert adni, akkor suExec, suPHP, persze virtualhostok biztosan a te barátaid, de persze minden attól függ, mennyire vagy paranojid :)

( Hunger | 2005. 01. 14., p – 11:01 )

Érdemes megnézni a hardened-php-t.

Virtualhostonként pedig minimum:

php_admin_value safe_mode 1
php_admin_value open_basedir "/users/foobar/"
php_admin_value register_globals Off

( drastik | 2005. 01. 14., p – 11:43 )

[quote:357b9a2033="lipilee"][quote:357b9a2033="drastik"]en pl virtualhostokban kulonitem el a kulonfele weboldalakat
:)

attól még vidáman cross-site scriptelhetnek a gonosz csúf hókuszpúkok.
nug: ha nem akarsz usermode linuxot tolni, és nem akarsz minden ügyfélnek külön chrootolt web/dbszervert adni, akkor suExec, suPHP, persze virtualhostok biztosan a te barátaid, de persze minden attól függ, mennyire vagy paranojid :)

szted miert van egy smiley a hozzaszolas vegen?
(igen azert mert viccnek szantam de latom a humorerzeked talajmenti)