SSH forwardon keresztül érik el (ahogy egyébként én is úgy érem el jelenleg a klienseket, ha azokon kell valamit távolról tekernem), persze az ssh sem publikus porton van, gyártok nekik kulcsokat jelszóval amin be tudnak jönni majd localhoston kapcsolódnak a távoli asztalukkal. Persze itt is csak eleve erős jelszavú userek kapnak kulcsot egyáltalán, ebben az esetben biztos nem tudom elérni további plusz maceraként a fix ip-t, épp elég lesz nekik a kulcs+jelszó. :)
gyk mindkét esetben likat ütök a jelenleg 2 túzfal+proxy-val leválasztott belső infrastruktúrán, csak az egyik esetben kissé bonyolultabban. :)
Nekem van elképzelésem melyiket válasszam, de nem akarom befolyásolni a véleményeket.
Mit gondoltok? Egy vagy kettő?
- muszashi blogja
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
A VPN miert nem megoldas? SSH forwardot most is tudnanak csinalni, ha akarnanak.
--
Why did the chicken cross the road?
It was trying to get a signal on its iPhone 4.
- A hozzászóláshoz be kell jelentkezni
Nem tudnak, mert nincs kulcsuk. :) VPN azért maradt ki mert akkor arra ott az ssh forward.
Eddig csak én használtam az ssh-t a szerver elérésére vagy kliensek táv elérésére. Ezek irodista népek, a windózos gépüket kell elérjék a rajta lévő programokkal és roaming profiljukkal együtt.
- A hozzászóláshoz be kell jelentkezni
A vpn abban jobb, hogy sokkal user-frendlybb összehozni és használni, illetve ha később nem csak rdp-t akarsz így biztosítani, akkor már ott a kész infrastruktúra.
- A hozzászóláshoz be kell jelentkezni
Ha ezt a verziót választanám ez esetben megkapnának mindent "csomagban" kulcsot, előre gyártott távoli asztal parancsikont, stb.
Csak annyi a dolga, hogy feltelepítse otthon mondjuk a putty-ot és kattintson az általam adott ikonra.
Ennél kevesebből akkor sem ússza meg ha vpn klienst kellene használnia.
- A hozzászóláshoz be kell jelentkezni
De, megussza. Ugyanis putty eseteben meg ossze kell loni a plink-et is hogy felhuzza a proxy-t mielott az mstsc egyaltalan el tud indulni, aztan nyugos a plinket leloni utana.
A VPN annyiban kulturaltabb megoldas, hogy nem kell se putty se plink, se elore gyartott parancsikon hozza, beallit egy VPN kapcsolatot a halozati es megosztasi kozpontban, aztan nyit egy tavoli asztalt, csokolom.
Raadasul amint uj szolgaltatas kerul ki, neked frissiteni kell a pakkot, neki ujra letolteni, elfelejti, nem tudja hasznalni, bugos a putty, nem frissiti, szoval millio egy baja van. A VPN tisztabb, szarazabb, biztonsagosabb erzes tapasztalatom szerint.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. - A hozzászóláshoz be kell jelentkezni
Azért nem olyan bonyolult az a putty, ráadásul azt is lehet készen, beállítva adni...
A beállít egy VPN kapcsolatot a megosztási központban is sokaknál túl van azon a szinten amire képes...
Új szolgáltatás ezen felül a következő 10 évben nem valószínű...
A bugos putty na az valóban lehet probléma. Ez ellene szólhat a port forwardnak.
Ellenben a vpn egy új szolgáltatás ami eleve magában hordoz biztonsági kockázat többletet, hiszen az ssh úgy is megy azon elmehetne, tehát ilyen szempontból a vpn egy "felesleges plusz.
...éppen ezért nem is került be a választás közé, mivel szerintem a feladat ezen megoldásához nem szükséges, ha titkosított alagút kell akkor arra ott az ssh, ha meg nem akkor meg a csupasz rdp. A minél egyszerűbb rendszer híve vagyok.
...és igazából a kérdés lényege az, hogy mely esetben lehet kicsit bonyolultabb/ismeretlenebb feladat az otthoni gépen esetlegesen lévő károkozóknak felhasználni, hogy az usernek elérése van a rendszerbe. ..és itt mindkettő mellett van pro és kontra, de most épp már a másik felé hajlok, mint eddig hajoltam :)
- A hozzászóláshoz be kell jelentkezni
Ebben az esetben a VPN az egyszerubb rendszer, trust me. Foleg ha a usereid olyan szinten vannak, ahogy mondod, valojaban semmi szukseguk nincsen ssh szolgaltatasra, feleslegesen adsz olyan jogot nekik, amit sosem fognak hasznalni arra, amire valo, ellenben beviszel egy plusz biztonsagi problemat a rendszerbe (mi garantalja, hogy masra az az SSH kapcsolat nem hasznalhato/nem fogjak hasznalni?)
Azt latni kell mindenkepp, hogy az,hogy az ssh-val lehet portforwardot csinalni, nem ekvivalens azzal, hogy az ssh erre valo. A "keszen beallitva adni" dolog reszedrol eleg sok melo, ha barmi valtozik (pl a szerver publikus kulcsa, az ssh portja, a putty parameterezese), akkor uj pakkot kell kiadni, azt az userekkel ki kell forcolni hogy feltegyek, stb. tehat maintenance-val is jar.
Akinek egy VPN beallitasa problemas, annak egy putty telepitese is az. Raadasul a VPN-t is lehet elore beallitva adni, egy INI fajlt kell csak a megfelelo helyre feltelepiteni ami sokkal egyszerubb egy puttyos konfig osszerakasanal, szoval az eddigi erveid erost megkerdojelezhetoek...
Tenyleg no offense, de szerintem a VPN mindket fel szamara egyszerubb es biztonsagosabb megoldas, plusz a te kezedbe tobb lehetoseget ad, tobb szabadsagot, es a kesobbiekben akar tobb szolgaltatas is elerhetove teheto a VPN-en keresztul, amit SSH-val nem, vagy csak korulmenyesen tudsz megoldani.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. - A hozzászóláshoz be kell jelentkezni
"Nem tudnak, mert nincs kulcsuk."
Kifele gond nelkul mukodik szerintem.
Elozo munkahelyemen legalabbis igy csinaltam, es amig nem volt beallitva a VPN, addig a mostanin is. Bentrol inditottam egy plinket/puttyot a tunnellel (-R5901:localhost:5901), otthonrol meg visszamentem ezen keresztul VNC-vel (vagy rdesktoppal).
A plinket bele kell tenni egy vegtelen ciklusba, hogy adott ido utan (sleep xy) ha szakad, kapcsolodjon vissza. Na meg otthon csinaltam egy kulon usert, ami kapott egy passphrase nelkuli kulcsot, es a default shelljet atallitottam egy olyan 3 soros programra, ami nem lep ki soha, csak folyamatosan sleepel (szoval akarmeddig nyitva tartja a kapcsolatot). Ja, es az otthoni sshd-t kitettem a https portra, azt a legtobb helyen kiengedik, szoval akarhonnan be tudok lepni a gepemre.
Azert a VPN pont arra valo (tavolrol is be tudjanak jutni), szoval erdemes lenne meggondolni a hasznalatat. Egysegsugaru usereknek mindenkepp.
Plusz ha valami belso serverre tavolrol belepve WoL-al el tudja inditani a gepet, az meg kenyelmesebb. Ezt is meg lehet oldani ssh-n keresztul, de macerasabb.
--
Why did the chicken cross the road?
It was trying to get a signal on its iPhone 4.
- A hozzászóláshoz be kell jelentkezni
Na jó, így persze megy, de ezek könyvelő és könyvvizsgáló népek, ők ilyet nem csinálnak. :)
Így nálunk is menne, mert a squid-on ezt át lehet nyomni lásd 443 .:)
- A hozzászóláshoz be kell jelentkezni
+1 a VPN-re
attól még maradhat neked az ssh mellette
- A hozzászóláshoz be kell jelentkezni
Rdp-t nem ismerve: titkosított protokoll? Ha nem, akkor szerintem ez nem kérdés.
VPN okkal maradt ki a felsorolásból, ugye?
- A hozzászóláshoz be kell jelentkezni
Igen az.
Azért maradt ki, mert esetünkben semmivel sem nyújt többet, mint a most is létező ssh-n adni hozzáférést az usereknek is.
- A hozzászóláshoz be kell jelentkezni
Szép, hogy egyszerűen akarod megoldani, de a jogosultságok kezelésével azért gondok lehetnek, nem beszélve arról, hogy azt is meg kell oldanod, hogy az átjárón csak és kizárólag portforwardot tudjon elkövetni a felhasználód. Abból a szempontból mondjuk jó a megközelítés, hogy nincs lehetőség összeroutolni a külvilágot a távoli user gépén keresztül a belső hálózatotokkal, de ezt megfelelően összerakott csomagszűréssel és kliensre letolt routing beállításokal azért jól lehet kezelni pl. openvpn esetén is.
- A hozzászóláshoz be kell jelentkezni
Egyertelmuen VPN. Es RDP-re csak helyi halozatbol (vpn) csatlakozhassanak a felhasznalok.
- A hozzászóláshoz be kell jelentkezni
+1 Annyival megfejelve, hogy a VPN-bol csak a rdp-t engedelyeznem és mindenki sajat VPN-n belei IP-t kapna.
Talan ez annyival jobb mint az SSH forward, hogy ha valaki megmutatja neki,hogy egy masik portot hogyan tud forwardolni, akkor azt o maga is meg tudja csinalni. Mig a tuzfal szabaly nem tudja modositani.
- A hozzászóláshoz be kell jelentkezni
+1
Illetve ha van központi hitelesítés, azt tudod használni a vpn-hez is, és csak azokat átengedni a vpn hálózatáról a belső hálózatra rdp-n, akiknek ehhez van megfelelő role-juk. Nem tudom ilyet ssh-val meg lehet-e csinálni...
- A hozzászóláshoz be kell jelentkezni
Az ssh tud pam-ot használni, a pam mögé meg gyakorlatilag mindenhez pakolható központosított backend (ldap, ipa, AD, satöbbi).
- A hozzászóláshoz be kell jelentkezni
Addig rendben van, hogy az authentication megy, engem az authorization része érdekel. Vagyis az, hogy már a port forward se menjen, ha a usernek nincs joga hozzá.
- A hozzászóláshoz be kell jelentkezni
Az "account"-ot is tudja bárhonnan venni, és oda be lehet reszelni, hogy csak akkor "success", ha van neki olyanja, hogy portforward jog. A gond serintem ott van, hogy az sshd ilyen szinten (portforward versus shell) nem különbözteti meg a dolgokat - ez mondjuk azzal megkerülhető, hogy a .bashrc-jébe/profile-jába az adott usernek egy szép egészséges exit kerül, semmi más.
Vagy - mivel kulcsos auth van csak - az authorized_keys-ben lehet, hogy megoldható a portforward-only kulcs felvétele, de ennek utána kéne olvasni.
- A hozzászóláshoz be kell jelentkezni
Csináltam már ilyet vagy 6 éve egyszer, az megoldható hogy ne kapjon shelt és csak a port forward menjen.
- A hozzászóláshoz be kell jelentkezni
Jelen esetben pont annak kellene mennie és másnak nem.
A shel letiltható a port forward meg megy ha van kulcsa és nem megy ha nincs kulcsa.
- A hozzászóláshoz be kell jelentkezni
+1
"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."
- A hozzászóláshoz be kell jelentkezni
Teljesen mindegy, ha az otthoni szedett-vedett gepukrol bejutnak a tuzfalon belulre, te mar igy-is-ugy-is vesztettel.
- A hozzászóláshoz be kell jelentkezni
Tudom :(
Tan ez egyik modszerrel mehezebben mukodnek a gepeiken levo karokozok...
- A hozzászóláshoz be kell jelentkezni
Egy darab terminálszerverre eshessenek be (akár vpn, akár portforward), és onnan, egy másik szűrésen át, ha van rá joguk, érjék el a saját "benti" gépüket. Ha nincs, akkor a "közös" ts-en van lehetőségük a legfontosabb dolgokat megnézni/elérni.
- A hozzászóláshoz be kell jelentkezni
A probléma arról szól, hogy pont a saját benti gépüket kell elérniük, mint közös olyan nem létezik. Vannak persze közös megosztások, de a faladat az hogy a saját profilja jöjjön be a saját maga által használt programokkal és mindennel. Ez mivel roamin profil van, simán megoldható. A legtöbb program a hálózati saját meghajtójára van telepítve, tehát csak akkor működik ha látja a szervert és pont úgy mintha fizikai gépnél ülne. Tehát a júzer végül is mindenhez hozzá fér, max bizonyos dolgokhoz (közös könyvtárak) nem teljes joggal.
Ilyentén sok értelme nincs még egy réteget tenni az igazi benti háló és terminál szerver közé, mivel gyakorlatilag ahhoz hogy dolgozni tudjon a helyi szerver összes szolgáltatását el kell tudnia érni, tehát pl egy tűzfallal leválasztva minden használható portot úgy is nyitva kell tartani.
Egyébként az általad írt koncepcióhoz hasonlóan megy ott egy terminál szerver már vagy 8 éve (win2k3) de az pontosan a belső és külső hálóról is le van választva, tehát bentről is és kintről is csak rdp-n érik el. Ott viszont önállóan működő program van, ami csak ott fut, ezért tehettem meg hogy leválasztottam a belső irányból is. Itt viszont mindent használniuk kell, pont úgy mintha bent lennének.
...egyébként egyre inkább hajlok a sima rdp-re, de csak fix ip címekről.
- A hozzászóláshoz be kell jelentkezni
A fix ip-t ki fogja fizetni a kollégáknak? Mert az otthonról nincs ingyen. Natúr pucér rdp-t én semmiképp nem engednék be, minimum egy plusz réteget/csövet húznék köré, ami egy plusz védelmet jelent. (Ha pucér rdp megy, az direktben támadható. Ha vpn vagy valamilyen más ssl-csőbe van húzva, akkor az rdp támadásához előbb azon a "csövön" kell átjutni a támadónak, és utána tudja az rdp-t támadni.
- A hozzászóláshoz be kell jelentkezni
A kolléga. Szerintem.
Alapvetően ez egy bejárós munkahely, a tulaj is azt szereti ha bejárnak, meg mint látható minden a belső infrastruktúrához kötött. Dolgozói oldalról merült fel, hogy szeretne inkább néha távolról dolgozni. Ebben az esetben szerintem szabható feltételnek, hogy ok lehet távolról, de az a feltétele hogy fix ip-d legyen.
Üzemeltetés oldalról legalábbis én örülnék egy ilyen plusz dolognak, hogy csak konkrét ip-ket engedjek át a tűzfalon. ...oszt ha nem lehet keresztülverni, hát nem lehet.
(Én hasonló esetben biztos inkább kicsenetnék 3 rugót a fix ip-re csak ne kelljen bejárni. :) )
- A hozzászóláshoz be kell jelentkezni
A fix IP, mint feltétel, komolytalan. Ráadásul az csak egy végpontot biztosítana, nem sokat ér. És amúgy se bízz az IP címben, többet ér egy nyílt kulcsú azonosítás.
Ave, Saabi.
- A hozzászóláshoz be kell jelentkezni
Nem az azonosításra használható természetesen, csak egy egyszerű előszűrő azon kérésekkel amik biztosan nem legálisak. Ezek már át sem jutnak a tűzfalon. Oszt ami átjutott azt lehet tovább masszírozni.
...bár egyébként míg másoknál vastagon tömve szokott lenni az auth log pl az ssh próbálkozásoknál, itt a 10 év alatt még egy sem volt benne, szóval a magas porton eldugott dolgoknak már önmagában is elég jó előszűrése van. :)-érts valahol bőven 30000 fölött szoktam általam kényesnek ítélt dolgokat kitenni, lásd ssh vagy pl az egroupware webes oldala is fent fut a fenében.
- A hozzászóláshoz be kell jelentkezni
Fix IP-t csak vezetékes szolgáltatásnál lehet kikunyizni. Ha csak mobilnetje van, akkor bukta. Ha épp elbacca a szolgáltató a DHCP-szerverben, és más címet kap, akkor ugyan verheti a szolgáltatója fejét, de belépni nem fog tudni. Értelme nulla, sz0p@sfaktort meg kellőképp megnöveli.
Én inkább abba az irányba mennék, hogy a vpn, vagy ssh-portforward _mikor_ működjön? Ha épp bent van a dolgozó a munkahelyén, akkor nem kell, ha szabin van, akkor sem kell, etc. Azaz legyen bent egy felület, amin igényel tól-ig időszakra távoli hozzáférést, a főnöke rábök, hogy mehet/nem mehet, és annak megfelelően "éled fel" és kerül lekapcsolásra a távoli hozzáférés. A munkájuk ugyanis nem olyan, aminél a 7x24 elérés szükséges. Ez egy auditon kellemes plusz pontokat hozna a távoli elérésekkel kapcsolatban.
- A hozzászóláshoz be kell jelentkezni
A biztonsági események alakulását ne a múltbeli események alapján prognosztizáld. Az, hogy eddig nem volt, az pontosan annyit jelent, hogy eddig még nem volt. Egy betűvel sem többet. Azzal, hogy fix ip-t szeretnél/javasolsz, a dolgozók (akikért, és nem akik ellen dolgozol!) nemszeretetét fogod maximum kivívni.
Keresztkérdés: A te távoli hozzáférésed is fix ip-re van szűrve, ugye? Ha ugyanis az a szabály, hogy fix ip, akkor az a szabály. Rád is. Csak neked mondjuk 7x24, a többieknek meg előzetes igény alapján megadott intervallumban él a távoli hozzáférés.
- A hozzászóláshoz be kell jelentkezni
> Az, hogy eddig nem volt, az pontosan annyit
> jelent, hogy eddig még nem volt. Egy
> betűvel sem többet.
Ehh valoszinusegszamitas...
Sose ertettem igazan, hogyha valaki a piros-fekete-re fogad rulettnel, minden vesztesnel duplazza a tetet, es sorozatban mar 30x vesztett, akkor 31-re miert ne lehetne nagyobb esely, tudva, hogy elotte zsinorban 30x vesztett.
Marmint ertem, meg minden, csak megse fogadhatom el:)
Mondom ezt ugy, hogy egyszer nyuszi voltam feltenni inget-gattyat a 9. menetnel:)
Pedig ott mar hatarozottan nagy a tet, meg messze (1000+ km) is voltam otthonrol, foleg stoppal.
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
- A hozzászóláshoz be kell jelentkezni
Mert egy játék kimenete független az előzőektől. Vagy úgy is mondhatnám, hogy ezt a játékot a geometriai eloszlás modellezi, az meg örökifjú. Nyilván a statisztikának ki kell jönnie, ha x esélyed van nyerni, akkor n játékból n*x esetben nyerni fogsz, csak azt nem tudod megmondani előre, hogy mikor. Többek között ez a baj a duplázós stratégiával, nagyon kevés játék alatt olyan mértékű lesz a tét, hogy nem tudod megtenni.
- A hozzászóláshoz be kell jelentkezni
hát ja :)
Ellenben ha csillió gép a szabványos porton nyomja pl az ssh-t és néhány eldugva a fenébe és láthatóan a technika valóban működik, mert a 22-es porton futóknak megabájtos logjai vannak az ötvenezervalahol futóban meg semmi -elmúlt x év gyakorlati tapasztalata -, akkor mondhatjuk a dolog működik és valószínűbb hogy a 22-es porton működőket fogja a jövőben is tosztatás érni ellentéteben az ötvenezervalahol futókkal.
- A hozzászóláshoz be kell jelentkezni
Egészen addig amíg valaki nem tol egy full portscant az adott ip-re, majd ráküldi a zombihálózatát az ssh tényleges portjára.
- A hozzászóláshoz be kell jelentkezni
Épp most néztem a routeremen: számomra ismeretlen okból 40-50ezres, elsősorban UDP portok tízezer fölötti darabszámban szerepelnek az eldobott csomagok között, míg 80, 443, 22, 23 valahol ezer körül. Persze ebből elég egy is, ha betalál egy nyitott porton. És a portscan-ek is viszonylag rendszeresnek tűnnek.
- A hozzászóláshoz be kell jelentkezni
Valamit nagyon keversz. Azaz, sejtesem szerint rosszkor (es rosszul is) alkalmazol egy aranyszabalyt.
Most nem az a pelda van, hogy van egy poisson eloszlasod egy lambda parameterrel, szamold ki a valoszinuseget. Hanem az, hogy van egy poisson eloszlasod, es egy csomo meresi adatod, es szamold ki a valoszinuseget.
Itt viszont mast fogsz kapni a kovetkezo nap betoresi valoszinusegere*, ha azt teszed fel, hogy a betoresek poisson eloszlast kovetnek, es evek ota soha nem tortek be, es mast fogsz kapni, ha azt teszed fel, hogy a betoresek poisson eloszlast kovetnek, es nagy atlagban napi ketszer bejarnak.
Nem mindig mond ellen a valszam a logikanak. Neha annak is lehet am hinni :P
*a valoszinuseg most nem ertelmezheto. De sebaj.
- A hozzászóláshoz be kell jelentkezni
Én kimondottan a rulettes példára válaszoltam, amit leírsz azzal ettől függetlenül egyetértek.
- A hozzászóláshoz be kell jelentkezni
fixip helyett nem sokkal kevesbe biztonsagosabb egy dyndns-es valami.
Vagy egy egyszeru weboldal, ahol jelszo utan az eppen aktualis ip cimet hozzaadja 1 orara a jogosult ip-k koze.
Ebben az esetben a fixip vs. egyszeru weboldal-t az kulonbozteti meg egymastol, hogy az egyiknel a szolgaltato allitja, hogy mindig ugyanaz van a vegpont mogott, a masikrol meg maga a felhasznalo allitja.
De szerintem tok mindegy milyen furfangos tunnelt alakitasz ki, hogyha meg van engedve, hogy fajlt masoljon a gepere, es el tudja inditani:)
Igy, innen a partvonalrol ennyi jut eszembe:)
ui: Ismerek olyan ceget, ahol maguktol megcsinaltak, ok teamviewert hasznalnak.
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
- A hozzászóláshoz be kell jelentkezni
Hát egyébként igen, gyakorlatilag csak kozmetika azok után hogy az otthoni gépéről bármit átpakolhat a cégesre :)
Teamviewert sosem használtam, az kimegy proxy-n keresztül? ...mondjuk a júzereim nem az a kategória akik ilyeneket tudnának használni. :)
- A hozzászóláshoz be kell jelentkezni
Akkor otthonra kapjanak egy virtuális gépet, mely leginkább csak VPN-re és RDP-re alkalmas. Mindezt lehetne pl. Virtualboxban futtatni. Egy ilyen gépnek nem lenne nagy erőforrásigénye, egy átlagos otthoni számítógép is futtathatná - bár fogalmam sincs, milyen egy átlagos otthoni számítógép, lehet, hogy mégsem.
Ave, Saabi.
- A hozzászóláshoz be kell jelentkezni
Szerintem a fajlok mozgatasa lesz a legnagyobb problema.
Virtualis gep es hoszt kozott hogyan? Shared directory?
Szerintem ha valamelyik rajon, hogy egy mezei teamviewer alkalmas ra, akkor onnantol kezdve a rendszergazda lesz az akadalyozo tenyezo, aki utjaban all minden jo es kenyelmes megoldasnak.
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
- A hozzászóláshoz be kell jelentkezni
Teamwiever? Ki garantálja, hogy nem mennek a rajta átfolyó adatok harmadik helyre? Mondjuk rögtön a NAV-ba. :)
Biztos nem használnék külső eszközt olyan helyen ahol kb 1 forintnál több a tét. :)
- A hozzászóláshoz be kell jelentkezni
Shared directory, external disk, vagy egyszerűen nincs file mozgatás a host és a guest között.
Ave, Saabi.
- A hozzászóláshoz be kell jelentkezni
Es ez a pelda gyonyoruen illusztralja,
miert terjed manapsag a cloud gozerovel es
tarol le mindent a szamitastechnikaban.
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
- A hozzászóláshoz be kell jelentkezni
...aminek annyira nem örülök :D:P
De vannak amit nem lehet ill nem olyan egyszerű felhősíteni, pl pont az ilyen komplex sok programból összeálló rendszerek (vannak még DOS-os programkáink is és lesznek is kb örökké)ahol szükséges a személyes (még ha távolról is, de személyre szabott) támogatás.
- A hozzászóláshoz be kell jelentkezni