Zergatik hausten duen jatorrizko ataka-arau batek zure SSH bide bat

Kudeaketa-sarrera bi host berean, zerbitzu-ataka bat eta biak laguntzeko xedea zuen politika-arau bat. Arauak jatorrizko 22 atakarekin bat egiten du, bilaketa WANeko balio lehenetsia baino ez duen taula batera bidaltzen du, eta VPN sarrerak saio-hasiera berriei erantzuteari uzten dio, sarrera zuzenak lanean jarraitzen duen bitartean. Horietako ezer ez da misteriotsua hautatzailea behar bezala irakurtzen denean. Jatorrizko atakak zerbitzu bat identifikatzen du, ez konexioa iritsi zen bidea.

Bi sarrera, zerbitzu-ataka bat

Hostak LAN aldeko helbide bat eta VPN helbide bat ditu, eta sshd biek entzuten du. Beraz, zuzeneko saioak eta tunel-saioak zerbitzu-ataka partekatzen dute eta konexioa zein tokiko helbidek jasotzen duen baino ez dute ezberdintzen.

Aldea hori nahikoa da erantzun-bidea hautatzeko, eta atakan oinarritutako arau batek baztertzen duen aldea da hain zuzen. Bi saioek jatorrizko ataka 22 duten erantzunak sortzen dituzte, beraz ataka horrekin bat egiten duen arauak ezin ditu bereizi. Bi bilaketak taula berera bidaltzen ditu, eta horietako batek egokitzen ez den erantzun bat jasotzen du. Konponbidea benetan ezberdintzen den atributua bat etortzea da.

Sarrera bakoitzari bere ataka emateak ere funtzionatuko luke, eta hori baldintzatzat hartzea diseinu-erabakia da, ez SSHren propietatea.

Irakurri araua, gero taula

Politika-araua hautatzaile ordenatu bat da, eta erantzun erabilgarria itzultzen duen lehenak amaitzen du bilaketa. Irakurri zerrenda ordenan eta ohartu zein arauk irabaz dezakeen.

Gero irakurri arauak seinalatzen duen taula, arrakastaz ebazten den araua ez baita erabilgarri ebazten den araua. Lehenetsitako bide bat baino ez duen taula batek VPN jatorriko erantzuna WAN interfazetik bidaltzen du. Geroagoko taula bateko bide zehatzagoa ez da inoiz kontsultatzen, eta horregatik bigarren taula bat gehitzeak hain sarritan ez du ezer aldatzen. Hautatutako taula da aztertu beharrekoa.

ip -4 rule show
ip route show table 100
ip route show table main

Irteera bi horiek elkarrekin azaltzen dute emaitza; bakoitzak bakarrik ondorio oker batera gonbidatzen du.

Mugatu araua aipatu nahi duzun fluxura

Bi sarrerak bereizten dituen atributua tokiko jatorrizko helbidea da. Helbide horrekin bat egiten duen arauak tunel-saioak soilik bidaltzen ditu taula pribatura eta zuzeneko saioak taula nagusian uzten ditu.

Arau hori bide pribatua eta azpisare horretarako itzulera-bidea dituen taula batekin parekatu behar da. Mugatu biak kudeaketa-trafikora, hosteko zerbitzu bakoitzera baino. Helbide horretako trafiko guztia harrapatzen duen arauak hostak hortik bidaltzen duen beste edozer ere birbideratuko du. Estuak irabazten dio argiari hemen, hurrengo pertsonak irakurri behar duelako.

sudo ip rule add from 10.90.0.1 lookup 100 priority 100
sudo ip route add 10.90.0.0/24 dev wg0 table 100
ip route get 10.90.5.20 from 10.90.0.1

Bi sarrerak tokiko helbide bakarrera itzultzen badira, bereizketa hori desagertu egiten da eta diseinuak konexioaz jabetzen den egoera behar du horren ordez.

Eduki entzulea, baimena eta erantzun-hautaketa bereizita

Hiru gauza bereizi behar dira egia izan saio batek lan egin dezan: helbidea badago, zerbitzuak hura entzuten du eta erantzunak itzulera-bidea aurkitzen du. Bide-aldaketa batek hirugarrena baino ez du konpontzen.

Entzulearen konfigurazioa bere fitxategi propioa eta bere birkarga propioa da, eta hainbat entzute-helbide normalak dira. Autentifikazioa hirugarren erabaki bat da berriz, eta bideratze-salbuespen batek ez dio inori sarbiderik ematen. Eutsi ostalari-gakoaren egiaztapenari, kontuaren autentifikazioari eta jatorri-murrizketei bi sarreretan, eta eutsi tunelaren beste kontrolak ahultzeko bulkadari, kudeaketa-bide bakarra lan egin dezan.

Eduki berreskuratze-kanal bat aldatzen ari zaren bidearen mende ez dagoena, hemengo akats batek konponbidea bera blokeatzen duelako.

Frogatu saio berri batekin, ez zaharrarekin

Ezarritako terminal batek ez du ezer frogatzen, aldaketaren aurretik onartu baitzen. Ireki saio berri bat aurreikusitako sarrera bakoitzetik.

ss -ltnp | grep ':22'
sudo sshd -T | grep -i listenaddress
ssh -v [email protected] true
sudo journalctl -u ssh -n 30

Ondoren errepikatu VPN berriz konektatzea eta saiatu berriro, berriz konektatzeari eusten dion bidea ez baita berriz konektatzeak husten duen taula batera gehitutakoaren berdina. Behatu ukatutako iturburuak baimenduetatik bereizita, blokeatutako saiakera batek lanean ari den saio baten atzean ezkutatu ez dadin. Gorde tokiko helbidea, araua eta taula emaitzaren ondoan. Horren ordez atakak banatzen badituzu, erregistratu eragiketa-erabaki gisa, ez SSHren mugatzat.