otthoni e-mail szerver & dinamikus IP & adatbiztonság?

Hálózatok egyéb

15-20 felhasználó kiszolgálására alkalmas email szervert szeretnék kialakítani, amely saját domain névvel rendelkezik. Webes felületen keresztül is elérhetővé szeretném tenni a levelezést.
A rendszer kialakításánál az egyik legfontosabb szempont az adatbiztonság, de egy átlagos felhsználó képes kell, hogy legyen a rendszer használatára.

Elképzelésem szerint kb. az alábbi lenne a felállás:
- Egy otthoni szerver gép dinamikus IP címről csatlakozik egy fix IP címmel rendelkező VPS-hez.
- A VPS fix IP címe lenne a domain "A" recordjának megadva.
- Az otthoni szervernek figyelnie kéne, hogy a VPS-el a kapcsolata mindig élő legyen.
- Minden érzékeny adat az otthoni szerveren lenne tárolva és nem a VPS-en

Kicsit konkrétabban: Email szerver és LAMP az otthoni szerver gépen lenne telepítve, az otthoni szerver gép pedig VPN kliensen keresztül kapcsolódik a VPN szerverhez, amely a VPS-en lenne telepítve. Így a VPS-en keresztül kapcsolódna az otthoni szerver az internethez.

Az alábbi alternatív megoldásokat mérlegeltem még:
- Otthoni szerverhez fix IP vásárlása az internet szolgáltatótól (elvetve, mert drágább, mint egy VPS és talán kevésbé biztonságos is)
- VPS-re telepíteni mindent és teljes hdd encryption alkalmazása (elvetve, mert kevésbé biztonságos)
- egy szerver hosztingnál elhelyezni az otthoni szerver gépet + teljes hdd encryption (elvetve, mert több munkát igényel és nem biztonságosabb, mint VPS)

Megítélésem szerint a szerver fizikai védhetősége nagyobb biztonságot ad, mint egy fizikailag nem védhető szerver esetén a teljes hdd encryption (fizikai védhetőség = szerver tulajdonosán kívül senkinek nincsen fizikai hozzáférése a szerverhez)

Az általam felvázolt megoldásnak egyetlen hátránya, amelyet látok a némileg alacsonyabb rendelkezésreállás az alternatívákhoz képest, de ez nem jelent problémát, annak a 15-20 felhasználónak, aki hozzáférést kapna a szerverhez.
(Otthoni szerver sávszélessége bőven elegendő)

Mit gondoltok?
Tudnátok ennél jobb megoldást javasolni?

( stra | 2013. 10. 29., k – 01:53 )

"A VPS fix IP címe lenne a domain MX recordjának megadva"
Az MX rekord nem IP-re mutat. Ha csak ezért szeretnél VPS-t, akkor miért nem DDNS által biztosított nevet használsz?

"Otthoni szerverhez fix IP vásárlása az internet szolgáltatótól (elvetve, mert drágább, mint egy VPS)"
Szinte biztos, hogy nem drágább, mint az "egy szerver hosztingnál elhelyezni az otthoni szerver gépet + teljes hdd encryption" változat, amelyet nem az ár, hanem a fizikai védelem okán vetettél el.

Ilyen alacsony postafiókszámnál és websitemennyiségnél egy változatot kihagytál: körülnézni, és szolgáltatásként megvenni. Valószínűleg jobban megérné, mint egy VPS díja, plusz az otthon üzemelő gép áramdíja (plusz a géppel kapcsolatos költségek). És nem csak anyagiakban, hanem egyéb paraméterekben is, mint például sávszélesség, vagy az általad nem túl fontos tényezőként megjelölt rendelkezésreállás.

Az MX rekord nem IP-re mutat. Ha csak ezért szeretnél VPS-t, akkor miért nem DDNS által biztosított nevet használsz?

Ha csak DDNS által biztosított nevet használnék, akkor összes kimenő levél spam mappában landolna a legtőbb e-mail szolgáltatónál, mert dinamikus IP tartományból küldeném, továbbá IP váltások problémaforrást jelentenének.
Bocs, nem "MX", hanem "A" recordnak lenne a VPS IP-je beállítva "MX" recordnak meg a saját domain név lenne megadva. Továbbá a domain név már adott, amelyhez a leírt szolgáltatást kötni szertném.

Szinte biztos, hogy nem drágább, mint az "egy szerver hosztingnál elhelyezni az otthoni szerver gépet + teljes hdd encryption"
Dedicated szerver hoszting valóban nem lenne drágább, mint az otthoni szolgáltatómtól vásárolt fix IP cím. De az otthoni fix IP cím viszont drágább, mint egy VPS. Egy dedicated szerverrel több karbantartási munkám lenne, mint az általam felvázolt megoldással (otthoni szerver + VPS). Ráadásul megítélésem szerint egy dedicated szerver kevésbé biztonságos, mint egy otthoni fizikailag is védett.

Ilyen alacsony postafiókszámnál és websitemennyiségnél egy változatot kihagytál: körülnézni, és szolgáltatásként megvenni
Pontosan az adatok nagyobb biztonsága miatt szertném az adatokat fizikailag is védhető szerveren tárolni (otthon). Így ez a változat szóba sem jön. Az ilyen szolgáltatásoknál szerintem még egy VPS is biztonságosabb.

És nem csak anyagiakban, hanem egyéb paraméterekben is, mint például sávszélesség

Otthoni szerver sávszélessége bőségesen elegendő, így ezzel nincsen gond. Az ár pedig másodlagos szempont a biztonsághoz képest.

láttál Te már korszerű szervertermet?

Igen láttam! De ha az otthoni sávszélességem bőségesen elegendő a szervernek és az otthoni szerver fizikai védelmét meg tudom oldani, akkor miért tegyem lehetővé a szerver fizikai elérését mások számára?
Vedd figyelembe, hogy a szerverhez csak 15-20 felhasználónak lenne hozzáférése és a szerveren tárolt adatok biztonsága lenne az elsődleges szempont.
Tudom a korszerű szervertermekben minden be van kamerázva, 0-24 órában örzik és bla-bla-bla, de saját magad nem védheted meg ott fizikailag a szerveredet, hanem valakinek a szolgáltatásában kell bíznod, ami egy felesleges rizikófaktor.

Sok hosting szolgáltató termét fegyveres őrrel, kamerával, komoly beléptető rendszerrel védik. Van ahol a fegyveres őr géppisztolyt tart a kezében és konkrétan katona.

Igen ez valóban így van, de ettől még egy másik félben és az általa nyújtott szolgáltatásban kell bíznod, amely felett nem rendelkezel kontrollal (kivéve ha nem a tied a szerverhoszting cég).
Akár minden szerver mellett is állhatna egy géppisztolyos katona az sem változtatna ezen a tényen.

[OFF]
Ahha, szóval durvábban véded a házadat/lakásodat, mint egy géppisztolyos katona!? Oké... Az a 10-20 user véletlen nem Obama, Merkel, Putyin.... :)
Nem akarom szétoffolni a témát, szóval tisztázzuk: kérdésed komoly, vagy csak flame?

Ha a szerver tulajdonosán kívűl másnak is fizikai hozzáférése van egy szerverhez, akkor az egy elméleti rizikófaktort jelent.
Az esetek többségében (pl egy tipikus webszerver esetén...) ez nem kerülhető el, de az általam felvázolt esetben (15-20 felhasználós mail szerver) igen.
Ha ezt nem tudod elfogadni, megérteni nincs gond, de ezért tényleg nincs értelme szétoffolni a topicot, főleg ha érdemben nem is szólsz hozzá.
[ON]

[OFF]

_Ha_ van, akkor esetleg. De ha van is, akkor lehet hogy olcsóbb eladni és mégis bérelni, pláne ha szükség van az emelt szintű biztonságra és ahhoz meg száz kilométereket kell utazni.

A szerver hoszting szolgáltatónál elhelyezett (akár bérelt) szerver szerintem semmiben nem jelent nagyobb biztonságot, mintha csak simán VPS-t használ valaki. Ha egy szerverhez a tulajdonoson kívűl fizikailag hozzáfér más is (akár a nagyon megbízhatő szerverhoszting cég alkalmazottjairól legyen is szó), akkor teljesen mindegy, hogy saját szerverről, bérelt szerverről, vagy VPS-ről van szó.
Fizikai hozzáférhetőség mindenképp elméleti rizikófaktort jelent.

Példaként alább valaki már felvetette, hogy ha törvényes úton érkező (lényegtelen hogy jogos vagy jogtalan) megkeresést kap a hosting cég a szerver kiszolgáltatására, akkor úgy is megteszi és tulajdonos semmit sem tehet ellene.
[ON]

[OFF]
Akkor kérj rá PCI minősítést és megtudod, hogy egy ilyennel rendelkező tényleg biztonságos hely körülményeinek, meglévő és kialakított adottságainak még az egy ezrelékét sem éred el.

Miért olyan nehéz azt az érvet elfogadni, hogy ha a szerver tulajdonosán kívűl másnak is fizikai hozzáférése van egy szerverhez, akkor az egy elméleti rizikófaktort jelent?
Vannak olyan esetek, amikor ez nem kerülhető el, de az általam felvázolt esetben (15-20 felhasználós mail és web szerver) igen.
[ON]

"Miért olyan nehéz azt az érvet elfogadni, hogy ha a szerver tulajdonosán kívűl másnak is fizikai hozzáférése van egy szerverhez, akkor az egy elméleti rizikófaktort jelent?"

Ezt senki se vitatta. Viszont te nem is ezt állítod, hanem azt, hogy otthon biztonságosabban tudod elhelyezni a gépet mintha hostingban lenne. Ez kb. egyenértékű azzal, hogy otthon biztonságosabban tudod a pénzedet tárolni mint a bankban. Ami amúgy, mondjuk kétszáz forintig, igaz is lehet, bebetonozod az alapba, és senki nem veszi majd a fáradtságot hogy kivésse. De ha mondjuk milliószor nagyobb összegről lenne szó, még én se lennék rest légkalapácsot ragadni.

[OFF]
"Miért olyan nehéz azt az érvet elfogadni, hogy ha a szerver tulajdonosán kívűl másnak is fizikai hozzáférése van egy szerverhez, akkor az egy elméleti rizikófaktort jelent?"

Ezt senki se vitatta. Viszont te nem is ezt állítod, hanem azt, hogy otthon biztonságosabban tudod elhelyezni a gépet mintha hostingban lenne.

Szerintem ez meddő vita, mert nem ugyanazt értjük biztonság alatt.
Maradjunk abban, hogy otthon szertném elhelyezni a szervert (legalábbis azt a részét amely érzékeny adatokat tárol), mert így nyugodtabban alszok éjszakánként és ennyi.
[ON]

"összes kimenő levél spam mappában landolna a legtőbb e-mail szolgáltatónál, mert dinamikus IP tartományból küldeném"
Ilyen kisszámú mailcímnél használhatod az ISP mailszerverét smarthostként.

"továbbá IP váltások problémaforrást jelentenének."
Ezt nem érzem jelentős problémának, nem véletlen dolgoznak a DDNS szolgáltatók rendkívül alacsony TTL-lel. Ehhez képest az IP változása sem lehet túl gyakori, maximum napi egy, és a postafiókszámból következően a bejövő mailforgalom sem lehet olyan jelentős, hogy az éppen az IP váltás utáni egy percben érkezni próbáló levél ne várhatna a következő queuefeldolgozásig.

"egy dedicated szerver kevésbé biztonságos, mint egy otthoni fizikailag is védett."
"az adatok nagyobb biztonsága miatt szertném az adatokat fizikailag is védhető szerveren tárolni"
"Az ár pedig másodlagos szempont a biztonsághoz képest."
Akkor határozzuk meg, mit értesz biztonság alatt, és az mihez kell. A mailforgalom szinte teljesen kiesik, mivel az SMTP alapvetően cleartext protokoll, és a mailek jelentős része titkosítás nélkül fog utazni. A sima HTTP-nél szintén ez a helyzet.

Ilyen kisszámú mailcímnél használhatod az ISP mailszerverét smarthostként.

Úgy tudom, hogy az internet szolgáltatóknak archiválniuk és elég hosszú ideig meg kell őrizniük az SMTP szerverükön keresztül menő adatokat. Így ez a lehetőség nem tűnik túl jó ötletnek.

Ezt nem érzem jelentős problémának, nem véletlen dolgoznak a DDNS szolgáltatók rendkívül alacsony TTL-lel.
Rendben akkor DDNS-t nem zárom ki. Viszont SMTP szerver IP-je nem lehetne az otthoni szerver IP-je, mert SPAM-nak tartanák más szolgáltatók a dinamikus IP tartományból érkező leveleket. Így DDNS önmagában nem jelentene megoldást.

Akkor határozzuk meg, mit értesz biztonság alatt, és az mihez kell. A mailforgalom szinte teljesen kiesik, mivel az SMTP alapvetően cleartext protokoll, és a mailek jelentős része titkosítás nélkül fog utazni. A sima HTTP-nél szintén ez a helyzet.

Biztonság alatt azt értem, hogy a lehető legnehezebb legyen illetékteleneknek a szerveren tárolt adatokhoz hozzáférnie kb.:
- Külső szolgáltatóknál ne legyenek adatok tárolva. - Fizikailag ne férhessenek illetéktelenek az adatokat tároló szerverhez
- MITM támadás lehetőségeit amennyire csak lehetséges minimalizáljam.

A rendszer kialakításához akár szakember segítségét is szívesen igénybe venném, de egy olyan megoldást szeretnék, amelynek az önálló fenntartására képes vagyok egyedül is.

Jelenlegi tudásom alapján az alábbi egymásra épülő biztonsági rétegekre gondoltam:
SSL titkosítás -> esetleg valami egyéb titkosítási réteg SSL MITM támadások ellen -> email OpenPGP titkosítása -> Otthoni szerver hdd titkosítása.

"az internet szolgáltatóknak archiválniuk és elég hosszú ideig meg kell őrizniük az SMTP szerverükön keresztül menő adatokat."
Javaslom, ennek a félinformációnak azért olvass utána. A logok és az adatok nem azonosak. A logokat természetesen igen. Az adatokat természetesen nem. Pontos jogszabályhelyet lehet hogy a többiek tudnak mondani.

"Viszont SMTP szerver IP-je nem lehetne az otthoni szerver IP-je, mert SPAM-nak tartanák más szolgáltatók a dinamikus IP tartományból érkező leveleket."
Akkor ismételten: a szervered küldhet az ISP szerverén mint smarthoston keresztül, azaz a más szerverrel kliensként SMTP kapcsolatba a te szervered nem kerülne.

"Külső szolgáltatóknál ne legyenek adatok tárolva."
Az SMTP mint protokoll márpedig ilyen. Aladár felad egy levelet a szolgáltatója szerverén, és az addig ott marad, amíg a te szerveredre el nem tud jutni (és ott kézbesítődik Béla postfiókjába). És a te szerveredről kimenő leveleknél ugyanez pepitában, lásd továbbá mail relay, MX rekordok.

"Fizikailag ne férhessenek illetéktelenek az adatokat tároló szerverhez"
Ahogy rámutattak már, nagyon valószínű, hogy egy hosting szerverterembe illetéktelen módon bejutni lényegesen nehezebb, mint a te lakásodba, hacsak a lakásod ajtaja előtt nincs 24 órás biztonsági személyzet, beléptetőkapu, fémkereső stb.

"MITM támadás lehetőségeit amennyire csak lehetséges minimalizáljam."
Konkrét kérdés: ha a te otthoni szervered az SMTP szerver, milyen okok miatt lesz kisebb a szervered ellen irányuló MITM lehetősége és esélye például az internetszolgáltatód SMTP szervere ellen irányulóénál? De ugyanezt a kérdést feltehetjük a kívánt POP3(S), IMAP(S), SMTPS, HTTP(S) protokollok esetében is. Mitől tartod az otthoni szervert ilyen szempontból biztonságosabbnak egy szolgáltatóénál?

"az internet szolgáltatóknak archiválniuk és elég hosszú ideig meg kell őrizniük az SMTP szerverükön keresztül menő adatokat."
Javaslom, ennek a félinformációnak azért olvass utána. A logok és az adatok nem azonosak. A logokat természetesen igen. Az adatokat természetesen nem. Pontos jogszabályhelyet lehet hogy a többiek tudnak mondani.

Már az sem szimpatikus, ha a szolgáltató a levelezésemmel kapcsolatban logokat őriz. Ha SMTP szerverüket használom elméletileg lehetősége megvan rá, hogy adatokat is tároljon. Miért adjak rá lehetőséget neki, ha saját SMTP szerveremet is használhatom?

Akkor ismételten: a szervered küldhet az ISP szerverén mint smarthoston keresztül
Kifejtettem, hogy ezt miért nem tartom jó megoldásnak.

"Külső szolgáltatóknál ne legyenek adatok tárolva."
Az SMTP mint protokoll márpedig ilyen.
Tisztában vagyok vele, hogy az SMTP protokoll egyáltalán nem biztonságos és természetesen más szolgáltatók mail szerverei irányába zajló adatforgalom nem a saját szerveren tárolódik. De legalább a saját felhasználók közötti levelezést a saját szerveren tudnám tárolni és ez sokat jelentene a biztonság szempontjából, mert a szerver felhasználóinak email levelezése nagyrészt egymás közötti lenne.

Ahogy rámutattak már, nagyon valószínű, hogy egy hosting szerverterembe illetéktelen módon bejutni lényegesen nehezebb, mint a te lakásodba, hacsak a lakásod ajtaja előtt nincs 24 órás biztonsági személyzet, beléptetőkapu, fémkereső stb.
Ez meddő vita, lehet ahol te laksz ott ez igaz, ahol én el tudom helyezni az otthoni szerveremet ott ez nem így van. Esetemben kényelmesebb és ugyanolyan biztonságos otthon elhelyezni a szervert, mint bármelyik szerver hosztingnál.

Konkrét kérdés: ha a te otthoni szervered az SMTP szerver, milyen okok miatt lesz kisebb a szervered ellen irányuló MITM lehetősége és esélye például az internetszolgáltatód SMTP szervere ellen irányulóénál? De ugyanezt a kérdést feltehetjük a kívánt POP3(S), IMAP(S), SMTPS, HTTP(S) protokollok esetében is. Mitől tartod az otthoni szervert ilyen szempontból biztonságosabbnak egy szolgáltatóénál?

-Több biztonsági réteget tudok használni: pl. SSL-t sem engedi szolgáltató smtp-je, illetve esetleg SSL alá még egy nem konvencionális biztonsági réteget is betehetek.
-saját felhasználók egymással folytatott levelezése (ami az e-mail forgalom jelentős részét tenné ki) nagyobb biztonságban van saját SMTP szerver használatával, mert az adatok végig a szerveren maradnak
-Ha az adatok és az azokat szolgáltató szerver programok saját fizikailag védett szerveren vannak és az adatok titkosított protokolokba csomagolva közlekednek az interneten, akkor a MITM támadás nehezebb, mintha valaki akár szerver oldalon is beavatkozhatna (pl.: szolgáltató SMTP szerverén keresztül, vagy bármilyen más szerverprogramon keresztül, vagy akár a szerveren futó operációs rendszer szintjén).

"Mert - gondolom - küldeni is szeretne, és azt dinamikus címről nem szerencsés."
Gyakorlatilag mindegyik ISP üzemeltet az ügyfelei számára SMTP szervert, amelyet igénybe vehetne, ezt írtam is már néhányszor. Csak 20 mailcímről (postafiókról) van szó, ha nem spammelni akarnak, a szolgáltató nem fog szólni ilyen kis levélmennyiségért. És mivel a szolgáltató SMTP szervere már (akár autentikáltan) átvette a kérdező szerverétől, nem lesz probléma.

"A legtöbb szolgáltató csak 25-ös porton ad smarthostot, amin nem feltétlenül van TLS."
De a címzett szerverén sem feltétlen van SSL/TLS. De ha Aladár postafiókjának szolgáltatójánál van is, Béláénál nem lesz. Ergo az SMTP-t nem tekintheted végtől végig (a feladótól a címzettig) biztonságos csatornának, akár van az első szakaszon titkosítás, akár nincs. Ezt a problémát a saját szerver sem oldja meg, hiszen ettől még Béla postafiókjának szolgáltatója ugyanúgy nem lesz képes SSL/TLS-en fogadni a levelet.

"Azon kívül nem feltétlenül bíznám a szolgáltatókra a leveleim kézbesítését, elég a túloldal baromságaival harcolni..."
Ezzel nincs semmi baj, csak arra próbálok rávilágítani a kérdező érveivel szemben, hogy a saját szerver üzemeltetésének oka lehet bármi (objektív vagy szubjektív dolog), de általános levelezésnél SMTP esetében garantált biztonságról, garantált titkosított átvitelről nem lehet beszélni akkor sem, ha saját szervert üzemeltet a küldési lánc elején.

De a címzett szerverén sem feltétlen van SSL/TLS.
A szerver felhasználóinak a levelezése nagyrészt (kb 80%-ban) egymás közötti zajlana, így ez SSL/TLS 80%-ban garantáltan biztosított. Továbbá, ha a címzett email szerverén nincsen SSL/TLS, akkor egy ilyen címzettel szinte biztos, hogy nem akarnak a felhasználóim bizalmas levelezést folytatni.

de általános levelezésnél SMTP esetében garantált biztonságról, garantált titkosított átvitelről nem lehet beszélni akkor sem, ha saját szervert üzemeltet a küldési lánc elején.
ld. előbbi válaszomat.

"Továbbá, ha a címzett email szerverén nincsen SSL/TLS, akkor egy ilyen címzettel szinte biztos, hogy nem akarnak a felhasználóim bizalmas levelezést folytatni."
Életszerű, hogy a felhasználóid megnézik a tervezett címzettek domainjeinek az MX és A rekordjait, rátelnetelnek ezekre a szerverekre, ellenőrzik a célszerverek titkosítási képességeit, majd ha ezen a rostán átment a címzett, elindítják kedvenc levelezőprogramjukat, és immár bizalommal telve megírják a levelüket? Persze lehet így is levelezni. Csak kérdés, hogy a válaszlevél milyen úton fog érkezni.

Életszerű, hogy a felhasználóid megnézik a tervezett címzettek domainjeinek az MX és A rekordjait, rátelnetelnek ezekre a szerverekre, ellenőrzik a célszerverek titkosítási képességeit, majd ha ezen a rostán átment a címzett, elindítják kedvenc levelezőprogramjukat, és immár bizalommal telve megírják a levelüket? Persze lehet így is levelezni. Csak kérdés, hogy a válaszlevél milyen úton fog érkezni.

A felhasználóim bizalmas emailezést szinte csak egymással kívánnak folytatni.
Külső cimzettekkel csak ritkán kívánnak bizalmas levelezést folytatni. Ha külső címzettel kívánnak bizalmas levelezést folytatni, akkor valóban nem ellenőrzik a célszerverek titkosítási képességeit, merte amúgy is OpenPGP-t fognak használni a leveleik titkosításához.

Saját szervereid között saját SSL-t használnál nem? Nem értem, hogy jön ide a cikk?
Amúgy meg használj rendes ssl certeket (openvpn alatt is), és nem lesz bajod.
#define rendes "nem önaláírt"

A cikk csak arra hívja fel a figyelmet, hogy SSL MITM támadás egy létező dolog sőt...
Nem tiszta, hogy te hogyan képzeled el a rendszert.
Te mit telepítenél a VPS szerverre és mit az otthoni szerverre?
A topicindító hozzászólásomban felvázoltam hogyan én hogyan gondoltam: otthoni szerveremen VPN kliens lenne telepítve, amely a VPS-en telepített OpenVPN szerverhez kapcsolódna és minden az otthoni szerveren lenne telepítve.

A szervereid IP alapon közvetlenül beszélgetnek. Ahhoz, hogy valaki beékelődjön, a szolgáltatóid routereit kéne meghackelni, illetve bejutniuk valamelyik gépedre. VPN esetén ezt ugyanúgy meg lehet tenni. Innentől édesmindegy, hogy SSL kapcsolatod van, vagy VPN.
Ez a cikk max. arra hívhatja fel a figyelmed, hogy egy általad használt SSL védett oldal (pl. website) evvel a módszerrel eltéríthető (akár dns eltérítéssel is), így célszerű a certificate-eket megnézni (pl. webbank esetén).
--
PtY - www.onlinedemo.hu

A szervereid IP alapon közvetlenül beszélgetnek. Ahhoz, hogy valaki beékelődjön, a szolgáltatóid routereit kéne meghackelni, illetve bejutniuk valamelyik gépedre. VPN esetén ezt ugyanúgy meg lehet tenni. Innentől édesmindegy, hogy SSL kapcsolatod van, vagy VPN.

Azt feltételezem, hogy VPN kapcsolat esetén azért ez nehezebb lenne, mint SSL esetén.

Sok dolgot feltételez az ember, amiről aztán később kiderül, hogy nem úgy van. :)

Akkor jól értem, hogy tulajdonképpen azt állítod, hogy, hogy az otthoni szerver és VPS közötti VPN kapcsolat (úgy hogy MTA csak otthoni szerveren van telepítva) nem biztonságosabb annál, mintha a VPS-re is telepítek MTA-t és SSL-en keresztül tartja a otthoni szerver MTA-ja a kapcsolatot a VPS MTA-javal?

Pontosan. Mindkét esetben csak a két gép között áramló adatok lehallgatását tudod kivédeni.
Ha valamelyik gépedre bejutnak, ugyanúgy hozzáférhetnek bármihez.
Ezért pl. erősen ajánlott megválogatni, hogy milyen weblapokat teszel elérhetővé a szervereden, amikben esetleg van egy sechole.

Sőt, tételezzük fel, hogy a két géped között VPN van, és - mivel biztonságosnak hiszed - ssh szinten össze vannak kulcsozva. A VPS-en van egy website-od, aminek az egyik szövegmezője hibás adat esetén visszaírja a változóba a bevitt adatot, és nem escape-el. Evvel megmérgezhető az oldal, és beszúrhat a támadó egy perl/php/whatever kódot, amivel kaput nyit kifelé, és azon keresztül bejut a VPS-re. Az összekulcsozás és VPN miatt egyből bejuthat az otthoni gépedre is.

Azonban, ha nincs VPN-ed, és így a két gép nincs egyetlen alhálózaton, akkor természetszerű, hogy nem fog átjutni az egyik gépről a másikra a behatoló - legalábbis sokkal nehezebben.

Ha a VPN mellett is döntesz a végén, nagyon ajánlott a vpn kliens felé és felől is korlátozni a forgalmat tűzfal szinten, és nem összekulcsozni őket. Elsődlegesen a VPS-edet fogják támadni a fix ip, a nagyobb sávszélesség és kisebb válaszidők miatt, de az otthoni gépedre is nagyon ügyelned kell. ssh-t pl. minden szinten tilts, egy sudoer user legyen, aki ssh-zhat, és ő is csak kulccsal, a kulcsban passphrase-zel, rootnak alapból tiltva legyen minden.

Tapasztalatból tudom, hogy nem az a kérdés, hogy bejutnak-e a szerveredre, hanem az, hogy mikor, és hogyan - ez utóbbi kettőre tudsz hatással lenni. Azt ugyanis nem tudod megakadályozni - akár milyen ügyes is vagy -, hogy pl. egy célzott DDoS esetén az egyik szolgáltatásod valami sérülékenység miatt nem úgy áll fejre, hogy szétteszi a lábát, és magába enged mindenkit. :)
Ezért (is) nagyon ajánlott, hogy amelyik szolgáltatásod kommunikál kifelé, ne áruljon el magáról olyanokat, hogy milyen az OS, milyen a szolgáltatás gyártója, verziója, az esetleges backend verziója, stb.

A legtöbb hibát az apache-csal követik el. Most találtam, nagyszerű példa a kiváló beállításra - ennél a csókánál nem hostoltatnék weboldalt, az sicher:

$ telnet www.cw.hu 80
Trying 195.56.44.194...
Connected to web.tarnay.hu.
Escape character is '^]'.
GET / HTTP/1.0

HTTP/1.1 200 OK
Date: Wed, 30 Oct 2013 10:16:44 GMT
Server: Apache/1.3.27 (Unix) (Red-Hat/Linux) PHP/3.0.18 mod_perl/1.23
Last-Modified: Fri, 04 Apr 2003 18:43:55 GMT
ETag: "1f5c3-1-3e8dd26b"
Accept-Ranges: bytes
Content-Length: 1
Connection: close
Content-Type: text/html

Persze lehet, hogy ez csak honeypot, és akkor a zember király csávó, de erre max. 1% az esély.

(pár hete még a HUP-on is megvolt ez a probléma)
--
PtY - www.onlinedemo.hu

Pontosan. Mindkét esetben csak a két gép között áramló adatok lehallgatását tudod kivédeni.
Ha valamelyik gépedre bejutnak, ugyanúgy hozzáférhetnek bármihez.
Ezért pl. erősen ajánlott megválogatni, hogy milyen weblapokat teszel elérhetővé a szervereden, amikben esetleg van egy sechole.

Persze ez világos.
Amúgy weben csak a levelek eléréséhez szeretnék egy felületet biztosítani és másra nem is használnám a webszervert.

Azonban, ha nincs VPN-ed, és így a két gép nincs egyetlen alhálózaton, akkor természetszerű, hogy nem fog átjutni az egyik gépről a másikra a behatoló - legalábbis sokkal nehezebben.

Igen ez logikusnak tűnik.

"Amúgy weben csak a levelek eléréséhez szeretnék egy felületet biztosítani és másra nem is használnám a webszervert."
Azaz használod a webszervert, minden biztonsági beállítási kockázataival, és a webmail app. biztonsági réseivel együtt.
És jó, ha tudod, hogy ha van egy sérülékenység a rendszer vagy az app felületén, akkor édesmindegy, hogy használsz-e SSL-t vagy VPN-t, ugyanis a támadó nem az adatforgalombe ékelődik be, hanem a szolgáltatás használatán keresztül jut be.
Úgy gondolom, nem célod az, hogy az adott webfelületet csak bizonyos IP címekről teszed elérhetővé - bár ez esetben megoldható lenne, hogy a kliensek csak VPN-en érjék el a HTTP(S) felületet, de ez újabb kockázatokat rejt magában (amellett, hogy kényelmetlenné válik a használat a mezei usereknek), ugyanis a kliens gép fölött nincs hatásköröd, és ha az épp valami botnet féreggel/backdoor wormmal/spambottal fertőzött, akkor az első vpn kapcsolódás után azt beemeled a védett hálózatodba.
Egyet sose felejts el: tökéletes védelem nincs, arra csak max. törekedni lehet, és rendszeresen ellenőrizni kell a logokat, beállításokat, update-eket, forgalmi elemzéseket. Szóval folyamatos munka van vele, amit nem szabad hanyagolni.
--
PtY - www.onlinedemo.hu

( Luther | 2013. 10. 29., k – 04:46 )

Nem feltétlenül szükséges fix ip: http://www.changeip.com/
Nekem náluk van több privát (otthoni, hobbi) domain nevem is, dinamikus ip-vel és nem tapasztaltam semmi hátrányt.
Amikor változik a külső ip, pár percen belül frissít...

--------------
„If there were no hell, we would be like the animals. No hell, no dignity.”

Ha van VPS-e, akkor felpattint rá egy bindet, és nsupdate-tel matatgatja rajta a zónát és öröm

Ezzel a megoldással ugyanaz a gond, mint, amit fentebb már a DDNS szolgáltatásokkal kapcsolatban leírtam: az otthoni szerver IP-je miatt SPAM-nak tartanák más email szolgáltatók a szerverről érkező leveleket.

Ha már van neki akkor igen, de ha nincs akkor szerintem felesleges költség.

Ahogy írtam VPS fenntartásának ára még mindig olcsóbb és biztonságosabb alterantívának tűnik, mint otthoni szolgáltatómtől fix IP címet vásárolni.

pl mert:

- a VPS szerver backup mail szerverként is használható lenne, ha otthoni szerver nem elérhető
- az otthoni szerver valós IP címe rejtett maradna
- tetszőleges IP tartományban bérelek VPS-t
- VPS esetleg egyéb célokra is használható

Mennyi most az IP, 1500Ft/hó!? SZVSZ, na azért aztán igazán nagy teljesítményű és veri szexuriti & stabiliti lesz az a VPS...

FIX IP többszöröse annak amit írtál.
FIX IP áráért bármelyik tetszőleges szolgáltatótól veszek minimum 1GB rammal 2TB adatforgalommal egy VPS-t, ami bőven elég ahhoz amire használnám.
De mint írtam az ár másodlagos szempont a biztonsághoz képest.
Így ha VPS drágább lenne (de nem az!), mint a szolgáltatótól vásárolt fix IP, akkor is lehet inkább VPS-t választanám a fentebb felsorolt előnyei miatt.


Milyen szolgáltatónál vagy te? A fix IP nem olyan drága.

Azt szeretném tudni melyik megoldás a legbiztonságosabb:
- Fix IP és csak otthoni szerver használata
- VPS+otthoni szerver kombináció
- csak VPS

Azt a megoldást szeretném választani, ami a legbiztonságosabb, az ár csak sokadlagos szempont a döntésben. Ha a drágább megoldás a biztonságosabb akkor is azt választanám.

Kockázat mindig van, és a nagysága nem a kombinációk valamelyikétől függ, hanem a megvalósítás mikéntjétől, a beállítások lehető legbiztonságosabb módjától, az alkalmazott komponensek kombinációjától, és a szakszerű és biztonságos üzemeltetéstől.
És itt a hangsúly majdnem hogy zöme a legutolsó összetevőn van.
Egy bármilyen rendszer biztonsága jórészt azon múlik, aki csinálja és üzemelteti. Vannak best-pactice megoldások, de mit sem érnek szakértelem és felelősségtudat nélkül.

Válaszolnék Neked szívesen konkrétabban is, azonban állíts fel egy rangsort arról, mik azok a kockázatok, amelyektől meg akarod óvni a rendszered - igen, prioritás szerint érdekel a lista: a fontosabb legyen elöl.
--
PtY - www.onlinedemo.hu

Válaszolnék Neked szívesen konkrétabban is, azonban állíts fel egy rangsort arról, mik azok a kockázatok, amelyektől meg akarod óvni a rendszered - igen, prioritás szerint érdekel a lista: a fontosabb legyen elöl.

- Biztonsági rés kihasználásával fér hozzá valaki az adatokhoz
- Szerver szolgáltató közreműködésével fér hozzá valaki az adatokhoz
- Internet szolgáltató közreműködésével fér hozzá valaki az adatokhoz
- Szolgáltatást egy rosszindulatú támadó elérhetetlenné teszi (pl. ddos támadással)

"- Biztonsági rés kihasználásával fér hozzá valaki az adatokhoz"
Biztonsági rés lehet az alkalmazásban - ez ellen védekezni nem tudsz, csak úgy, hogy minél hamarabb frissítesz, amikor jön ki biztonsági javítás.
Biztonsági rés lehet az Általad elvégzett beállításokban.

A legfontosabb feltétel csak Rajtad múlik.

"- Szerver szolgáltató közreműködésével fér hozzá valaki az adatokhoz"
Ez ellen nem tudsz védekezni. Ha pl. a szolgáltatóhoz törnek be, az ellen sem tudsz. Ha fizikai géped van, és nem VPS, akkor biztosabb a dolog, de a gépet akkor is a hóna alá kaphatja bárki - ez ellen sem tudsz védekezni. Csak megnehezíteni tudod a dolgát a tolvajnak: titkosított fájlrendszerrel.

"- Internet szolgáltató közreműködésével fér hozzá valaki az adatokhoz"
Lásd az előző pontot...

"- Szolgáltatást egy rosszindulatú támadó elérhetetlenné teszi (pl. ddos támadással)"
Lásd a legelső pontot. Emellett megjegyzendő, hogy flood ellen nem tudsz védekezni, mert ha akarják, túlterhelik a géped, függetlenül attól, hogy mi fut rajta - ha egy port sincs nyitva, akkor nem, de akkor a gépedet nem is használod Te sem semmire.

Ezek alapján megint csak azt kell mondja, nem a módszer, hanem a hozzáértő kéz számít jobban.

Nyilvánvaló hülyeséget nem kell csinálni - azaz a két gép között (ha két gép van), titkosítva menjenek az adatok - VPN vagy SSL: mindegy. És az SSH kapcsolatot az ésszerűség határán belül a lehető legszigorúbbra kell állítani.

A második pont kivédhető, ha csak otthon van szervered.

A harmadik csak úgy, ha nincs interneted. Ugyanis a végleges kimenő és elsődleges bejövő emailek mindenképpen plaintextben mennek MTA-MTA között, így ha a szolgáltató segítségével/feltörésével lehallgatják a forgalmadat, akkor az aktuális forgalom meglesz nekik.
A túloldal lehallgatására meg nincs ráhatásod.
--
PtY - www.onlinedemo.hu

Nem feltétlenül szükséges fix ip: http://www.changeip.com/
Nekem náluk van több privát (otthoni, hobbi) domain nevem is, dinamikus ip-vel és nem tapasztaltam semmi hátrányt.

Köszönöm a javaslatot, de mint ahogy fentebb már írtam egy DDNS szolgáltaás önmagában nem jelentene megoldást, mert az SMTP szerver dinamikus IP tartományból kapna mindig címet és így blokkolná, vagy SPAM-nak ítélné a legtöbb email szolgáltató a szerverről érkező leveleket.

Igaz, de mégse :)
Az MX recordnak nem feltétlenül kell a te domainedre mutatnia, managelheti azt más is, például a zohomail...
A te home szervered pedig annak használhatja az smtp accountját.
Kérdés viszont, hogy ebben az esetben szükséges-e egyáltalán szervert felállítanod...

--------------
„If there were no hell, we would be like the animals. No hell, no dignity.”

Én egy nagyon fapados megoldást használok, de ugye ez csak home cucc: 


#!/bin/sh
while [ 1 ];
do
previpf=/home/pcstr/previp
ip=`wget -q checkip.dyndns.org -O - | grep -o "[0-9|.]*"`;
previp=`cat $previpf`
if [ $ip != $previp ];
then
lynx -dump -accept_all_cookies "https://www.changeip.com/update.asp?u=felhasznalonevem&p=jelszavam&cmd=update&set=1&offline=0"
echo $ip > $previpf
fi
sleep 30;
done

Értelemszerűen berakható a script cron-ba is, percenként ütemezve és akkor nem kell a végtelenített ciklus...

--------------
„If there were no hell, we would be like the animals. No hell, no dignity.”

Ha saját vps-e van, akkor megmondja az ip-t saját magának ;)
VPS oldalon http://<vps_ip>/ip/index.php:
<?php
echo $_SERVER['REMOTE_ADDR'];
?>

That's it. Nem kell még egy hibalehetőséget bevonni (pl. ha épp nem elérhető a checkip, vagy dns probléma van. És nem kell grepelgetni orrba-szájba, meg újraírni a scriptet, ha a szolgáltató valamit változtat az oldalon, amitől a script mondjuk fals értéket kezd visszaadni.
--
PtY - www.onlinedemo.hu

BTW.
Ha pl. az internetre nem a router kapcsolódik, hanem egy linux, így az ip kiolvasható az if-ből - van arra valami trigger, ha pl. dhcp renew, vagy pppoe újratárcsázás hatására megváltozik az ip, akkor az meghívódik?
Olyan megoldás kéne, ami minden verzióban működik, azaz tök mindegy, hogy az ip honnan jön: egy tetszőleges if ip-je megváltozik (ethX, pppX, tapX, tunX, whateverX) - tehát egy teljesen if specifikáció független megoldás kellene...
--
PtY - www.onlinedemo.hu

( PtY | 2013. 10. 29., k – 10:13 )

Szerintem ne a VPN-en keresztül netezz/emailezz.
Fölösleges forgalmat generálsz (minden titkosítva megy az otthoni géped és a vps között), és evvel fölösleges terhelést a CPU-knak mindkét oldalon.
Amit titkosítva illik, azt használd SSL-en keresztül, de ne mindent.
Megnöveled a hibalehetőségek számát. Ha pl. a helyi szolgáltatódnál akadnak gondok, az mindenképpen érint, de ha a vps-ben van csak probléma, miért legyen Nálad is?
Én a Helyedben a vps-en smtp authot csinálnék, és minden SSL-en keresztül tennék elérhetővé (IMAP/SMTP/whatever). De az is megoldható (ahogyan Te szeretnéd), hogy a levelet (IMAP) az otthoni részen lennének, de az SMTP viszont a VPS-en. Oda elég egy user, amivel az otthoni smtp authol, és smarthostként használod. Így garantáltan fix IP-ről megy ki a leveled. Természetesen az otthoni smtp és a vps-en futó smarthost is SSL-en kommunikálna. Az MX rekord meg lehet az otthoni gépedre mutató DDNS bejegyzés, bár ha van fix IP-d, akkor Te is tudsz csinálni DDNS-t saját részre egy kis trükkel.
--
PtY - www.onlinedemo.hu

evvel fölösleges terhelést a CPU-knak mindkét oldalon
Szerintem ez a kis felhasználószám miatt nem releváns szempont.

Én a Helyedben a vps-en smtp authot csinálnék, és minden SSL-en keresztül tennék elérhetővé (IMAP/SMTP/whatever).
Ezzel probléma, hogy adatok nagyrészt VPS-en lennének tárolva és a VPS fizikai védelme nem biztosítható.

De az is megoldható (ahogyan Te szeretnéd), hogy a levelet (IMAP) az otthoni részen lennének, de az SMTP viszont a VPS-en. Oda elég egy user, amivel az otthoni smtp authol, és smarthostként használod.
Véleményem szerint annál biztonságosabb a rendszer minél kevesebb funkció van a VPS-en telepítve. Illetve felügyelet, karbantartás is egyszerűbbnek tűnik számomra, ha az otthoni szerveren van minden telepítve.

Az MX rekord meg lehet az otthoni gépedre mutató DDNS bejegyzés, bár ha van fix IP-d, akkor Te is tudsz csinálni DDNS-t saját részre egy kis trükkel
Ez a megoldás bonyolultabbnak tűnik mint egy VPN kapcsolat. Valószínűleg több lenne a lehetséges hibaforrás is.

"Szerintem ez a kis felhasználószám miatt nem releváns szempont."
Ahogy gondolod... :)

"Ezzel probléma, hogy adatok nagyrészt VPS-en lennének tárolva és a VPS fizikai védelme nem biztosítható."
A levelek nem ott lesznek - legalábbis a terv szerint. Milyen adat lenne ott, és miért nem biztosítható a védelme? Főleg mit értünk "fizikai" védelem alatt?

"Véleményem szerint annál biztonságosabb a rendszer minél kevesebb funkció van a VPS-en telepítve."
Ha túl kevés a funkció, akkor minek a vps?

"Ez a megoldás bonyolultabbnak tűnik mint egy VPN kapcsolat."
És hibatűrőbb. Azt se felejtsd el, ha nem az internettel van gond, egyik oldalon sem, hanem csak a vpn-ben van valami probléma, akkor sem internetezik senki...

--
PtY - www.onlinedemo.hu

A levelek nem ott lesznek - legalábbis a terv szerint. Milyen adat lenne ott, és miért nem biztosítható a védelme?
Ok, akkor félreértettelek.


Főleg mit értünk "fizikai" védelem alatt?
fizikai védelem = fizikailag rajtam kívűl senki nem fér hozzá a szerverhez.

Ha túl kevés a funkció, akkor minek a vps?
- FIX IP cím olyan tartományban, amit csak szeretnék és nem számítana SPAM-nak a szerverről kiküldött levél
- Otthoni szerver IP-jének elrejtése

És hibatűrőbb. Azt se felejtsd el, ha nem az internettel van gond, egyik oldalon sem, hanem csak a vpn-ben van valami probléma, akkor sem internetezik senki...
Valóban érdemes lenne backup mail szervert telepíteni VPS-re és ha gond van VPN kapcsolattal, otthoni szerverrel akkor addig ideiglenesen a leveleket fogadni tudá a VPS is. Ezt nem tudom hogyan lehetne egyszerűen megoldani.

"fizikai védelem = fizikailag rajtam kívűl senki nem fér hozzá a szerverhez."
Fizikailag Te sem fogsz :) VPS.

"Otthoni szerver IP-jének elrejtése"
A received-from fejlécekből akkor ki kell majd szedegetned. Másrészt a fix ip alapján hamarabb tudni fogják, hogy Te vagy a drót másik oldalán, mint ha maradna dinamikus. Erre használhatnál inkább auth-os proxy-t, de nvan csomó anonimizer, amivel lehet bohóckodni, nem kell vpn emiatt. Ha meg mégis, ott a thor.

"Valóban érdemes lenne backup mail szervert telepíteni VPS-re és ha gond van VPN kapcsolattal, otthoni szerverrel akkor addig ideiglenesen a leveleket fogadni tudá a VPS is. Ezt nem tudom hogyan lehetne egyszerűen megoldani."
Úgy, hogy a vps-es szervered az mx, a transport meg másik szerverre (dns name) mutat a saját domainedre vonatkozólag. Kb. 2 perc postfixben beállítani. Ilyenkor a vps gyakorlatilag fenntart egy elsődleges queue-t.

--
PtY - www.onlinedemo.hu

"fizikai védelem = fizikailag rajtam kívűl senki nem fér hozzá a szerverhez."

Az még nem jutott eszedbe, hogy ha valaki nagyon hozzá akar férni a secure cuccodhoz, észrevétlenebbül meg tudja csinálni, mint az otthoni fix IP vagy fizikai szerverelhelyezés esetén?
Hogyan védekezel az ellen, ha valaki snapshotot csinál róla, megnézi, hogy kommunikál az otthoni rendszereddel, módosít rajta egy picit, aztán észrevétlenül a VPS-ed IP-jét a preparált VM-re irányítja?

Az még nem jutott eszedbe, hogy ha valaki nagyon hozzá akar férni a secure cuccodhoz, észrevétlenebbül meg tudja csinálni, mint az otthoni fix IP vagy fizikai szerverelhelyezés esetén?
Hogyan védekezel az ellen, ha valaki snapshotot csinál róla, megnézi, hogy kommunikál az otthoni rendszereddel, módosít rajta egy picit, aztán észrevétlenül a VPS-ed IP-jét a preparált VM-re irányítja?

De gondoltam erre és egyéb hasonló VPS felöl elméletileg lehetséges támadásokra. Nem tudom pontosan mennyivel lenne biztonságosabb az otthoni szerver+VPS kombináció használata, ahhoz képest mintha minden csak egy VPS-en lenne telepítve.
Azt gondoltam (lehet tévedek), hogy a 2 szerver kombinációjával (otthoni szerver + VPS) az adatok nagyobb biztonságban lennének. Ezért is gondoltam azt, hogy minél kevesebb dolog van a VPS-en telepítve annál biztonságosabb lehet a rendszer. Ha csak egy openVPN szerver lenne a VPS-en és semmi más, akkor azt gondoltam, hogy nem lenne olyan egyszerű dolga az adatok megszerzésében, annak aki a VPS-be bejutna. De valaki pont azt az érvet hozta fel, hogy szerinte meg VPN kapcsolat miatt aki bejut a VPS-re gyakorlatilag az otthoni szerverre is könnyen be tud jutni a VPS-en kersztül és érdemesebb lenne VPS-re telepíteni proxikat, MTA-t és alkalmazások szintjén kapcsolódni a VPS-hez (ssl-en keresztül) az otthoni szerverről.

Az biztos, hogy csak simán egy VPS-re feltelepíteni mindent sokkal egyszerűbb megoldás lenne, mint az általam felvázolt 2 szerveres felállás.
Így nyitott vagyok arra, hogy erről meggyőzzetek :)

Én egészen konkrétan arra próbáltam rávilágítani, hogy egy VPS-t sokkal könnyebben tudnak módosítani, mint egy fizikai szervert. Miből áll, hogy a storage-ed valaki "távolról" olvassa/írja?
Ha abban nem bízol, hogy valahová fizikai szervert tegyél be, akkor miért bíznál egy olyan megoldásban, ahol a fizikai réteg után van még egy transzparens támadási felület.
Ilyen extrém biztonsági igénynél gondoljunk extrém lehallgatási módszerre is: mondjuk az összes memóriaírás logolása. Ebben az esetben ha több van rajta, mint hogy specifikus portokat forwardolsz otthonra/otthonról, már bukta.

( Proci85 v | 2013. 10. 29., k – 10:16 )

Jól érzem, hogy az elmúlt időszakban felröppent, -gmail és társaival kapcsolatos-, bizalmatlansági kérdések miatt szeretnéd ezt az egészet?
Szerintem egy VPS (rajta encryptfs, amit csak jelszóval lehet felcsatolni vagy jó hosszú kulcs fájllal) elég jó biztonságot adhat.
_Figyelembe_véve_ a potenciális fenyegetettség, bekövetkezési valószínűség és az üzemeltetés költségét, ez a megoldás a legjobb (szerintem).

Jól érzem, hogy az elmúlt időszakban felröppent, -gmail és társaival kapcsolatos-, bizalmatlansági kérdések miatt szeretnéd ezt az egészet?

Az elmúlt időszak botrányai csak plusz motivációt jelentettek számomra, de nem okot.

Szerintem egy VPS (rajta encryptfs, amit csak jelszóval lehet felcsatolni vagy jó hosszú kulcs fájllal) elég jó biztonságot adhat.Figyelembe_véve_ a potenciális fenyegetettség, bekövetkezési valószínűség és az üzemeltetés költségét, ez a megoldás a legjobb.

Ennél biztonságosabb megoldást szeretnék.
Üzemeltetés költsége a biztonsághoz képest számomra sokadlagos szempont.

Először tisztázni kéne, hogy milyen szintű biztonságot szeretnél elérni. A "minél nagyobbat" kijelentés értelmetlen. Ha tudod hogy milyen szintre van szükséged, akkor ahhoz lehet méretezni a fizikai és logikai védelmet és esetlegesen a megbízhatóságot is, mert gondolom ilyen fontos esetben az is szempont.

A fizikai védelemről: a Dataplex elé kocsival csak úgy tudsz beállni, ha előtte a kapuőr áttükrözte a jármű alját és leengedte az acél nemtommit, ami alighanem egy tankot is megállít (más kérdés, hogy a tank viszont átkocog a kerítésen). Ha mindig otthon vagy, sose alszol és ilyen acél izéd is van, akkor már majdnem eléred azt a szintet ami a Dataplex előszobája, ahonnét eleve csak belépőkártyával lehet bemenni az ügyféltérbe, fémkapun és forgókapun át.

Tovább finomítja a helyzetet hogy a Dataplexben elég sok cégnek és talán állami intézménynek van infrastruktúrája, ha oda (akár az ügyféltérbe, akár a hosting területre) akarnak illetéktelenek bejutni, akkor hamarabb ugrik a TEK mintsem a rendőrség felvenné a panaszodat, hogy betörtek hozzád és elvitték az otthoni szerveredet.

Ha jogi eszközzel lépnek fel, azaz bírósági határozattal viszik el a gépedet, akkor az ellen se otthon, se a hostingnál nem tudsz mit csinálni (illetve de, eleve olyan felségterületen kell üzemeltetni, ahonnét nem tudják elvinni). De ez már megint a logikai védelem.

Először tisztázni kéne, hogy milyen szintű biztonságot szeretnél elérni
Az elindított témával részben ez is a célom, hogy az ilyen kérdésekre pontosabb választ tudjak adni. Lássam, hogy mire lenne szükségem, mi az amit magam is meg tudok valósítani és mai az amivel szakembert kéne megbíznom a rendszer kialakításánál.

A fizikai védelemről: a Dataplex elé kocsival csak úgy tudsz beállni, ha előtte a kapuőr áttükrözte a jármű alját és leengedte az acél nemtommit, ami alighanem egy tankot is megállít [...]
Hagyjatok már ezekkel a "szerver hoszting milyen biztonságos" érvekkel :D
Ha egy rajtad kívülálló szervezet szolgáltatásában kell biznod, akkor kiszolgáltatott vagy. Akár tankokkal is őrizhetnének Dataplex-ben a szervereket az sem változtat ezen. Fogadjátok már el, hogy nálam otthon biztonságosan megoldható a szerver elhelyezése.

Ha jogi eszközzel lépnek fel, azaz bírósági határozattal viszik el a gépedet, akkor az ellen se otthon, se a hostingnál nem tudsz mit csinálni (illetve de, eleve olyan felségterületen kell üzemeltetni, ahonnét nem tudják elvinni). De ez már megint a logikai védelem.

Elméletileg ez is megoldható az általam felvázolt megoldással VPS olyan országban van amelyikben csak akarom. Az otthoni szerver IP-je meg nem látszik Internet felől, hanem csak a VPS IP-je.

Elméletileg tetszőleges biztonságot is elérhetsz, legfeljebb marha sokat kell fejleszteni. Gyakorlatilag, a (rém)híreket nézve, jelenleg nem nagyon van olyan, széles körben elterjedt protokoll, amit ne lehetne viszonylag értelmes időn belül törni.

Azt hiszem a PGP épp kivétel, így a PGP alapú titkosítással viszonylag jól lehet biztosítani egy-egy üzenet vagy a fájlok hitelességét, titkosságát. Más kérdés, hogy egy ilyen megoldás kialakítása macera, pláne ha nincs minden fél felkészítve a titkosított levelek fogadására.

Viszont arról sosem fogsz meggyőzni, hogy otthon jobb lesz. A "rajtad kívül álló szervezet" az épp úgy bejátszik, ISP, ELMÜ, miegyéb. Ha nem tartasz a törvényes úton érkező (az lényegtelen hogy jogos vagy jogtalan) támadásoktól, akkor egy hosting cég mindenképpen megbízhatóbb lesz.

Viszont arról sosem fogsz meggyőzni, hogy otthon jobb lesz. A "rajtad kívül álló szervezet" az épp úgy bejátszik, ISP, ELMÜ, miegyéb. Ha nem tartasz a törvényes úton érkező (az lényegtelen hogy jogos vagy jogtalan) támadásoktól, akkor egy hosting cég mindenképpen megbízhatóbb lesz.

Nem állítottam, hogy a rajtam kívülálló szervezetektől való függőség teljesen megúszható, ha a szervert otthon tartom, de egy szervezettel (szerver hoszting cég) legalább kevesebbtől kell függenem. ISP, ELMÜ stb szervezetektől akkor sem tudsz független lenni, ha szerverhosztingnál van a szervered.

Nem látom értelmét szerver hosztingnál fizikai szerver elhelyezésének, mert azt nem tartom biztonságosabbnak, mintha csak simán VPS-t használnék, vagy mintha otthon tartom a szervert.

Amúgy nem akarlak ebben a kérdésben meggyőzni, mert értelmetlen ezen vitatkozni, nem visz előrébb.

Az ISP, ELMÜ és társaitól annyiból nem függesz egy hostingál, hogy a hosting fel van készülve az esetleges problémákra. Redundáns kapcsolatokkal, pótáramforrással és ügyvédekkel. Ezért hasznos olyan helyen tartani a gépet ahol a nagyok, mert nem miattad, de miattuk állatira figyelnek, hogy ne legyen gáz.

Az, hogy a fizikai gép biztonságosabb-e mint a VPS már egy másik kérdés, elvinni nehezebb, letörölni könnyebb :D

De persze nem kell egyetértenünk :D

[OFF]
Az, hogy a fizikai gép biztonságosabb-e mint a VPS már egy másik kérdés, elvinni nehezebb, letörölni könnyebb :D

Annál van biztosabb, ha azt sem tudják honnan kell elvinni a szervert? :D
Az általam felvázolt felállásban a VPS-en nincsen érzékeny adat tárolva, ha lefoglalják, lemásolják az adatokat róla azzal nem sokat lehet kezdeni.
A fizikai szerver IP-je pedig a VPN miatt nem látszik.

Szóval szerintem neked mást jelent a biztonság, mint nekem.
Nekem az a biztonság, ha a szerverhez a tulajdonosán kívül senki nem fér hozzá, és a senki tényleg senkit jelent.
Neked az ha egy jól örzött helyen vigyáz rá egy olyan szervezet, akinek rajtad kívül fizikai hozzáférése van a szerveredhez és pl. törvényes megkeresés esetén (lényegtelen, hogy jogos, vagy jogtalan) akár ki is adják a szerveredet másnak.
[ON]

"Nekem az a biztonság, ha a szerverhez a tulajdonosán kívül senki nem fér hozzá, és a senki tényleg senkit jelent."

Nekem is kb. ezt jelenti. Viszont míg otthon megvan az illúziód hogy csak te férsz hozzá, egy hosting esetén tudod hogy ki és milyen feltétellel nyúlhat a gépedhez. Más kérdés, hogy ezeket a feltételeket mennyire tartják be, ez már hely- és szabályzatfüggő.

Amúgy VPS + biztonság + érzékeny adat: ha megjelenik a VPS memóriájában, titkosítatlanul, akkor _szerintem_ már kár tovább foglalkozni a dologgal. Ha titkosítva van, akkor a tudomány legújabb állása szerint szintén kár.

( abli | 2013. 10. 29., k – 10:52 )

Az "alacsonyabb rendelkezésre állás" kapcsán egy extra ötlet: vannak "backup MX" szolgáltatások (pl. http://www.mxsave.com/services-backup-mx.html), amik az bejövő email-eket fogadják és tárolják, ha az elsődleges (pl. általad üzemeltetett) MX nem elérhető. Elvileg ezzel a bejövő emailek fogadásának folyamatossága megoldható.

Az "alacsonyabb rendelkezésre állás" kapcsán egy extra ötlet: vannak "backup MX" szolgáltatások (pl. http://www.mxsave.com/services-backup-mx.html), amik az bejövő email-eket fogadják és tárolják, ha az elsődleges (pl. általad üzemeltetett) MX nem elérhető. Elvileg ezzel a bejövő emailek fogadásának folyamatossága megoldható.

Köszi a javaslatot, de talán célszerűbb lenne a VPS-en kialakítani valami hasonlót és nem külső szolgáltató szolgáltatását igénybe venni ehhez.

( uid_7086 | 2013. 10. 29., k – 12:34 )

Egyébként apróság, de annak is nézz utána, hogy
1. A szolgáltatód engedi-e, hogy mail szervert üzemeltess? (úgy értem: fizikailag engedi-e, mert pl. a Diginél szűrik a 25-ös portot és kizárólag akkor hajlandóak átengedni, ha fix IP címet rendelsz, ami nagyjából megduplázza a havidíjat)
2. Legális-e az általad használt végponton a szerver üzemeltetés? (anno asszem, a UPC szerződése explicite tiltotta az ilyesmit)

Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

1. A szolgáltatód engedi-e, hogy mail szervert üzemeltess? (úgy értem: fizikailag engedi-e, mert pl. a Diginél szűrik a 25-ös portot és kizárólag akkor hajlandóak átengedni, ha fix IP címet rendelsz, ami nagyjából megduplázza a havidíjat)

Ha az otthoni szerver VPN-en kapcsolódik a VPS-hez, akkor irreleváns, hogy az otthoni internet szolgáltató mit csinál a 25-ös porttal.


2. Legális-e az általad használt végponton a szerver üzemeltetés? (anno asszem, a UPC szerződése explicite tiltotta az ilyesmit)

Legális, de amúgy is irreleváns, mert szolgáltató úgy sem látja, hogy mi az adatforgalom pontos forrása.

1. Ebben valószínűleg igazad van, nem olvastam el elég aprólékosan, hogy mit akarsz
2. Nem irreleváns, mert attól, hogy technikailag kivitelezhető, még sérthetsz szerződést. (más téma, hogy ha VPN-en lógsz, akkor ilyen szempontból még számíthat-e szerver üzemeltetésnek a dolog vagy sem)

Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

2. Nem irreleváns, mert attól, hogy technikailag kivitelezhető, még sérthetsz szerződést. (más téma, hogy ha VPN-en lógsz, akkor ilyen szempontból még számíthat-e szerver üzemeltetésnek a dolog vagy sem)

Esetemben ez irreleváns, mert szolgáltató eleve nem tiltja. (Amúgy szerintem VPN kapcsolat miatt eleve nem is számítana szervernek.)

Nem egészen. Befelé mindenképp szűrik, kivéve ha fix IP-d van és külön kéred, hogy engedjék át.
Hiába nyitsz meg 25-ös portot a saját csatlakozásodon, nem jut el hozzád egy darab mail sem, de még a telnet kísérletek sem), kifelé meg smarthostként használhatod az ő szerverüket megfelelő authentikáció után x mennyiségig, ahol az x fogalmam sincs, mit takar ;)
(pár hónapja, talán egy éve is, hogy próbáltam saját mail szervert beüzemelni, a végén már tcpdump-pal néztem a routeren bejövő forgalma és nyoma sem volt az smtp csomagoknak. Ekkor hívtam fel a helpdeskjüket és ők mondták, hogy ne is kísérletezzek, mert csak a fenti feltételek mellett lehet mailt fogadni)

Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Hát az lehet. Feltéve, hogy nincs fix IP-d.
Illetve mostanában jönnek érdekes forgalmak a környéken lakóktól is, mintha a tisztelt szolgáltató switch-e kissé érdekesen terelgetné a biteket.

Az biztos, hogy amikor én ezzel próbálkoztam (visszagondolva jó rég volt, mert még működött a kedvenc nyitott port ellenőrzőm :) ), akkor hozzám nem jutott el belőle semmi és a reklamációmra a fenti választ kaptam.

Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Ez érdekes, kipróbáltam és valóban! Befelé is szűrik! Most vagy az van, hogy rosszul emlékeztem és még Telekomos userként jöttek az említett kis kínaiak, vagy időközben a Digi elkezdte szűrni. Egy a lényeg, már nem úgy van, ahogy emlékeztem, szóval jogos, igazad volt, bocsi! ;)

Az van, hogy időközben kezdték szűrni (hogy kapnák be a...) - amikor bekötötték, még tudtam e-mailt fogadni. Aztán sokáig nem volt rá szükségem és amikor megint előjött az igény, már nem működött.

Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

( PcZolee v | 2013. 10. 29., k – 12:56 )

Ha mindenképpem az otthoni szervereden szeretnéd a LAMP-ot és a mailt üzemeltetni, akkor én azt csinálnám, hogy a VPS-re kérnék még egy ip-t, és az új ip-t egy az egyben átroutolnám vpn-en az otthoni szerverre! Ez egyszerű is, biztonságos is, és a rendelkezésreállása is elfogadható, főled a ddns-es megoldásokhoz képest.

<= Powered By Ubuntu & Gentoo Linux =>

'Software is like sex: It's better when it's free!'
By Linus Torvalds

Ha mindenképpem az otthoni szervereden szeretnéd a LAMP-ot és a mailt üzemeltetni, akkor én azt csinálnám, hogy a VPS-re kérnék még egy ip-t, és az új ip-t egy az egyben átroutolnám vpn-en az otthoni szerverre! Ez egyszerű is, biztonságos is, és a rendelkezésreállása is elfogadható, főled a ddns-es megoldásokhoz képest.

Hogyan oldanád ezt meg?
Miben lenne ez előnyösebb megoldás, mint VPN szerveren keresztüli kapcsolat?
Ebben az esetben az otthoni szerver IPcíme nem lenne látható?

Amúgy a VPS másra nem lenne használva csak ehhez így teljesen mindegy, hogy azt az az IP címet routolnám át az otthoni szerverre, amit eleve kapok VPS-hez, vagy egy másikat.

Pontosan hogy érted azt, hogy hogyan oldanám meg? Technikai részletekre gondolsz, vagy a felépítés nem volt egyértelmű esetleg konkrét programok érdekelnek?

Kivülről az az ip látszódna, amit veszel a vps-hez pluszba! Azért nem használnám az ő meglévő ip-jét, mert:
1. portforwardok kellenek, az meg macerásabb (persze megoldható ez is)
2. jobb meghagyni a vpn szervernek az ip-jét külön, anélkül, hogy ugyanott más szolgáltatások is lennének

Egyébként egyplusz ip pár huf/hó, szóval nem beszlünk nagy összegekről...

De te tudod, minden esetre, a megoldás egyszerű ;).

<= Powered By Ubuntu & Gentoo Linux =>

'Software is like sex: It's better when it's free!'
By Linus Torvalds

Technikai részletekre gondolsz, vagy a felépítés nem volt egyértelmű esetleg konkrét programok érdekelnek?

Kivülről az az ip látszódna, amit veszel a vps-hez pluszba! Azért nem használnám az ő meglévő ip-jét, mert:
1. portforwardok kellenek, az meg macerásabb (persze megoldható ez is)
2. jobb meghagyni a vpn szervernek az ip-jét külön, anélkül, hogy ugyanott más szolgáltatások is lennének

Felépítés és konkrét programok is érdekelnek.
Mit telepítenél VPS-re és mit az otthoni szerverre stb...?
Akkor tulajdonképpen a VPS-ből egy routert csinálnál, ami a VPS-hez igényelt második IP-t egy az egyben átroutolná az otthoni szerver IP-jére?
Ebben az esetben az otthoni szerver amikor válasz csomagot küldene, akkor azt közvetlenül arra az IP-re küldené, ahonnan a kérés érkezett és nem a VPS-en keresztül és így látszana az otthoni szerver IP-je, vagy nem?
25-ös portot az otthoni szolgáltató kifele és befele is tiltja/szűri. Ez nem jelentene gondot az általad felvázolt megoldásnál?

Én openvpn-nel oldottam meg hasonló feladatot. Semmi másra nincs tulajdonképpen szükség, csak erre, meg a megfelelő tűzfalszabályokra.

Tulajdonképpen igen, egy router lenne a VPS-ből, és ahogy írog a másik ip-t egy az egyben az otthoni szerver "kapja meg". Mivel a kommunikáció a két gép között vpn-ben megy, így senkit nem érdekel mit tilt a szolgáltató. Kivülről úgy néz ki, mintha a szerverteremben levő gép küldené a mailt, ill fogadná, de közben ő "csak" routol és mindent az otthoni géped csinál.

<= Powered By Ubuntu & Gentoo Linux =>

'Software is like sex: It's better when it's free!'
By Linus Torvalds

( djsilas | 2013. 10. 29., k – 14:43 )

"Mit gondoltok?"
Hacsak nem tapasztalat szerzés a cél, akkor: hülyeség

Mert ilyen formában semmi értelme, a felvetett ötletek közül semmi nem jó. Végigolvasva azt sem tudod mit akarsz (de szerintem volt olyan is, amikor az se ment át, hogy épp mit javasolnak...), egyik szál szól valamiről, a másikban már érvényét veszti, mert Isteni sugallat hatására már mást akarsz és a többi és a többi. Ezért. Azért röhögni még maradok, ahogy időm engedi...

Mert ilyen formában semmi értelme, a felvetett ötletek közül semmi nem jó. Végigolvasva azt sem tudod mit akarsz

Egy biztonságos email szervert szeretnék 15-20 felhasználó kiszolgálására.

Azt, hogy ezt hogyan képzeltem megvalósítani a topicnyitó hozzászólásomban leírtam.
A hozzászólások alapján próbálom felmérni mennyire életképes az elképzelésem, létezik-e jobb megoldás az általam felvázoltnál.

Ezen mit nem értesz?
Írhatnál vmi konkrétumot is.

VPN-en mész ki, de mégis az otthoni IP címed miatt félsz, hogy SPAM -nek nézik a szerverek azok leveleit, akik erre nem is használják a szervert, mert hát localba leveleznek. Jó bocs, 80%-ban... a másik 20% esetén meg telnetelnek, meg tanúsítványt ellenőriznek, hogy merjenek-e levelet írni. Hát... ehhez konkrétan nem tudok hozzászólni, elvesztettem a fonalat.


VPN-en mész ki, de mégis az otthoni IP címed miatt félsz, hogy SPAM -nek nézik a szerverek azok leveleit, akik erre nem is használják a szervert, mert hát localba leveleznek. Jó bocs, 80%-ban...

Kevered a dolgokat.
Vagy nem olvastad el rendesen amiket írtam, vagy nem érted.
Na jó kedvedért mégegyszer röviden:

SPAM téma úgy jött elő, hogy egyesek DDNS szolgáltatás használatát javasolták az otthoni szerver VPS-el való VPN kapcsolata helyett.
Ha csak DDNS-t használna az otthoni szerver, akkor IP címe miatt a szerveren kívülre menő levelek más szolgáltatüknál SPAM mappában landolnának.
Természetesen local levelezésnél ezzel nem lenne probléma.


a másik 20% esetén meg telnetelnek, meg tanúsítványt ellenőriznek, hogy merjenek-e levelet írni.

Én ilyet nem írtam, félreolvastad. Pontosan azt írtam, hogy senki sem telnetelne, hanem saját szerveren kívülre csak OpenPGP használatával tudnának a felhasználok bizalmas levelezést folytatni (ha szeretnének)...


elvesztettem a fonalat.

Nekem is úgy tűnik, hogy nem igazán vagy képben.

Például nálam is. :) Az összes dinamikus IP tartományból jövő levél "nem kerül elfogadásra". Csak FIX IP, csak ha feloldható név van mögötte, csak ha van reverse bejegyzés hozzá, csak ha mondd egy tisztességes feloldható nevet a helo üzenetben... ...csak akkor vesszük át tőle a levelet. /ez utóbbival évente 1-2 partnerrel gond akad, de már leszoktam róla, hogy magyarázzam, ezeket felveszem kivételszabályba és jóccakát/

Rózsár Gábor (muszashi)

Azt hogy állapítod meg, hogy dinamikus tartományból jött-e?
A dinamikus dns meg nem zárja ki, hogy legyen hozzá reverse bejegyzés is. (legalábbis úgy emlékszem, a DynDNS-en még volt reverse)

Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

http://whatismyipaddress.com/blacklist-check
Én ezt találtam.
Érdekes.
Pár címemet ellenőriztem. Volt amelyik csak egyetlen szerveren szerepelt, de ehhez pirossal odaírták, hogy nem célszerű használni, de a többség 4-5 helyen is felkiáltójeles lett.
Ebből egyet ellenőriztem: ott a komplett IP tartomány spammerként van számon tartva.

Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

No response nem volt. Vagy zöld vagy piros. Többnyire zöld és a többség 4-5 szervertől kap pirosat. És van egy, amelyiktől minden ellenőrzött címem azt kapott, de azt a kiírás szerint nem javasolt spam ellenőrzéshez használni. :)
(azért néha egész érdekes dolgokat tanulok itt, csak kár, hogy mivel nem használom, hamar el is felejtem :( )

Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

( zither | 2013. 10. 29., k – 15:27 )

Olvasva a hozzászólásokat és az azokban kifejtett részletek a legegyszerűbb megoldás szerintem:

* Otthon beállítod a levelező rendszeredet, ahogy szeretnéd, illetve belősz egy dns-t rá (a fix ip problémái miatt legegyszerűbb egy dyndns-t).
* A VPS-ben beállítasz egy levelező szervert, amire mutatni fog az MX rekordod. Ezen a levelező szerveren beállítod, hogy a domainre érkező leveleket fixen továbbítsa az otthoni szerveredre, a többi levelet meg a megfelelő domainre. Közben _rohadtul_ odafigyelsz, hogy véletlenül se legyen belőle open relay (többszörösen ellenőrizd).
* Az otthoni szervereden beállítod, hogy a nem helyi kézbesítés menjen a vps-re relay módban.

Így a belső leveleid mindig bent maradnak, csinálhatsz rá olyan biztonságot, amilyet akarsz. A külső partnerek elöl az egészet elrejti a vps, fix ipvel, könnyen kezelehető spf-el. Az otthoni szerver esetleges alkalmankénti kiesését a vps szintúgy elfedi --> mindig át tudod venni a feléd érkező leveleket. A külső levelek csak ideiglenesen ülnek a vps-en, a belső meg sose kerül rá --> nem kell félned a szolgáltatódtól.

Szerk:
A webes részt meg esetleg megoldhatod reverse proxyval.

Zavard össze a világot: mosolyogj hétfőn.


* Otthon beállítod a levelező rendszeredet, ahogy szeretnéd, illetve belősz egy dns-t rá (a fix ip problémái miatt legegyszerűbb egy dyndns-t).
* A VPS-ben beállítasz egy levelező szervert, amire mutatni fog az MX rekordod. Ezen a levelező szerveren beállítod, hogy a domainre érkező leveleket fixen továbbítsa az otthoni szerveredre, a többi levelet meg a megfelelő domainre. Közben _rohadtul_ odafigyelsz, hogy véletlenül se legyen belőle open relay (többszörösen ellenőrizd).
* Az otthoni szervereden beállítod, hogy a nem helyi kézbesítés menjen a vps-re relay módban.

Így a belső leveleid mindig bent maradnak, csinálhatsz rá olyan biztonságot, amilyet akarsz. A külső partnerek elöl az egészet elrejti a vps, fix ipvel, könnyen kezelehető spf-el. Az otthoni szerver esetleges alkalmankénti kiesését a vps szintúgy elfedi --> mindig át tudod venni a feléd érkező leveleket. A külső levelek csak ideiglenesen ülnek a vps-en, a belső meg sose kerül rá --> nem kell félned a szolgáltatódtól.

Szerk:
A webes részt meg esetleg megoldhatod reverse proxyval.

Köszönöm, így elsőre egész jól tűnik a javaslatod.

Ebben a felállásban a vps-ről továbbküldésre kerülnek a levelek, nincs helyi tárolás. Tehát ha bármikor belenéz a vps-be, nem látja a leveleket.
Amennyiben annyira félünk a szolgáltatótól, hogy feltételezzük, folyamatos tartalom elemzést fog futtatni (amivel ténylegesen össze szedhetné a leveleket), akkor felmerül, hogy az internet szolgáltatónkban (sőt, általában a szolgáltatókban) miért bízunk meg, mivel ők is el tudják érni ezt az állapotot. (Nem mellesleg akkor az összes vps-ben proxyzunk, vpn végpontot csinálunk, forgalmat átirányítunk ötlet is nyugodtan mehet a levesbe.)

Ebben az esetben az egyetlen megoldás, ha valamilyen zárt rendszert képzünk, amely semmilyen nyitott csatornán nem kommunikál. Igaz innentől kezdve (a zártság miatt) semmilyen kívülről induló vagy kifelé tartó forgalom nem lehetséges (pl külső címről levelet fogadni).

Ezen a ponton javaslom a kérdezőnek, hogy csináljon legalább saját magának egy kockázat elemzést (mégis mitől akarja megvédeni az adatait). Aztán ha ezt sikerült tisztáznia magával, akkor térjen vissza a kérdésre.

Zavard össze a világot: mosolyogj hétfőn.

En kozben irtam privatot. :)

Köszönöm, megkaptam!
Ha nem gond a releváns részt ide is bemásolom a leveledből:


A VPN nem feltétlenül fontos, inkább
proxyzásban gondolkodnék, de persze együtt is lehet a kettőt. A VPS-re
egy Varnish-t tennék webproxy-nak, dovecot-ot imap proxy-nak és egy
rendes MTA-t smarthostnak. Ha VPN-ezel is, akkor OpenVPN-t és az
alkalmazás szintű titkosítás megúszható a két pont között.

Legalább értelmezni próbáld amit írt, ha már nem törődsz olyan apróságokkal, mint netikette!

A VPN az nem alkalmazás szintű titkosítás! Épp arról van szó, hogy a VPN-nel ki tudod váltani azt, hogy alkalmazás szintjén kelljen kódolni az adatforgalmat.
(vagy valamit én értek félre urak?)

ui: VPN-ből hányféle létezik? Már úgy értem: milyen rétegeket lehet vele titkosítani? Úgy emlékszem, az OpenVPN a L3-ban turkál, míg a... hm... PPTP? A L2-ben.

Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

A VPN az nem alkalmazás szintű titkosítás! Épp arról van szó, hogy a VPN-nel ki tudod váltani azt, hogy alkalmazás szintjén kelljen kódolni az adatforgalmat.
(vagy valamit én értek félre urak?)

Szerintem jól érted. (Csak előszőr másra gondoltam én is.)


VPN-ből hányféle létezik? Már úgy értem: milyen rétegeket lehet vele titkosítani? Úgy emlékszem, az OpenVPN a L3-ban turkál, míg a... hm... PPTP? A L2-ben.

https://www.ivpn.net/knowledgebase/62/PPTP-vs-L2TP-vs-OpenVPN.html

[OFF]
Csak így kicsit hülyén jön ki, mert ha jól látom, mialatt írtam, átszerkesztetted a hozzászólásodat. :)

Eredetileg kihagyta andrej_ a 'nem' szócskát az első mondatából így kicsit összezavart mit is akar mondani. Közben kapcsoltam és beírtam a kifelejtett 'nem' szócskát a mondatába és egyből láttam, hogy hülyeséget is írtam. :-)
[ON]

A VPN nem feltétlenül fontos, inkább
proxyzásban gondolkodnék, de persze együtt is lehet a kettőt. A VPS-re
egy Varnish-t tennék webproxy-nak, dovecot-ot imap proxy-nak és egy
rendes MTA-t smarthostnak. Ha VPN-ezel is, akkor OpenVPN-t és az
alkalmazás szintű titkosítás megúszható a két pont között.

Ha állandó VPN kapcsolat van otthoni szerver és VPS között, akkor miért kellenének a proxyk?
Miért nem lenne érdemesebb inkább mindent az otthoni szerverre telepíteni?
MTA és dovecot VPS-re való telepítésének csak annyi értelmét látom, hogy ha az otthoni szerver és VPS között valamiért megszakad a VPN kapcsolat akkor ideiglenesen a VPS is fogadni tudja a leveleket.

Mert a proxy jó dolog. Remekül lehet velük pl. protokoll szinten szűrni, forgalmat spórolni stb. Persze lehet nat-olni, port továbbítani is a VPN-be, de szerintem jobb ha gyorsan átveszed a levelet, kezeled a webet. Az pedig nem is tartozik a kedves külvilágra, hogy milyen belsőséggel oldod meg a kiszolgálást. A webproxy azért is jó, az otthoni kapcsolatod késleltetése is kissé elfedhető és ha esetleg lemegy a neted, akkor kitehetsz egyszerűen egy "karbantartás alatt" oldalt.

szerintem jobb ha gyorsan átveszed a levelet, kezeled a webet. Az pedig nem is tartozik a kedves külvilágra, hogy milyen belsőséggel oldod meg a kiszolgálást. A webproxy azért is jó, az otthoni kapcsolatod késleltetése is kissé elfedhető és ha esetleg lemegy a neted, akkor kitehetsz egyszerűen egy "karbantartás alatt" oldalt.

Igazából weben csak az emailekhez (pl.: rouncube) szertnék hozzáférést biztosítani a felhasználóknak.
Nem tudom, hogy ennek a használatánál mennyire lehetne észrevenni, hogy nem a VPS-en van a webszerver, hanem az otthoni gépen. Ezt gondolom ki kéne próbálni, másként nem derül ki.

Az valóban jó lenne ha otthoni szerver és VPS kapcsolat problémák esetén VPS valamilyen szinten backup szerverként funkcionálna, pl ilyenkor weben "karbantartás alatt" oldal jelenne meg stb...

( procika v | 2013. 10. 30., sze – 10:43 )

Nem volt időm mindent végig olvasni.

Kipróbáltam, csak tesztből pár hónapja. Csináltam egy saját rendszert dinamikus dns kiszolgálásra ( mert olcsóbb egy VPS ennyi címre mint előfizetni és érdekelt is ) és ki akartam próbálni, hogy Digi előfizetésen tudok-e üzemeltetni mail szervert, frissül-e elég gyorsan az MX-nek használ A rekord.

A 25-ös port befele is le van tiltva, így feleslegesen kínlódtam vele. Vagyis pontosabban mivel kifele tiltva van így kicsit egyoldalú a kommunikáció.

Kipróbáltam, csak tesztből pár hónapja. Csináltam egy saját rendszert dinamikus dns kiszolgálásra ( mert olcsóbb egy VPS ennyi címre mint előfizetni és érdekelt is ) és ki akartam próbálni, hogy Digi előfizetésen tudok-e üzemeltetni mail szervert, frissül-e elég gyorsan az MX-nek használ A rekord.

A 25-ös port befele is le van tiltva, így feleslegesen kínlódtam vele. Vagyis pontosabban mivel kifele tiltva van így kicsit egyoldalú a kommunikáció.

Igen, a 25-ös portot az otthoni internetszolgáltatók általában letiltják.
Abból amit írtál nem teljesen világos, hogy hogyan nézett ki a rendszer nálad. VPS-ről beszélsz, de akkor nem értem miért gond, ha az otthoni internetszolgáltatód tiltja a 25-ös portot?
Én VPS alatt szerverszolgáltatótol bérelt VPS-t értek, amelynek a 25-ös portját a szerverszolgáltató természetresen nem tiltja.

Ha az MX rekordod a VPS-re mutat, és ott lesz egy elsődleges queue-d, akkor nem feltétlenül kell az otthoni gépeden a 25-öst használnod, ugyanis a transport táblában portot is adhatsz meg, nem csak IP-t/dns nevet ;)
Úgyhogy szerintem a 25-ös porttal ne is törődj, a VPS-edet meg a 465-ösön érd el otthonról smarthostként (SMTP-SSL).
--
PtY - www.onlinedemo.hu

A DNS fut VPS-en, sok dinamikus frissítés kell és így olcsóbb mint a dyndns stb. előfizetés, meg már akkor másodlagos DNS-t is ad a többi cuccomnak.

Mivel a 25-ös port tiltva volt otthon így nem is keresgéltem tovább, nem ért annyi az ötlet, hogy időt fordítsak rá.
Pontosabban teljesen tiltva van és nem csak a kimenő új kapcsolatokra mert akkor befele még jöhetne.

Saját levelezés VPS-en van.

A DNS fut VPS-en, sok dinamikus frissítés kell és így olcsóbb mint a dyndns stb. előfizetés, meg már akkor másodlagos DNS-t is ad a többi cuccomnak.

Mivel a 25-ös port tiltva volt otthon így nem is keresgéltem tovább, nem ért annyi az ötlet, hogy időt fordítsak rá.
Pontosabban teljesen tiltva van és nem csak a kimenő új kapcsolatokra mert akkor befele még jöhetne.

Saját levelezés VPS-en van.

Ok, így már értem, kár hogy feladtad a dolgot. :)
Csak egyszerűen a VPS-en kialakítani mail szervert valóban egyszerűbb.

( lajos22 | 2013. 10. 30., sze – 20:55 )

Ennyire még én se vagyok paranoiás. Pedig én az SSL-ben sem bízok... :D

Amúgy levelezés otthoni neten felejtős lesz. nem csak a dinamikus IP tartomány miatt, hanem a portszűrés miatt. Diginél volt nekem régebben (kellett érte anyáznom, hogy megoldják) olyanom, hogy se ki, se be egy levél sem. Fix IP-s megoldásnál is volt ilyen gond néhány napig, de az előbb említett anyázás megoldotta.

Most UPC van, ennél is kellett anyázni mire használatba tudtam venni küldésre-fogadásra. (bár küldésre nem nagyon tudom, mert nem minden szerver fogadja el amit küldök)

Mindenképp a VPS-t használd levelezésre, de az adatokat tartsd az otthoni gépen és pl. NFS-sel csatold a VPS-re. Aszondod VPN-nel kapcsolódnál hozzá, ezzel meg is van oldva a szolgáltató port tiltás fétise...

--
openSUSE 12.2 x86_64

NFS remote felcsatolás veszélyes. Ha valami miatt megszakad a kapcsolat, az udp miatt a vps nem fogja észrevenni, és amikor írni akar rá, az összes folyamat beragad, a load meg felmegy 200 ezerre.
Nem hiszem, hogy ez a cél. A VPS-es gépet SMTP proxyként és smarthostként kell használni, ha a leveleknek az otthoni gépen van a helye.
A távoli mountos megoldás öngyilkosság.
--
PtY - www.onlinedemo.hu

Ez a SMTP proxy más portot használ, mint a mezei smtp szerver? mert ha igen, akkor az vázolt dolgok miatt kissé bonyolult lesz.. Esetleg átírható (esetleg) de nem biztos, hogy attól ott fog kommunikálni rendesen. Ilyennel még nem foglalkoztam, szóval nem tudom hogy működik.

Ez a megszakadástól load növekedés dolgot nem vettem észre. Most is fel van csatolva a gépemre NFS-en 2 hely, abból az egyik nem elérhető, és így a csatolási pontjára ha írok, akkor egyszerűen a helyi fájlrendszert használja. persze később nem synceli át, csak "eltűnik" az oda írt cucc.

--
openSUSE 12.2 x86_64

A gond az lehet, hogy a netszolgáltatók szeretik szűrni / tiltani az előfizető egyéb smtp forgalmát, és csak a saját szerverükre engedik. mivel ezzel a proxyval ugyanúgy szükséges az smtp portján kommunikálni, nem biztos, hogy menni fog. Szolgáltatóval megfutott körök után talán.

Bár, ha a forgalom egy VPN-en halad, akkor már nincs ezzel gond. Elvileg abba nem kötnek bele, hogy hova VPN-ezel...

--
openSUSE 12.2 x86_64

A gond az lehet, hogy a netszolgáltatók szeretik szűrni / tiltani az előfizető egyéb smtp forgalmát, és csak a saját szerverükre engedik. mivel ezzel a proxyval ugyanúgy szükséges az smtp portján kommunikálni, nem biztos, hogy menni fog. Szolgáltatóval megfutott körök után talán.

Bár, ha a forgalom egy VPN-en halad, akkor már nincs ezzel gond. Elvileg abba nem kötnek bele, hogy hova VPN-ezel...

De ha az otthoni szerver és a VPS között VPN kapcsolat lenne, akkor a VPS SMTP proxyként és smarthostként való használatának nem sok értelme lenne.
VPN kapcsolat esetén az otthoni szerver IP-je is ugyanaz lenne, mint VPS-é, így egy hoston két SMTP szerver lenne (egy SMTP proxy a VPS-en egy sima SMTP szerver meg az otthoni szerveren). Tehát az SMTP proxynak localhoston belül kéne a másik SMTP szerverrel kommunikálnia. Nem tudom, nekem ez nem tűnik túl jó ötletnek. Nem csináltam még ilyet, de azt gondolnám, hogy két SMTP szerver nem igazán férne meg egymás mellett egy hoston.

"mivel ezzel a proxyval ugyanúgy szükséges az smtp portján kommunikálni, nem biztos, hogy menni fog."
Csináltál már ilyet? Az alapján, hogy statikusan kijelented, hogy ugyanazon a porton kommunikál: nem.
Az smtp proxynál meg lehet mondani, hogy az otthoni gép melyik portjára továbbítsa a levelet, az otthoni gépen is meg lehet mondani, hogy a smarthost milyen porton legyen (amire amúgy is 465-öst használna SSL-en, amit senki sem tilt).
Úgyhogy ezt a kérdést szerintem tisztáztuk.
--
PtY - www.onlinedemo.hu

Akkor marad a kérdés, hogy ez a megoldás (smtp proxy és smarthost VPS-en telepítve és otthoni szerveren meg SMTP szerver) valóban biztonságosabb lenne-e, mintha minden VPS-en lenne telepítve?

Ha egy illetéktelen személy bejutna a VPS-re, akkor otthoni az szerveren tárolt levelekhez nem férne hozzá, vagy nem olyan könnyen férne hozzá, mitha minden a VPS-en lenne telepítve?

Írtam is, hogy nem (sosem volt rá szükségem, ezért nem foglalkoztam vele). és kérdeztem, hogy ugyanazt használja-e, a válasz az volt, hogy: igen. Sőt, pont te válaszoltál rá. (2-vel feljebb)

SSL-t SMTP-n nem használtam, de arról tudtam. és ha emlékeim nem csalnak, azért nem használtam, mert valamelyik levelezőm aszonta rá, hogy "fiam, te hülye vagy, hogy nem 25-s portot adsz nekem SMTP-re"...

--
openSUSE 12.2 x86_64

Nem, te konkrétan a proxy portjára kérdeztél, ami ugyanolyan postfix, mint bármi más. Csak azért proxy a neve, mert azt a feladatot látja el. És mint minden szolgáltatásnak, ezeknek is lehet állítani a portjait - ami azonban erősen nem ajánlott akkor, ha MX rekord mutat rá. Így a VPS-es gépen igen, 25-ös porton figyel a szolgéltatás. Az otthoni gépen viszont nem 25-ösre, hanem máshová kell tenni - ha amúgy is SSL lesz, akkor maradhat 465.
--
PtY - www.onlinedemo.hu

NFS remote felcsatolás veszélyes. Ha valami miatt megszakad a kapcsolat, az udp miatt a vps nem fogja észrevenni, és amikor írni akar rá, az összes folyamat beragad, a load meg felmegy 200 ezerre.

Akkor NFS, mint lehetséges megoldás kilőve.

A VPS-es gépet SMTP proxyként és smarthostként kell használni, ha a leveleknek az otthoni gépen van a helye.

Pontosan milyen programokat telepítenél VPS-re és mit az otthoni szerverre?
(webes felület is kéne a levelek eléréséhez)

Mindegy, hogy hol a webes felület.
A VPS-re én egy apache-on meg egy postfix-on kívül más publikus szolgáltatást nem tennék (ssh-t nyilván, de erős korlátozásokkal), maximum a dns-t, de az önmagában úgysem elég, mert kell még amellé egy másodlagos is, innentől kezdve az egész dns-es móka lehetne a szolgáltatónál. Az otthoni gép ip-jére meg valami ddns-t tennék, amire az eredeti dns-ben meg egy cname mutatna.
--
PtY - www.onlinedemo.hu

maximum a dns-t, de az önmagában úgysem elég, mert kell még amellé egy másodlagos is, innentől kezdve az egész dns-es móka lehetne a szolgáltatónál.

Ezt nem teljesen értem. Miért kéne a dns és miért kéne mellé egy másodlagos is?

ddns helyett nem lenne egyszerűbb ha az otthoni szerveren lenne egy szkript, ami figyeli az IP változást és ha az otthoni szerver IP-je változik akkor a szkript átírná a VPS /etc/hosts fájljában az otthoni szerverhez tartozó IP-t?

Aham, tehát jelszó nélkül összekulcsoznád a két gépet (a scriptnek senki sem fog begépelni semmit)?
Egyre inkább az jön le nálam, hogy:

- még nem csináltál ilyet
- nem vagy tisztában alapvető biztonsági kockázatokkal
- jól bevált, működő megoldások helyett garázsötletekkel operálsz

Ezek alapján akár VPN-nel, akár anélkül, pillanatok alatt fogják botnetbe kapcsolni nem csak a vps-es, de az otthoni gépedet is, amint bejutnak. Márpedig annál könnyebb lesz a dolguk, minél többet ötletelsz, és minél kevesebbet hallgatsz olyanok tanácsára, akik nem csak láttak már ilyen megoldásokat, de a mai napig csinálják is.

Szerk: dns és a /etc/hosts nem ugyanaz. Ha egyszer az egyikről beszélsz, egyszer a másikról, akkor nem tudjuk, hogy mit akarsz.
Ha az otthoni IP-d a vps /etc/hosts fájljában van meg, akkor hogyan fér hozzá a leveleihez valaki távolról? Csak weben?
Nem lesz senkinek imap/smtp?
--
PtY - www.onlinedemo.hu

Ennyire még én se vagyok paranoiás. Pedig én az SSL-ben sem bízok... :D
Csak szertném rendesen megcsinálni.
SSL-ben te miért nem bízól? SSL MITM támadás veszélye miatt?

levelezés otthoni neten felejtős lesz.
Igen ebben egyetértünk, eszembe sem jutott ilyen.
Nem is én hoztam fel a topicban.

Mindenképp a VPS-t használd levelezésre, de az adatokat tartsd az otthoni gépen és pl. NFS-sel csatold a VPS-re.
Bennem is felmerült, hogy az érzékeny adatokat NFS-el csatolnám VPS-hez.
De ha VPS kompromittálódik, akkor elméletileg hiába csatolom az érzékeny adatokat NFS-el hozzá, az adatokhoz hozzáférhet az aki a VPS-re bejutott úgyanúgy mintha az adatok a VPS-en lennének, vagy nem?

Egy kissé eltúloztam a SSL-ben nem bízom dolgot. Csak mindig feljön, hogy ember bocsájt ki tanúsítványt, és ember hibázhat / lehet rossz akaratú stb...

Ha már a VPS-re betörtek, akkor az otthoni cuccodra is betörnek, akármit használsz. Ha csak simán klónozzák az imageed, akkor az NFS-es tartalom nem látszik. Ami nem 100%, hogy pont NFS, lehet az bármi más hálózati fájlrendszer.

--
openSUSE 12.2 x86_64

Ezt írtam már fentebb valamerre, ha már betörnek a VPS-re, akkor onnan eljutnak a homeszerverhez is, azt se lesz nehezebb felzúzni. Akkor meg már úgyis mindegy, hogy miként volt megoldva a történet.

E gondolatmenetből szerintem az következne, hogy nem is lenne érdemes otthoni szerver és VPS kombinációjával szórakozni, mert nem lenne tőle biztonságosabb a rendszer. Vagy az otthoni szerverhez kéne fix IP-t vennem az otthoni internetszolgáltatótól, vagy pedig csak egy VPS-re kéne mindent feltelepíteni. Vagy nem? vagy mégis biztonságosabb lenne a rendszer VPS + otthoni szerver kombinációval?

( procika v | 2013. 10. 31., cs – 10:29 )

Ha már úgy is belementünk itt mindenbe ami téma kapcsán előjöhet akkor én is kérdeznék egyet.

Nekem is VPS-en sokminden, saját és ügyfél dolog is. Közel 10 VPS már.

Ugyebár biztonság és VPS kapcsán felmerül az is, hogy sokkal könnyebb hozzáférni mint egy fizikai szerverhez ( úgymond fizikai hozzáférés ). Fizikai szervert elérd és lásd a fájlrendszert be kell jutnod a terembe, vagy kijátszani a hosting céget és konzolhoz jutni. Tekintsünk el attól, hogy meg is lehet zúzni akár.

VPS esetében amennyiben titkosított partíción tárolom a dolgokat akkor az elérhető a host / kezelő szoftver felől? Bár már így leírva lehet hülyeség a kérdésem is mert OpenVZ esetén a webes felület még root jelszót is enged módosítani és ha fel van csatolva a titkosított partíció akkor mindegy. XEN, KVM esetében is hozzá lehet ilyen könnyen férni a VPS fájlrendszeréhez a szolgáltató felől?

VPS kapcsán felmerül az is, hogy sokkal könnyebb hozzáférni mint egy fizikai szerverhez
Ha a szerver szolgáltató nem segíti a hozzáférést egy harmadik fél számára, akkor szerintem VPS kb. ugyanolyan biztonságos, mint egy szolgáltatónál elhelyezett fizikai szerver. Ha meg szolgáltató segíti, vagy lehetővé teszi harmadik fél (pl. valamilyen felügyeleti szerv) számára a hozzáférést, akkor teljesen mindegy, hogy VPS-t, vagy fizikai szervert használsz. Ha rajtad kívül fizikailag más is hozzáfér a szerverhez, akkor az elméleti rizikófaktort jelent és itt egyáltalán nem arra gondolok, hogy majd az utcáról beront valaki a szerverszolgáltatóhoz erőszakkal, hogy akkor ő most megszerzi az adatokat a szerverről, sőt!

VPS esetében amennyiben titkosított partíción tárolom a dolgokat akkor az elérhető a host / kezelő szoftver felől?

Ha a VPS-en végzel titkosítást/dekódolást, akkor igen hozzáférhető, pl memórából, vagy más módon is hozzáférhetőek az adataid.
(Ha otthon titkosítod és azt felteszed VPS-re és csak otthoni gépeden dekodolod akkor természetesen nem, de ugye nem ez az általános eset.)

XEN, KVM esetében is hozzá lehet ilyen könnyen férni a VPS fájlrendszeréhez a szolgáltató felől?
Igen.

Sőt a nagy VPS szolgáltatók különféle egyéb backdoor megoldásokat is építenek be maguknak...

( n.balazs v | 2013. 10. 31., cs – 19:39 )

Végigolvastam a hozzászólásokat. Ha már ennyire paranoiás vagy és biztonságos kommunikációt akarsz, akkor miért nem a hagyományos, modemes kommunikációt választod? Az a 15-20 felhasználó betárcsáz hozzád, neked csak 1 modem kell a szerverbe. Így zárt a hálózat, internetre se kell kötnöd, használhatsz akármilyen titkosítást ebben a csatornában. Levelezésre elég az 56/33 Kb/s.


Végigolvastam a hozzászólásokat. Ha már ennyire paranoiás vagy és biztonságos kommunikációt akarsz, akkor miért nem a hagyományos, modemes kommunikációt választod? Az a 15-20 felhasználó betárcsáz hozzád, neked csak 1 modem kell a szerverbe. Így zárt a hálózat, internetre se kell kötnöd, használhatsz akármilyen titkosítást ebben a csatornában. Levelezésre elég az 56/33 Kb/s.

Olyan megoldás kéne, amelyet a hétköznapi felhasználók is egyszerüen tudnak használni (webes felületen elérhető levelezés stb...). Ha minden felhasználó elég felkészült lenne, akkor mindenki használhatna minden levelének a titkosításához 4096 bites pgp kulcsot és nem is kellett volna ezt a topicot elindítanom.

A modemes betárcsázást miért ne tudnák használni? Csak modem kell hozzá.
Mert átlagfelhasználónak bonyolult, körülményes.
Mert pl mostani PC-k, notebookok, tabletek, okostelefonok nem rendelkeznek modemmel.
Nem biztos, hogy rendelkezik a felhasználó vezetékes telefonvonallal.
Nagy távolságoknál drága lenne.
stb stb...

Viszont korábban azt írtad, hogy az összeg másodlagos, a biztonság az első. USB-s külső modemet szerezni pedig fillérekért lehet annak a 15-20 felhasználónak, akinek hozzá kell férnie a rendszerhez. Az külön jó, hogy átlag pc nem rendelkezik modemmel. Különben meg ha a felhasználót mindenféle eszközről fel akarod engedni a rendszerre, akkor megint a biztonságot áldozod fel. Persze te tudod...

Viszont korábban azt írtad, hogy az összeg másodlagos, a biztonság az első.
Igen, de ezt az email szerverre értettem és nem arra, hogy a 20 felhasználót is majd speciális hardver eszközökkel látom el...
Nem életképes az ötleted.
Inkább vállalnám, mid a 20 felhasználó betanítását GnuPG használatára :D

( PtY | 2013. 11. 01., p – 13:43 )

Nos, így végiggondolva két scenario-t választanék.

1. Vagy csak otthon lenne gépem fix IP-vel, és azt használnám (nem kell fs-t titkosítani, a vas nálam van mindig). Természetesen a külső behatások ellen a lehető legjobb módon védekezni kell. Hátrány a viszonylag kis garantált sávszélesség és az egyéb velejárók: áram, zaj, stb).

2. Vagy csak a colocationben lenne gépem, ám nem VPS, hanem fizikai gép (esetleg saját virtuális infrastruktúrával). Előny a nagyobb garantált sávszélesség, a folyamatos áramellátás és hűtés, hátrány a távolság, és az, hogy az érzékeny adatokat tartalmazó fájlrendszereket titkosítani kell.

Nem használnék önaláírt tanúsítványt, és a publikus webes oldalakon kívül (már ha ilyesmi szükséges) nem használnék olyan szolgáltatást, ami plaintext forgalmat csinál (a bejövő és kimenő levelekkel nem lehet mit kezdeni, mert bár van TLS lehetőség, ha a túloldal nem használja, úgyis plaintext lesz). A klienseken küldésre és fogadásra viszont csak SSL védett szolgáltatásokat engednék (SMTP-SSL, IMAP-SSL, POP3-SSL - a webmail pedig HTTPS).

Az egyszerre két gép használata dupla vesződség, dupla hibalehetőség, dupla kockázat.
A kevesebb néha több...
--
PtY - www.onlinedemo.hu