[Lenny]

Minkét gépen egy hálókártyára még egy hálózatot.

És azt már tudod irányítgatni...

[letix]

Idézet: Lenny - Dátum: 2007. nov. 27., kedd - 13:06

Minkét gépen egy hálókártyára még egy hálózatot.

És azt már tudod irányítgatni...

Eloszor is koszonom a segitokeszsegedet.

Elmeletben mar nekem is sikerult ezt kiokkumulalni,hisz logikus.Gyakorlatban viszont meg nem, remelem nem szegyen, hogy kezdo vagyok.

Igyekszem utannakeresni, gondolom valamifele virtualis interface-el orvosolhato a problema.


udv
letix

[bogdan]

szerintem az interface marad ugyanaz, csak a /etc/networks/interfaces-ben tobb sora is lesz. vagy a megfelelo vizualis modszerrel, amiket en nem ismerek.

[letix]

Ugy tunik nagy faba vagtam a fejszet , bar lehetseges hogy csak nekem az.

Lehet hogy en vagyok a mazochista beallitottsagu, de ez a legjobb az egeszben..Marmint hogy nem mukodik minden elsore,viszont ha mukodesre tudom birni, erteni is fogom mit-merre-hogyan.

udv
letix

[Lenny]

Idézet: bogdan - Dátum: 2007. nov. 27., kedd - 15:52

szerintem az interface marad ugyanaz, csak a /etc/networks/interfaces-ben tobb sora is lesz. vagy a megfelelo vizualis modszerrel, amiket en nem ismerek.

pl. eth0:0

[critical_source]

Idézet: letix - Dátum: 2007. nov. 27., kedd - 17:10

Ugy tunik nagy faba vagtam a fejszet , bar lehetseges hogy csak nekem az.

Lehet hogy en vagyok a mazochista beallitottsagu, de ez a legjobb az egeszben..Marmint hogy nem mukodik minden elsore,viszont ha mukodesre tudom birni, erteni is fogom mit-merre-hogyan.

udv
letix

szerintem ezt inkább tanulásnak hívják 

[Mono]

Sziasztok!

Elakadtam picit

Van egy Suse Linux-om, melynek a logolását syslog végzi.
Van egy Debian-om, mely logolását syslog-ng végzi, php-syslog-ng-vel megspékelve.

Azt szeretném, hogy a SuSE syslog-ja hálózaton keresztül a Debian syslog-ng által kezelt logjai közé is kerüljenek. Azaz maradjanak meg a SuSE logoka a SuSE gépen is logfájlban, de küldje át a Debian-ra is.
Tûzfalak már ki vannak kapcsolva, azok nem kavarhatnak be.
SuSE syslog.conf állományába beírtam ezt:
*.*                          @logserver
Majd ezután persze a syslog újra lett indítva. A SuSE géprõl természetesen pingelhetõ a "logserver", ami egyébként a Debian, melyen a syslog-ng fut.

Próbálom a logserveren monitorozni az eseményeket a messages, valamint a syslog fájlokban, de semmi nyoma annak, hogy a SuSE próbálkozna logok küldésével - véleményem szerint még ha nem is lenne jól beállítva a syslog-ng, akkor is kellene látnom valami próbálkozást, nem
A SuSE logok között semmi plusz nincs erre utalólag.

Magyarán látszólag mindenki el van foglalva a saját logjával, logolásával és nem hajlandó ennél többre

Mit javallotok, mit csinálok rosszul. mi hiányzik még

[Friczy]

Elsõ körben: ellenõrizd hogy a @logserver névfeloldása jó-e (ha nem IP van ott, hanem név). Aztán ha van rá lehetõséged, nézd meg, hogy a Suse-rõl ténylegesen elmennek-e a csomagok (syslog alapból UDP/514 porton logol). Aztán ellenõrizd, hogy a Debianon a syslog-ng figyel-e az 514-es UDP porton (default configban nem szokott). Ha van iptables szabályod, akkor azt is ellenõrizd, hogy beengedi-e a csomagokat. Ha mindez megvan, és mégsincs log, akkor itt is tcpdump, hogy eljut-e ide a log.

További ötleteket ezen eredmények ismeretében lehet mondani.

[bugmenot]

Kérdésem lenne: kezembe került egy egész pofás PII konfig (ASUS alaplap, rakat ISA-PCI csati, P 200 MMX proci, 64 MB RAM)
Ennyi lenne a dolga: router, Qos, proxy*,fileserver illetve ha lesz WLAN kártya, akkor AP is lenne. Késõbbiek folyamán talán SMTP szerver meg webszerver, de egyelõre ezek nem lényegesek funkciók. Linuxszal foglakoztam már desktop szinten, szerveren most kezdõdne a móka    Raknék rá valami egyszerû GUI-t (pl. Xfce), mert azért én azt jobban kezelem még. Elég erõs ehhez a gép, ha nem, akkor mi a szûk keresztmetszet?

*utólag írtam bele

Szerkesztette: bugmenot 2007. 12. 05. 14:03 -kor

[Mono]

Friczy:

Köszönöm a válaszod, sikerült összehozni a dolgot, megy is szépen. Küldés volt eredendõen, csak a syslog-ng-t kellett még UDP hallgatózásra is rávenni.

bugmenot:
Ilyen célra - bár szerverekre én is mindenhova Debian-t teszek - jobban javaslok valami cél alkalmazást, mely természetesen legyen linux alapú. Ilyen téren csak egyet tudok ajánlani, melyet próbáltam is, nagyon bevált: Smoothwall (www.smoothwall.org)
Nem levelezik, nem Sambázik, viszont minden mást tud, alapvetõen azokat, melyeket tûzfal funkciót ellátó gépre amúgy is telepíteni szoktak (felsoroltak közül nagyon egyiket sem).

[Friczy]

Idézet: bugmenot - Dátum: 2007. dec. 5., szerda - 15:01

Kérdésem lenne: kezembe került egy egész pofás PII konfig (ASUS alaplap, rakat ISA-PCI csati, P 200 MMX proci, 64 MB RAM)
Ennyi lenne a dolga: router, Qos, proxy*,fileserver illetve ha lesz WLAN kártya, akkor AP is lenne. Késõbbiek folyamán talán SMTP szerver meg webszerver, de egyelõre ezek nem lényegesek funkciók. Linuxszal foglakoztam már desktop szinten, szerveren most kezdõdne a móka    Raknék rá valami egyszerû GUI-t (pl. Xfce), mert azért én azt jobban kezelem még. Elég erõs ehhez a gép, ha nem, akkor mi a szûk keresztmetszet?

*utólag írtam bele

Ehhez ez a gép szerintem nagyon karcsú. Egy proxy önmagában is nagyobb ramot eszik, nem elsõsorban maga miatt, hanem azért, mert egyik alapfunkciója, hogy cache-el. 64 MB RAM-ra pedig semmiképpennem tennék fel GUI-t, és az is openbox lenne )
Szóval egyenként:
qos: végül is a kernel végzi, tehát elfér.
proxy: felejtõs ennyi memóriával.
fileserver: hülyén néz ki egy ekkora gépen, de ha nincs nagy adatforgalom, akkor akár el is fér.
AP. nem hiszem, hogy nagy ügy.
smtp: belefér.
webserver: imho nem, hacsak nem tesztelésre kell.
gui: felejtsd el, megeszi a hasznos programok mellõl az erõforrást. egy ilyen gépet az ember szépen betesz a sarokba, és távolról ssh-zik rá ha valamit konfigurálni kell.

Szû keresztmetszet a RAM, illetve bonyolultabb feladatok esetén a processzor is. Diskméretet meg nem írtál, pedig egy fileserver esetén az sem lényegtelen paraméter

[Lenny]

Napokban kell majd összedobnom egy WEB servert. Természtesen Deiban lesz alatta. Magát az oldalt nem én fogom csinálni csak a vasat konfigolom alá.

A WEB szerverek az egyik leggyakrabban támadott szerverek. Milyen védelmi eszközöket ajánlotok megfelelõen bekonfigolt iptablesen felül?

Gyakorlatilag a 80-as port lesz ugye nyitva teljesen a többi szükséges (SSH, FTP) csak adott IP-rõl lehet majd elérni.

[kroozo]

Annak a kutyunek a biztonsagi frissiteseit, amit futtatni fog. A webszerverek nagy reszet a szolgaltatott tartalom hibajat kihasznalva torik meg.

[Lenny]

Idézet: kroozo - Dátum: 2007. dec. 6., csütörtök - 14:34

Annak a kutyunek a biztonsagi frissiteseit, amit futtatni fog. A webszerverek nagy reszet a szolgaltatott tartalom hibajat kihasznalva torik meg.

pl.?

Mik lehetnek azok a hibák?

[kroozo]

Ezt most ugye nem kerdezed komolyan.
ha valami kulso cucc, akkor tessek biztonsagi frissiteni, ha sajat fejlesztes, akkor meg remeld, hogy a programozo ert hozza. Esetleg guglizz egyet audit ugyben, ha nem bizol benne.

Ja igen, es tessek az egesz vackot chrootba tenni, amiben ne legyen semmi, csak ami feltetlen muszaj a mukodeshez.

[bugmenot]

Idézet: Friczy - Dátum: 2007. dec. 6., csütörtök - 12:17

Ehhez ez a gép szerintem nagyon karcsú. Egy proxy önmagában is nagyobb ramot eszik, nem elsõsorban maga miatt, hanem azért, mert egyik alapfunkciója, hogy cache-el. 64 MB RAM-ra pedig semmiképpennem tennék fel GUI-t, és az is openbox lenne )
Szóval egyenként:
qos: végül is a kernel végzi, tehát elfér.
proxy: felejtõs ennyi memóriával.
fileserver: hülyén néz ki egy ekkora gépen, de ha nincs nagy adatforgalom, akkor akár el is fér.
AP. nem hiszem, hogy nagy ügy.
smtp: belefér.
webserver: imho nem, hacsak nem tesztelésre kell.
gui: felejtsd el, megeszi a hasznos programok mellõl az erõforrást. egy ilyen gépet az ember szépen betesz a sarokba, és távolról ssh-zik rá ha valamit konfigurálni kell.

Szû keresztmetszet a RAM, illetve bonyolultabb feladatok esetén a processzor is. Diskméretet meg nem írtál, pedig egy fileserver esetén az sem lényegtelen paraméter

Köszönöm, akkor  a proxy felejtõs. Elsõdleges feladatként a QoS és a fileszerver jutott eszembe. Aztán kezdtem egyre több feladatot köré tenni.

Lemezként van egy 30 gigás vinyó, meg egy 4 gigás (erre menne a rendszer). Itt nem valami nagyon nagy feladatra gondolni,pl. ilyenre: volt egy buli, készült róla vagy 400 MB-nyi kép, videó. Ezt szétosztani nehéz feladat, mert nem mindenkinél volt pendrive,cd. Jó lett volna feltolni egy ilyen apró szerverre és akkor kényelmesen lehúzhatták volna. (Kissé csípné a szemem, ha az otthoni gépen más is "matat"). A webszerver azóta kiesett, hiszen az internet elõfizés mellé jár egy kevés tárhely, ahova megy a HTML, onnan már át tudok irányítani ide linket, ha valami nagyobb dolgot akarok megosztani.

GUI csak addig kellene, amíg bekonfigolom (nekem azért még kényelmesebb így), aztán menne parancssorról pl puttyal. 

[Friczy]

Idézet: Lenny - Dátum: 2007. dec. 6., csütörtök - 16:17

pl.?

Mik lehetnek azok a hibák?

Bérmi. Egy külön tudomány a php programokat biztonságossá tenni, ha egyáltalán lehetséges. Volt egy webserver, azt rendszeresen megtalálta valami féreg, és egybõl pakolt fel botokat a gépre Minden uptodate volt rajta, egyszerûen szarul volt megírva a program és lyukas volt. Tehát ha a webprogramozó béna, akkor nem tudsz mindent elhárítani. Amivel csökkentheted az esetleges betörés hatását:

- A webservert chrootba vagy egy virtuális gépre elhelyezni, így ha fel is törik, kisebb a kockázata annak, hogy egy másik hibát kihasználva tovább tudjanak menni.
- Az iptables szabályokat még jobban szigorítani. A legtöbb host-alapú tûzfalnál az egszerûség és könnyebb menedzselhetõség érdekében az OUTPUT policy jellemzõen ACCEPT. Nos, ezt kihasználva a webserver-feltöréseknél szokták alkalmazni azt, hogy a behatoló kód viszonylag rövid, de ráveszi a webservert arra, hogy a tényleges backdoort vagy egyebet tartalmazó programot töltse le egy távoli serverrõl, és utána indítsa el. Ezt roppant hatékonyan lehet blokkolni, ha a tûzfal nem enged kifelé kapcsolatot teremteni (kivéve néhány jól ismert gépre - pl. az update-ek letöltésére).
- Változás-detektorok telepítése (tripwire és társai), hogy észrevedd, ha valami bemászott, és letöltött nem kívánt programokat a gépre. Sajnos ennek hozadéka igencsak korlátozott, ugyanis az így a gépre jutott kódok többségét a /tmp, /var/tmp és egyéb hasonló helyekre töltik, ahol esélyed se nagyon van észrevenni, mert azon a területen állandóan változik úgyis a tartalom.

[Lenny]

Hmm.. ok.

Már csak az a kérdés, hogy egy web szervernek kb. mekkora a gépigénye. Egy kb. dinamikus oldalakat futtató szerver lesz kb. 50-60 oldallal. A napi lekérdezések egyelõre nem ismertek. Azt valahol apache log-olja? vagy lekérdezhetõ?

Lehet saccolni, hogy pl. nap 100-200 lekérdezésnél mekkora gépigény szükséges?
Proci,RAM?

[kroozo]

napi 100-200? arra egy abakusz is eleg

viccet felreteve: nehez saccolni, nagyon fugg az oldal milyensegetol, kulonos tekintettel az sql reszere, a varhato hitcount nelkul meg teljesen remenytelen barmit mondani.

persze, logol, access.logba mehetnek ilyenek, meg valami rendes statisztikazot is felrakhatsz... (pl webmin, vagy ilyesmi)

Szerkesztette: kroozo 2007. 12. 07. 11:27 -kor

[Lenny]

Idézet: kroozo - Dátum: 2007. dec. 7., péntek - 11:24

napi 100-200? arra egy abakusz is eleg

Az elsõ idõkben, aztán ez persze növekedni fog.