Kion povas ankoraŭ atingi kompromitita retpordego?
Retpordego limigas, kion malfermas vizitanto, ne kion povas atingi kompromitita gastiganto. Du revizioj, aŭtoritata tabelo kaj komandoj por mezuri la atingon.
Supozu, ke la gastiganto de la pordego estas kompromitita dum ĝia atestilo ankoraŭ validas. Ĉiu regulo, kiu regis, kiujn paĝojn vizitanto povas peti, restas en valido, kaj neniu el tiuj reguloj limigas la konekton, kiun la atakanto nun malfermas de tiu gastiganto al la datumbaza subreto. Ĝuste tiu manko estas kial nurreta enirpunkto ne estas la sama aserto kiel segmentita reto. La du asertoj postulas apartajn reviziojn, el malsamaj komencpunktoj, antaŭ ol eblas honeste fari iun el ili.
Du asertoj, kaj nur unu el ili komenciĝas ĉe la vizitanto
La unua aserto temas pri persono: vizitanto kun retumilo kaj valida seanco povas malfermi unu aplikaĵon kaj nenion alian. Nurreta enirpunkto bone respondas tiun aserton, ĉar la vizitanto ricevas paĝon anstataŭ itineron. Tiu respondo indas, kaj ĝi ankaŭ estas la sola aserto, kiun plej multaj diagramoj registras.
La dua aserto temas pri komponanto: oni supozas, ke la pordego, aŭ la aplikaĵa procezo malantaŭ ĝi, estas sub la regado de iu alia. El tiu supozo la demando ŝanĝiĝas de kiuj URL-oj estas permesitaj al kiujn celojn kaj identecojn la procezo ankoraŭ povas atingi.
La du asertoj havas malsamajn posedantojn, produktas malsamajn pruvojn kaj malsukcesas sendepende. Identeca teamo povas pruvi la unuan per seanca testo; la dua bezonas retan politikon, revizion de la serva konto kaj gastigantajn kontrolojn. Dezajno, kiu registras nur la duonon de la vizitanto, aspektas kompleta sur revizia lumbildo kaj maldensa dum incidento, ĉar la kontroloj, kiuj gravas post kompromito, neniam estis en la amplekso. Nomu, kiun aserton ĉiu kontrolo subtenas, alie unu pordega regulo estos kreditita al ambaŭ.
Pritraktita elspeza servo, kaj la du manieroj, kiel ĝi perdiĝas
Prenu elspezan servon: publika pordego ĉe 10.60.4.10 aŭtentikigas oficistojn kaj plusendas aprobitajn petojn al aplikaĵa aŭskultanto sur pordo 8443, kaj tiu aplikaĵo atingas unu PostgreSQL-aŭskultanton ĉe 10.60.4.20:5432 kiel la rolo expenses_app. Oficistoj ne celas ricevi ĝeneralan internan aliron. Dum normala funkciado la dezajno ja liveras aplikaĵ-specifan eniron sen publikigi la datumbazan aŭskultanton ie ajn. La adresoj gravas, ĉar ĉiu posta kontrolo en ĉi tiu artikolo nomas ilin.
Nun forigu la pordegon el la fidinda aro. Kiujn celojn povas atingi 10.60.4.10, kiam ĝia procezo apartenas al atakanto? La URL-filtro, kiu limigis vizitantojn, diras nenion pri konekto, kiun la pordega gastiganto malfermas al la datumbaza subreto.
Forigu anstataŭe la aplikaĵan procezon, kaj la aŭtoritato ŝanĝas formon: la rolo expenses_app, la servoj, kiujn tiu servilo povas atingi, kaj la dosieroj, kiujn tiu konto povas legi. En ambaŭ kazoj la antaŭa pordo povas resti nurreta dum la malantaŭa limo mankas. La etikedo sur la antaŭa pordo do ne estas respondo al iu el la du demandoj.
Mapu la aŭtoritaton, kiun ĉiu partio efektive tenas
Kontrakto skribita kiel intencitaj permesoj emas ripeti la dezajnon al vi. Skribu ĝin kiel tenata aŭtoritato, la kontrolo, kiu refutas la troon, kaj la posedanto de tiu kontrolo, kaj ĉiu vico fariĝas testebla. Ĉi tiu tabelo estas propono por la supra ekzemplo, ne produkta aserto:
| Component | Authority it actually holds | Check that proves the denial | Owner of the check |
|---|---|---|---|
| Identity provider | Issues assertions and session cookies, and holds no network path of its own | A request to the application URL without a session is redirected to the login page | Identity team |
| Public gateway host | TCP reachability to whatever its routing table and egress rules permit | An egress rule drops 10.60.4.20:5432 and the probe reports the port filtered | Network platform team |
| Application role | SQL privileges granted to expenses_app inside the expenses database | A privilege query shows no ownership or create right on any other schema | Application team |
| Database listener | Accepts connections only from the source ranges named in its host-based rules | A connection from an unlisted address is refused before authentication | Database administrator |
| Management path | Administrative access reserved for patching, monitoring and recovery | A staff workstation cannot reach the administrative port or jump through it | Platform owner |
Posedo sekvas la aŭtoritaton. La identeca teamo posedas asertojn, la retplatforma teamo posedas vojojn, la aplikaĵa teamo posedas la datumbazan rolon, la datumbaza administranto posedas la aŭskultanton kaj ĝiajn gastigant-bazitajn regulojn, kaj la platforma posedanto posedas la administran ebenon. Rifuzo sen posedanto estas frazo en dokumento, ne kontrolo.
La divido ankaŭ malhelpas duoblan kalkuladon. Porda limigo ne povas esprimi tabelan privilegion, kaj datumbaza rolo ne povas malhelpi gastiganton malfermi ingon al nerilata subreto.
Listigu, kion la pordego povas atingi, anstataŭ aserti ĝin
Lim-aserto estas nur tiel bona, kiel la listigo malantaŭ ĝi. Sur la pordega gastiganto tri komandoj kovras itineran elekton, vivan sondadon kaj la eliran politikon:
ip route get 10.60.4.20
nc -zv 10.60.4.20 5432
sudo nft list chain inet filter outputLegu la eligon en tiu ordo. La itinero diras, ĉu 10.60.4.20 entute estas elektita de tiu gastiganto; la sondado diras, ĉu la aŭskultanto respondas; la reglisto montras, ĉu politiko haltigas la paketon aŭ ĉu neniam io estis sur ĝia vojo.
Ripetu la listigon de la aplikaĵa gastiganto. De tie la datumbaza flanko estas unu demando ruligita kiel la aplikaĵa rolo:
psql -h 10.60.4.20 -U expenses_app -d expenses -c 'select rolname, rolsuper, rolcreatedb from pg_roles'Sukcesa konekto sub rolo, kiu ne povas legi alian skemon, estas malsama rezulto ol sukcesa konekto sub posedanta rolo. Nur la dua estas trovitaĵo.
Registru la rifuzojn, poste datu la revizion
Akcepto estas skribata kiel rezultoj, ne kiel intencoj: oficista seanco ne povas atingi la aŭskultanton, la pordega gastiganto ne povas atingi nerilatan subreton, kaj la aplikaĵa rolo ne povas krei datumbazon. Ĉiu estas aparta kontrolo kun nomita posedanto kaj dato.
Tenu observadon, flikadon kaj restaŭradon atingeblaj per la administra vojo desegnita por ili. Limo, kiu ankaŭ blokas sian posedanton, fariĝas interrompo, kaj la kutima unua respondo al tiu interrompo estas denove larĝigi la regulon. La perimetra gvidilo de CISA postulas limigi envenantan kaj elvenantan aliron al pravigitaj pordoj kaj protokoloj, inkluzive de trafiko inter internaj retoj, kio estas la backend-iniciata direkto, kiun plej multaj diagramoj preterlasas.
Datu la revizion kaj nomu ĝian posedanton. Rekuru la listigon kaj la privilegian demandon post iu ajn ŝanĝo al la pordega bildo, la itinerada tabelo aŭ la aplikaĵa rolo.