[Techinfo] pfsense alapozó - infók

2021. Jan. 5., K, 08:38:36 CET

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 <venczelj69 at 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 <czirokf at gmail.com <mailto:czirokf at 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 at 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/

--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: <http://lista.sulinet.hu/pipermail/techinfo/attachments/20210105/5ffc954f/attachment.html>