Szia, Abszolút nem vagyok önzetlen, igenis önző célok vezérelnek! Elsősorban információ és adatbiztonsággal foglalkozom időm jelentős részében, ez nem a munkám, ez a hivatásom. Azt gondolom Ti vagytok az a közösség aki a legtöbbet teheti annak érdekében, hogy Magyarország ne a “botnetek országa” legyen. -hát ez a motivációm, egy önző féreg vagyok!
Én is sokat agyaltam rajta csak elpróbálni nem tudtam még, így azért nem írtam meg, DE kb ez van a fejemben: 1) amit használsz gateway group-ot azt kiegészíted egy plusz tier-rel, aminek a prioritása a legalacsonyabb. - így arra csak akkor fog a forgalom menni, ha az élő net-jeid leszakadtak. - ez az IP bármi lehet, lényeg, hogy “mindig” válaszoljon (ki kell próbálni megeszi-e a link local címet a tűzfal mint GW, ha igen akkor az a legjobb) 2) amikor a tűzfal arra route-olja a csomagot, mert minden más GW leszakadt akkor: - csinálsz egy NAT-ot ami módosítja a csomag DST address-ét egy http szerver címére amin a hibalap van 3) a http szerver pedig minden web kérésre kiadja a hiba lapot —> ezzel a https forgalmakkal lesz gondod, mivel mind tanúsítvány hibád fog dobni Lehetséges megoldás: 1) egy http-t beszélő proxy-t felhúzol ami képes az SNI-t módosítani és a módosított SNI-vel proxy-zod át a forgalmat a hibalapra. - itt nem kell nagy dologra gondolni, egy apache vagy egy nginx is megcsinálja - ennek kerékkötője lesz a TLS1.3 amivel ott már ESNI van. - bár egy jó idegi (2-3 évig) biztosan lehet TLS protokoll downgrade-et csinálni. - VAGY a http protokollt downgrade-eled 1.0-ra, ott nincs SNI 2) Windows-okra terítesz GPO-vel egy root CA-t és ezzel a CA-val aláírt tanúsítványokat állítasz ki a user-nek, ha nem mennek a GW-k, így a redirect-elt forgalom nem lesz cert hibás. Üdv, Feri > On 2021. Jan 5., at 6:40, József Venczel <venczel...@gmail.com> wrote: > > Szia! > > Kevés ennyire önzetlen ember van, aki hajlandó INGYEN megosztani a > szaktudását! > > Magam részéről befoglalom a neved imáimba és mindig hálával gondolok majd > rád, mert több dolgot is megtanultam az előadásodból. > > Az első részt, ami tele volt elmélettel, kár lenne kukázni, mert szerintem az > teljesen rendben van, legalább is úgy emlékszem. > A többi részen meg csak annyi látszik - ha nem tévedek -, hogy először > csináltál ilyet és zavarban voltál kicsit. > Láttunk viszont hibakeresést, amit amúgy is megígértél ;o) > Ahogy érzed, teljesen jó lesz úgy, ahogyan írtad. Szerintem az eredeti sem > ciki (legfeljebb Neked, mert többet vársz önmagadtól). > > Köszönöm! > > Üdvözlettel, > Venczel József > > ps: Az előadáson kérdeztem a felhasználóknak szóló hibajelző weblap > megjelenítését. A tanfolyam hatására, még aznap este megnéztem megint a > captive portálos megoldásomat, amit egy másik szálban már ecseteltem, illetve > segítséget kértem hozzá. > Ez volt az eredeti felvetés: > > "Néhány napja az jutott eszembe, hogy kiegészítem egy új funkcióval a > hálózatot. Mégpedig úgy, hogy ha nincs a sulinak internet elérése, mint pl. > idén is kb. egy fél óráig nem volt az érettségi idején, akkor a > munkaállomásokon a böngészőben jelenjen meg egy helyi hálózaton lévő weblap, > ami arról tájékoztatja a felhasználókat, hogy megszakadt az intézményi > internet kapcsolat., de a helyi szolgáltatások továbbra is működnek. > > Ezt úgy gondoltam kivitelezni, hogy a tűzfalam Proxmox szerveren fut egy > virtuális gépben. OPNSense. Két internetes kapcsolattal rendelkezik, ha az > egyik megszakad, átvált a másikra (failover). Arra gondoltam, adok ennek a > virtuális gépnek még egy host only hálózati kártyát és csinálok még egy > virtuális gépet, aminek szintén adok egy host only hálókártyát és telepítek > erre is egy OPNSense-t. A két gépet összekonfigolom úgy, hogy az igazi > tűzfalnak ez legyen a harmadik gateway-e és ha már egyik internet kapcsolat > sem él, akkor automatikusan átkerül a labda erre a host only hálózaton > kommunikáló másik OPNSense tűzfalra, aminek egyetlen dolga, hogy valahogyan > megjelenítse ezt a hibajelző weblapot. > Készítettem egy Captive Portal-t, aminek lecseréltem a html kódját erre a > hibajelentő lapra. Ha a kliens gépen a böngészőbe HTTP-vel kommunikáló weblap > van betöltve, akkor szépen működik is a dolog, de HTTPS esetében nem akar > összejönni. Átbújtam már a netet és mindenhol azt írják, hogy a captive > portál nem jó barátja a HTTPS-nek. Igen ám, de manapság már mindenki > HTTPS-sel kommunikál." > > A captive portal beállításainál van egy olyan lehetőség, hogy "SSL > certificate". Ha itt beállítok egy tanúsítványt, akkor működik HTTPS-re is. > Csak ilyenkor nem egyből a captive portal-ra visz, hanem megjelenik a > szokásos figyelmeztetés, hogy nem megbízható tanúsítvány, stb. Ha a speciális > gombbal továbbmegyek, csak akkor jön be a captive portal (HTTP esetén eddig > is simán működött). > Arra gondoltam, hogy beszerzek hozzá egy Let's Encrypt tanúsítványt és úgy > simán fog működni. Nézegettem az OPNSense Let's Encrypt plug-in-jét, nem > tűnik bonyolult dolognak. > Viszont itt jön egy másik probléma: ilyen tanúsítványt nem lehet privát ip > címen lévő szerverre kérni. > Most nincs időm foglalkozni többet vele, mert más problémákon kell > foglalkoznom, de majd megírom a listára mire jutottam... > > Ferenc Czirok <czir...@gmail.com <mailto:czir...@gmail.com>> ezt írta > (időpont: 2021. jan. 4., H, 23:05): > Sziasztok, > > Nos, először is elnézést, elég csúnyán beszaladtam az erdőbe. > Utólag megnézve a video-t, hát ciki. > _______________________________________________ > Techinfo mailing list > Techinfo@lista.sulinet.hu > Fel- és leiratkozás: http://lista.sulinet.hu/cgi-bin/mailman/listinfo/techinfo > Illemtan: http://www.szag.hu/illemtan.html > Ügyfélszolgálat FAQ: http://sulinet.niif.hu/
_______________________________________________ Techinfo mailing list Techinfo@lista.sulinet.hu Fel- és leiratkozás: http://lista.sulinet.hu/cgi-bin/mailman/listinfo/techinfo Illemtan: http://www.szag.hu/illemtan.html Ügyfélszolgálat FAQ: http://sulinet.niif.hu/
