SSH-ի և VPN-ի մուտքի կանոնները. ինչ է իրականում վերահսկում թույլատրող ցանկը

Միացեք մեկ անգամ նախքան կանոնը փոխելը և նկատեք՝ հաճախորդը կախվում է, թե անմիջապես մերժվում։ Այդ միակ տարբերությունը ձեզ ասում է, թե որ որոշումը գցեց փաթեթը, և խնայում է մեկ ժամ քաղաքականության ֆայլեր կարդալուց։ Ճանապարհի մնացած մասը կարճ է՝ փաթեթը հատում է կեռ, համընկնում է կանոնի հետ և կամ հասնում է լսողին, կամ ոչ։ Թույլատրող ցանկը ընդամենը հաշվառում է այդ երեք փաստերի շուրջ։

Հետևեք մեկ SSH փորձի մինչև մուտքի կեռը

Հաճախորդը SYN է ուղարկում հոսթի հասցեին 22 պորտով, և միջուկը որոշում է՝ այդ փաթեթը տեղական ծառայության համար է, թե ոչ։ Եթե այո, գործարկվում է մուտքի ուղին, և կանոնների հավաքածուն կա՛մ ընդունում է փաթեթը, կա՛մ դեն է նետում։ Լռությունը նշանակում է, որ SYN-ը մահացել է նախքան լսողը կտեսներ այն, իսկ արագ մերժումը նշանակում է, որ ինչ-որ բան պատասխանել է վերակայմամբ։ Սրանք տարբեր կանոնների տարբեր վճիռներ են, և երկուսն էլ օրինական ելքեր են։

Այնուհետև հաստատեք լսողին, քանի որ ոչ մի կանոն չի փրկի ծառայություն, որը չկա։ Գործարկեք ss -ltnp և ստուգեք, որ ինչ-որ բան կապված է սպասվող պորտին և հասցեների ընտանիքին, ապա կարդացեք ssh -v հաճախորդի վրա՝ տեսնելու, թե որտեղ է այն կանգ առնում։

Փոխանցումը առանձին որոշում է

VPN սերվերի վրա ավելի հետաքրքիր կեռը forward-ն է, քանի որ հաճախորդի երթևեկությունը երթուղվում է մեքենայի միջով, այլ ոչ թե հանձնվում դրան։ Հոսթը, որն աշխատեցնում է միայն իր սեփական VPN հաճախորդը, պահանջում է շատ ավելի փոքր կանոնների հավաքածու, քան այն, որ փոխանցում է ուրիշների փաթեթները։ Երկու ձևավորումները մեկ մեքենայի վրա խառնելը ստեղծում է կանոններ, որոնք ճիշտ են թվում և ոչինչ չեն անցկացնում։

Ներքին քաղաքականությունը գրեք որպես առանձին հարց՝ որ հաճախորդի հասցեներն ինչ նպատակակետերի կարող են հասնել թունելի միջով։ Վարչական ուղին, օրինակ SSH-ը, պահեք մուտքի ուղու վրա՝ իր սեփական աղբյուրի սահմանափակմամբ։ Փորձարկման ընթացքում ավելացված թույլատրող forward կանոնը դասական արատն է, որը գոյատևում է փորձարկումից հետո, ուստի փոփոխությունից հետո վերանայեք ամբողջ հավաքածուն, այլ ոչ թե խմբագրած մեկ տողը։ Թունելի լսողը բացելը թույլտվություն չէ, որ յուրաքանչյուր միացած հաճախորդ կառավարի հոսթը։

Գցելն ու մերժելը գործողություններ են, ոչ քաղաքականություն

Հիմնական շղթայի քաղաքականությունն ընդունում կամ գցում է, և դա ընտրությունների ամբողջ ցանկն է, ինչպես ասում է nftables-ի տեղեկագիրը։ Մերժումը գոյություն ունի որպես կանոնի գործողություն՝ ընտրված պատասխանով, դրա համար էլ այն որպես քաղաքականություն գրելը ձախողվում է և՛ nftables-ում, և՛ iptables-ում։ Գործնականում drop-ը հաճախորդին ոչ մի տեղեկություն չի տալիս, մինչդեռ reject-ը տալիս է սխալ, որի հիման վրա նա կարող է գործել։

table inet admin {
    chain input {
        type filter hook input priority filter; policy drop;
        ct state established,related accept
        ip saddr 203.0.113.0/28 tcp dport 22 accept
        udp dport 51820 accept
        icmp type { destination-unreachable, time-exceeded } accept
    }
}

Այդ ուրվագիծը կարդացեք որպես որոշման ձև, ոչ թե տեղադրելու ֆայլ, քանի որ հասցեների միջակայքերը օրինակներ են։ SSH պորտի վրա բացահայտ reject-ը չարտոնված հաճախորդին ձախողում է մեկ վայրկյանում՝ ժամկետի սպասելու փոխարեն, ինչը կրճատում է ձեր սեփական վրիպազերծումը։ Լռությունը հետ է պահում պատահական սկանավորումից և թույլատրված օգտվողին ընդհանրապես ոչինչ չի ասում։ Ընտրեք ըստ ծառայության և գրեք պատճառը, այլապես հաջորդ մարդը կվերադարձնի այն։

Պահեք այն կառավարման երթևեկությունը, որն իսկապես անհրաժեշտ է

Ամբողջ ICMP-ի արգելափակումը հանրաճանաչ լռելյայն է, որը կոտրում է ուղու MTU-ի հայտնաբերումը, և ախտանիշը կապ է, որը հաստատվում է, ապա կանգ է առնում ավելի մեծ փաթեթների վրա։ IPv6-ում հարևանների հայտնաբերումը կախված է իր ICMPv6 տեսակներից, և դրանք դեն նետելը կոտրում է կապը նախքան որևէ TCP կանոն դիտարկելը։ Երկուսն էլ թույլատրող ցանկում տեղ ունեն որպես անվանված կախվածություններ, այլ ոչ որպես համատարած թույլտվություններ։ Քաղաքականությունը, որ լուռ կոտրում է հայտնաբերումը, ավելի վատն է, քան այն, որ թույլ է տալիս մի փոքր ախտորոշիչ երթևեկություն։

Թույլատրեք established և related վիճակները ձեր սկսած կապերի համար և թողեք վիճակին տեղյակ շարժիչը զբաղվի պատասխաններով։ Ապա հաստատեք, որ պատասխանի ուղին ավելի հեռու արգելափակված չէ, քանի որ միայն ելքային երթևեկության սահմանափակումը վերևում առաջացնում է նույն ժամկետը, որը պատրաստվում էիք մեղադրել հոսթին։

Ապացուցեք վերականգնումը նախքան հին ուղուց հրաժարվելը

Բաց պահեք կոնսոլի նստաշրջանը, կիրառեք փոփոխությունը և բացեք բոլորովին նոր կառավարման կապ այլ տերմինալից։ Գոյություն ունեցող նստաշրջանը ոչինչ չի ապացուցում, քանի որ այն կարող է վերապրել կանոն, որը արգելափակում է յուրաքանչյուր նոր մուտք, ինչը դարձնում է այն հրապարակային աշխատանքի ամենահամոզիչ կեղծ դրականը։ Եթե մոնիտորինգի համակարգը ստուգում է հոսթը, ավելացրեք նրա աղբյուրի հասցեն փոփոխությունից առաջ, ոչ թե առաջին ծանուցումից հետո։ Ապա փորձարկեք մեկ մեծ և մեկ փոքր փաթեթ՝ ապացուցելու, որ հայտնաբերումը դեռ աշխատում է։

VPN ծառայության համար կրկնեք հաճախորդից, որը երբեք չի միացել, քանի որ վերսկսված նստաշրջանը կարող է վերօգտագործել վիճակ, որը նորին պետք է բանակցի։ Արձանագրեք անցած կանոնների ճշգրիտ հավաքածուն՝ ստուգիչ գումարով կամ պատճենով, որպեսզի հետագա խմբագրումը համեմատվի, այլ ոչ թե գուշակվի։ Համաձայնեցրեք կանոնների հերթականության տիրոջ հետ, քանի որ ավելի վաղ կանոնը լուռ հաղթում է ձեր ավելացրածին։