ਕਿਵੇਂ ਡੈਨ ਕਾਮਿੰਸਕੀ ਦੀ DNS ਖੋਜ ਨੇ ਪ੍ਰਣਾਲੀਗਤ ਖ਼ਤਰੇ ਨੂੰ ਬੇਨਕਾਬ ਕੀਤਾ, ਸਮਨਵਿਤ ਖੁਲਾਸੇ ਨੂੰ ਪ੍ਰੇਰਿਤ ਕੀਤਾ, ਅਤੇ ਉਦਯੋਗ ਨੂੰ ਮਹੱਤਵਪੂਰਨ ਇੰਟਰਨੈੱਟ ਢਾਂਚੇ ਨੂੰ ਪੈਚ ਕਰਨ ਦੇ ਤਰੀਕੇ ਬਦਲਣ 'ਤੇ ਮਜ਼ਬੂਰ ਕੀਤਾ।
ਡੈਨ ਕਾਮਿੰਸਕੀ (1979–2021) ਅਜੇ ਵੀ ਪ੍ਰੈਕਟੀਸ਼ਨਰਾਂ ਵਲੋਂ ਹਵਾਲਾ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਉਸਨੇ ਦਿਖਾਇਆ ਕੀ “ਇੰਟਰਨੈੱਟ-ਪੈਮਾਨੇ ਦੀ” ਸੁਰੱਖਿਆ ਠੀਕ ਤਰ੍ਹਾਂ ਕੀਮਿੱਤਦਾਰ, ਵਰਤੋਂਯੋਗ ਅਤੇ ਹਕੀਕਤੀ ਪ੍ਰਭਾਵਾਂ 'ਤੇ ਲਗਾਤਾਰ ਧਿਆਨ ਰੱਖਣ ਵਾਲੀ ਹੁੰਦੀ ਹੈ।
ਉਸਦੀ 2008 ਦੀ DNS ਖੋਜ ਸਿਰਫ਼ ਚਤੁਰ ਨਾ ਸੀ—ਇਸਨੇ ਇੱਕ ਅਬਸਟ੍ਰੈਕਟ ਚਿੰਤਾ—“ਸ਼ਾਇਦ ਨਲਿਕਾ ਵਿੱਚ ਛੇਦ ਹਨ”—ਨੂੰ ਮਾਪਯੋਗ ਅਤੇ ਤੁਰੰਤ ਹਾਲਤ ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ: ਇੱਕ ਖ਼ਾਮੀ ਜੋ ਇਕ ਵਾਰੀ ਵਿੱਚ ਇੰਟਰਨੈੱਟ ਦੇ ਵੱਡੇ ਹਿੱਸਿਆਂ ਨੂੰ ਪ੍ਰभावਿਤ ਕਰ ਸਕਦੀ ਸੀ। ਇਸ ਬਦਲਾਅ ਨੇ ਸੁਰੱਖਿਆ ਟੀਮਾਂ ਅਤੇ ਐਗਜ਼ਿਕਿਊਟਿਵਾਂ ਨੂੰ ਇਹ ਸਮਝਣ ਵਿੱਚ ਮਦਦ ਕੀਤੀ ਕਿ ਕੁਝ ਬਗ ਸਿਰਫ਼ “ਤੁਹਾਡਾ” ਜਾਂ “ਮੇਰਾ” ਨਹੀ ਹੁੰਦੇ। ਉਹ ਸਾਰੇ ਦੇ ਸਾਰੇ ਹੁੰਦੇ ਹਨ।
ਕਾਮਿੰਸਕੀ ਦਾ ਕੰਮ ਅਕਸਰ ਅਸਲ-ਦੁਨੀਆ ਦਾ ਕਿਹਾ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਇਸਨੇ ਤਿੰਨ ਚੀਜ਼ਾਂ ਨੂੰ ਜੋੜਿਆ ਜੋ ਹਰ ਵੇਲੇ ਮਿਲਦੀਆਂ ਨਹੀਂ:
ਇਹ ਸੰਯੋਗ ਆਧੁਨਿਕ ਟੀਮਾਂ ਲਈ ਅਜੇ ਵੀ ਪ੍ਰਸੰਗਿਕ ਹੈ ਜਿਹੜੀਆਂ ਕਲਾਉਡ ਨਿਰਭਰਤਾਵਾਂ, ਮੈਨੇਜਡ ਸਰਵਿਸਿਜ਼, ਅਤੇ ਸਪਲਾਈ-ਚੇਨ ਰਿਸਕ ਨਾਲ ਨਜਿੱਠ ਰਹੀਆਂ ਹਨ। ਜੇ ਕੋਈ ਕਮਜ਼ੋਰੀ ਬਹੁਤ ਵਰਤੀ ਜਾਣ ਵਾਲੇ ਹਿੱਸੇ ਵਿੱਚ ਹੋਵੇ, ਤਾਂ ਤੁਸੀਂ ਮੁਆਫੀ ਨੂੰ ਇੱਕ ਆਮ ਟਿਕਟ ਵਾਂਗ ਨਹੀਂ ਦੇਖ ਸਕਦੇ।
ਇਹ ਪ੍ਰਣਾਲੀਗਤ ਖ਼ਤਰੇ, ਖੁਲਾਸਾ ਕਰਨ ਦੇ ਸਮਨਵਣ, ਅਤੇ ਢਾਂਚਾ ਪੈਚ ਕਰਨ ਦੀ ਹਕੀਕਤਾਂ ਬਾਰੇ ਸਿੱਖਿਆ-ਭਰਪੂਰ ਕਹਾਣੀ ਹੈ। ਇਹ ਕਿਸੇ ਹੱਕੇ-ਬੱਕੇ ਐਕਸਪਲੌਇਟ ਗਾਈਡ ਦੀ ਤਰ੍ਹਾਂ ਨਹੀਂ ਹੈ, ਅਤੇ ਇਸ ਵਿੱਚ ਹਮਲੇ ਨੂੰ ਦੁਹਰਾਉਣ ਵਾਲੇ ਨਿਰਦੇਸ਼ ਨਹੀਂ ਦਿੱਤੇ ਜਾ ਰਹੇ।
ਜੇ ਤੁਸੀਂ ਸੁਰੱਖਿਆ ਜਾਂ ਰਿਲਾਇਬਿਲਟੀ ਪ੍ਰੋਗਰਾਮ ਚਲਾਉਂਦੇ ਹੋ, ਤਾਂ ਕਾਮਿੰਸਕੀ ਦਾ DNS ਪਾਠ ਤੁਹਾਨੂੰ ਆਪਣੀ ਸੀਮਾ ਤੋਂ ਅੱਗੇ ਦੇਖਣ ਦੀ ਯਾਦ ਦਿਵਾਉਂਦਾ ਹੈ: ਕਈ ਵਾਰ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਣ ਜੋਖਮ ਉਹਨਾਂ ਸਾਂਝੀਆਂ ਪਰਤਾਂ ਵਿੱਚ ਹੁੰਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਹਰ ਕੋਈ “ਸਿਰਫ਼ ਚੱਲ ਰਹੀਆਂ” ਸਮਝਦਾ ਹੈ।
ਜਦੋਂ ਤੁਸੀਂ ਕੋਈ ਵੈੱਬਸਾਈਟ ਨਾਮ example.com ਟਾਈਪ ਕਰਦੇ ਹੋ, ਤੁਹਾਡੀ ਡਿਵਾਈਸ ਆਪੋ-ਆਪ ਨਹੀਂ ਜਾਣਦੀ ਕਿ ਕਿੱਥੇ ਜਾਣਾ ਹੈ। ਇਹਨੂੰ ਇੱਕ IP ਪਤਾ ਚਾਹੀਦਾ ਹੈ, ਤੇ DNS ਉਹ ਡਾਇਰੈਕਟਰੀ ਸੇਵਾ ਹੈ ਜੋ ਨਾਮਾਂ ਨੂੰ ਉਹਨਾਂ ਪਤਿਆਂ ਵਿੱਚ ਤਬਦੀਲ ਕਰਦੀ ਹੈ।
ਅਕਸਰ, ਤੁਹਾਡਾ ਕੰਪਿਊਟਰ ਇੱਕ recursive resolver ਨਾਲ ਗੱਲ ਕਰਦਾ ਹੈ (ਅਕਸਰ ਤੁਹਾਡੇ ISP, ਕੰਮ ਦੀ ਜਗ੍ਹਾ, ਜਾਂ ਕੋਈ ਪਬਲਿਕ ਪ੍ਰਦਾਤਾ ਇਹ ਚਲਾ ਰਹੇ ਹੁੰਦੇ ਹਨ)। resolver ਦਾ ਕੰਮ ਤੁਹਾਡੇ ਵਾਸਤੇ ਜਵਾਬ ਲੱਭਣਾ ਹੁੰਦਾ ਹੈ।
ਜੇ resolver ਕੋਲ ਪਹਿਲਾਂ ਤੋਂ ਜਵਾਬ ਨਹੀਂ ਹੁੰਦਾ, ਤਾਂ ਇਹ ਉਸ ਨਾਮ ਲਈ ਜਿੰਮੇਵਾਰ DNS ਸਰਵਰਾਂ ਨੂੰ ਪੁੱਛਦਾ ਹੈ, ਜਿਨ੍ਹਾਂ ਨੂੰ authoritative servers ਕਿਹਾ ਜਾਂਦਾ ਹੈ। authoritative servers ਕਿਸੇ ਡੋਮੇਨ ਲਈ “ਸਚ ਜ਼ਰੂਰੀ ਸਰੋਤ” ਹੁੰਦੇ ਹਨ: ਉਹ ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ ਕਿਹੜਾ IP ਪਤਾ (ਜਾਂ ਹੋਰ ਰਿਕਾਰਡ) ਵਾਪਸ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
Recursive resolvers ਜਵਾਬਾਂ ਨੂੰ cache ਕਰਦੇ ਹਨ ਤਾਂ ਜੋ ਉਹ ਹਰ ਵਾਰੀ ਪੁੱਛਣ ਦੀ ਲੋੜ ਨਾ ਹੋਵੇ। ਇਸ ਨਾਲ ਬਰਾਉਜ਼ਿੰਗ ਤੇਜ਼ ਹੁੰਦੀ, authoritative servers 'ਤੇ ਲੋਡ ਘੱਟ ਹੁੰਦਾ, ਅਤੇ DNS ਸਸਤਾ ਅਤੇ ਜ਼ਿਆਦਾ ਭਰੋਸੇਯੋਗ ਬਣਦਾ ਹੈ।
ਹਰ cached ਰਿਕਾਰਡ ਵਿੱਚ ਇੱਕ ਟਾਈਮਰ ਹੁੰਦਾ ਹੈ ਜਿਸਨੂੰ TTL (time to live) ਕਿਹਾ ਜਾਂਦਾ ਹੈ। TTL ਦੱਸਦਾ ਹੈ ਕਿ resolver ਕਿੰਨੇ ਸਮੇਂ ਲਈ ਜਵਾਬ ਨੂੰ ਦੁਬਾਰਾ ਵਰਤ ਸਕਦਾ ਹੈ।
ਕੈਸ਼ਿੰਗ ਉਹੀ ਗੱਲ ਹੈ ਜੋ resolvers ਨੂੰ ਉੱਚ-ਮੁੱਲ ਵਾਲੇ ਨਿਸ਼ਾਨਾ ਬਣਾਉਂਦੀ ਹੈ: ਇੱਕ cached ਜਵਾਬ ਬਹੁਤ ਸਾਰੇ ਯੂਜ਼ਰਾਂ ਅਤੇ ਬਹੁਤ ਸਾਰੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ TTL ਦੇ ਖਤਮ ਹੋਣ ਤੱਕ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦੀ ਹੈ।
DNS ਇੱਕ ਅਣੁਕ੍ਰਮਿਕ ਧਾਰਨਾ 'ਤੇ ਬਣਿਆ ਹੈ:
ਇਹ ਧਾਰਨਾਵਾਂ ਆਮ ਤੌਰ 'ਤੇ ਸੁਰੱਖਿਅਤ ਹੁੰਦੀਆਂ ਹਨ ਕਿਉਂਕਿ DNS ਬਹੁਤ ਮਿਆਰੀਕ੍ਰਿਤ ਅਤੇ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਤੈਅ ਕੀਤਾ ਗਿਆ ਹੈ। ਪਰ ਪ੍ਰੋਟੋਕੋਲ ਉਸ ਯੁੱਗ ਵਿੱਚ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਗਿਆ ਸੀ ਜਦੋਂ ਵੈਰੋਧੀ ਟ੍ਰੈਫਿਕ ਘੱਟ ਉਮੀਦ ਕੀਤੀ ਜਾਂਦੀ ਸੀ। ਜੇ ਕਿਸੇ ਹਮਲਾਵਰ ਨੇ ਇਕ resolver ਨੂੰ ਨਕਲੀ ਜਵਾਬ ਨੂੰ ਸੱਚਾ ਮੰਨਣ ਵਾਲਾ ਬਣਾਇਆ, ਤਾਂ ਕਿਸੇ ਨਾਮ ਦੀ “ਫੋਨ-ਬੁੱਕ” ਦਰੁਸਤ ਨਾ ਰਹਿ ਸਕਦੀ—ਬਿਨਾਂ ਯੂਜ਼ਰ ਨੇ ਕੁਝ ਅਸਾਧਾਰਣ ਕੀਤਾ ਹੋਵੇ।
DNS ਇੱਕ ਭਰੋਸਾ ਪ੍ਰਣਾਲੀ ਹੈ: ਤੁਹਾਡੀ ਡਿਵਾਈਸ resolver ਨੂੰ ਪੁੱਛਦੀ ਹੈ “example.com ਕਿੱਥੇ ਹੈ?” ਤੇ ਆਮ ਤੌਰ 'ਤੇ ਜਵਾਬ ਨੂੰ ਮੰਨ ਲੈਂਦੀ ਹੈ। ਡੈਨ ਕਾਮਿੰਸਕੀ ਨੇ ਜੋ ਖ਼ਾਮੀ ਸਾਹਮਣੇ ਲਿਆਉਂਦੀ ਦਿਖਾਈ, ਉਹ ਇਹ ਦਿਖਾਉਂਦੀ ਸੀ ਕਿ ਇਹ ਭਰੋਸਾ ਕੈਸ਼ ਪਰਤ 'ਤੇ ਕੀਵੇਂ ਹੱਲਾ ਆ ਸਕਦਾ ਹੈ—ਚਪਕੇ, ਪੈਮਾਨੇ 'ਤੇ, ਅਤੇ ਅਜਿਹੇ ਪ੍ਰਭਾਵਾਂ ਨਾਲ ਜੋ “ਸਧਾਰਨ ਇੰਟਰਨੈੱਟ ਵਿਹਾਰ” ਵਰਗੀ ਲੱਗਦੇ ਹਨ।
Resolvers ਹਰ ਰਿਕ्वੈਸਟ ਲਈ ਗਲੋਬਲ DNS ਸਿਸਟਮ ਨੂੰ ਪੁੱਛਦੇ ਨਹੀਂ। ਉਹ cache ਕਰਦੇ ਹਨ ਤਾਂ ਜੋ ਦੁਹਰਾਏ ਗਏ ਲੁੱਕਅੱਪ ਤੇਜ਼ ਹੋਣ।
Cache poisoning ਉਹ ਹੈ ਜਦੋਂ ਇੱਕ ਹਮਲਾਵਰ ਕਿਸੇ resolver ਨੂੰ ਗਲਤ ਜਵਾਬ ਸਟੋਰ ਕਰਵਾਉਂਦਾ (ਉਦਾਹਰਨ ਲਈ, ਇਕ ਅਸਲੀ ਡੋਮੇਨ ਨੂੰ ਹਮਲਾਵਰ-ਨਿਯੰਤਰਿਤ ਟਰਗੇਟ ਉੱਤੇ ਨਿਰਦੇਸ਼ਿਤ ਕਰਨਾ). ਇਸ ਦੇ ਬਾਅਦ, ਉਸ resolver 'ਤੇ ਨਿਰਭਰ ਬਹੁਤ ਸਾਰੇ ਯੂਜ਼ਰ ਉਸੇ ਗਲਤ ਦਿਸ਼ਾ ਨੂੰ TTL ਦੇ ਖਤਮ ਹੋਣ ਜਾਂ cache ਸਹੀ ਹੋਣ ਤੱਕ ਫਾਲੋ ਕਰ ਸਕਦੇ ਹਨ।
ਭੈਤਰੀ ਗੱਲ ਰੀਡਾਇਰੈਕਸ਼ਨ ਖੁਦ ਨਹੀਂ—ਇਹ ਹੈ ਦਿਖਾਉਣਯੋਗਤਾ। ਬ੍ਰਾਊਜ਼ਰ ਫਿਰ ਵੀ ਉਹੀ ਡੋਮੇਨ ਨਾਮ ਦਿਖਾਉਂਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਦੀ ਯੂਜ਼ਰ ਉਮੀਦ ਕਰ ਰਿਹਾ ਸੀ। ਐਪ ਕੰਮ ਜਾਰੀ ਰੱਖਦੇ ਹਨ। ਕੁਝ ਵੀ “ਕ੍ਰੈਸ਼” ਨਹੀਂ ਹੁੰਦਾ।
ਇਹ ਮੁੱਦਾ ਮਹੱਤਵਪੂਰਨ ਇਸ ਲਈ ਸੀ ਕਿਉਂਕਿ ਇਸਨੇ ਇਕ ਮੁੱਖ ਧਾਰਨਾ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਇਆ: resolvers ਜੋ ਪਹਚਾਣ ਕਰਨ ਦੀ ਨਿਰਭਰਤਾ ਤੇ ਕਿ DNS ਜਵਾਬ ਕਿੰਨੇ ਵਾਜਿਬ ਹਨ। ਜਦੋਂ ਇਹ ਧਾਰਨਾ ਨਾਕਾਮ ਹੋ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਪ੍ਰਭਾਵ ਸਿਰਫ਼ ਇਕ ਮਸ਼ੀਨ ਤਕ ਸੀਮਿਤ ਨਹੀਂ ਰਹਿੰਦਾ—ਇਹ ਉਹਨੇ ਨੈਟਵਰਕ ਹੋ ਸਕਦੇ ਹਨ ਜੋ resolvers ਸਾਂਝੇ ਕਰਦੇ ਹਨ (ਸੰਸਥਾਵਾਂ, ISP, ਕੈਂਪਸ, ਅਤੇ ਕਈ ਵਾਰ ਪੂਰੇ ਖੇਤਰ).
ਅਧਾਰਭੂਤ ਕਮਜ਼ੋਰੀ ਆਮ DNS ਡਿਜ਼ਾਈਨ ਪੈਟਰਨਸ ਅਤੇ ਡੀਫ਼ੌਲਟ ਵਿਵਹਾਰ ਵਿੱਚ ਸੀ, ਨਾ ਕਿ ਕਿਸੇ ਇੱਕ ਉਤਪਾਦ ਵਿੱਚ। ਵੱਖ-ਵੱਖ DNS ਸਰਵਰ ਅਤੇ recursive resolvers—ਅਕਸਰ ਵੱਖ-ਵੱਖ ਟੀਮਾਂ ਦੁਆਰਾ ਲਿਖੇ—ਇਕੋ ਜਿਹੇ ਤਰੀਕੇ ਨਾਲ ਪ੍ਰਭਾਵਿਤ ਹੋ ਗਏ।
ਇਹੀ ਪ੍ਰਣਾਲੀਗਤ ਖ਼ਤਰੇ ਦੀ ਪਰਿਭਾਸ਼ਾ ਹੈ: ਪੈਚ ਕਰਨ ਦਾ ਮਤਲਬ “Vendor X ਨੂੰ ਅਪਡੇਟ ਕਰੋ” ਨਹੀਂ ਸੀ, ਇਹਨਾਂ ਨੂੰ ਸਮਨਵਿਤ ਬਦਲਾਵਾਂ ਦੀ ਲੋੜ ਸੀ ਜੋ ਇੱਕ ਮੁੱਖ ਪ੍ਰੋਟੋਕੋਲ ਨਿਰਭਰਤਾ ਨੂੰ ਹਰ ਥਾਂ ਵਰਤਦਾ ਹੈ। ਭਲਾ ਚੱਲਣ ਵਾਲੀਆਂ ਸੰਸਥਾਵਾਂ ਨੂੰ ਵੀ ਇਹ ਇਨਵੈਂਟਰੀ ਬਣਾਉਣੀ ਪਈ, ਪੁੱਤਰ ਅਪਡੇਟ ਲੱਭਣੇ, ਟੈਸਟ ਕਰਨੇ, ਅਤੇ ਰੋਲ-ਆਊਟ ਕਰਨੇ ਬਿਨਾਂ ਨਾਮ-ਰਿਜ਼ੋਲਿਊਸ਼ਨ ਤੋੜੇ—ਕਿਉਂਕਿ ਜੇ DNS ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਸਭ ਕੁਝ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ।
ਪ੍ਰਣਾਲੀਗਤ ਖ਼ਤਰਾ ਉਹ ਹੈ ਜੋ ਉਸ ਵੇਲੇ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਸਮੱਸਿਆ “ਤੁਹਾਡੀ ਸਮੱਸਿਆ” ਜਾਂ “ਉਹਨਾਂ ਦੀ ਸਮੱਸਿਆ” ਨਹੀਂ ਰਹਿ ਜਾਂਦੀ, ਬਲਕਿ ਸਭ ਦੀ ਸਮੱਸਿਆ ਬਣ ਜਾਂਦੀ ਹੈ ਕਿਉਂਕਿ ਇੰਨੇ ਲੋਕ ਇੱਕੋ ਮੁੱਢਲੇ ਹਿੱਸੇ 'ਤੇ ਨਿਰਭਰ ਹਨ। ਇਹ ਫਰਕ ਹੈ ਇਕੱਲੀ ਕੰਪਨੀ 'ਤੇ ਹਮਲਾ ਹੋਣ ਅਤੇ ਇਕ ਐਸੀ ਕਮਜ਼ੋਰੀ ਜਿਸਨੂੰ ਵੱਡੇ ਪੈਮਾਨੇ 'ਤੇ ਦੁਹਰਾਇਆ ਜਾ ਸਕੇ—ਹਜ਼ਾਰਾਂ ਅਲੱਗ-ਅਲੱਗ ਸੰਸਥਾਵਾਂ ਵਿਰੁੱਧ।
ਇੰਟਰਨੈੱਟ ਢਾਂਚਾ ਸਾਂਝੀਆਂ ਪ੍ਰੋਟੋਕੋਲਸ ਅਤੇ ਸਾਂਝੀਆਂ ਧਾਰਨਾਵਾਂ 'ਤੇ ਬਣਿਆ ਹੈ। DNS ਸਭ ਤੋਂ ਵੱਧ ਸਾਂਝਿਆ ਹੋਇਆ ਹਿੱਸਾ ਹੈ: ਲਗਭਗ ਹਰ ਐਪ, ਵੈੱਬਸਾਈਟ, ਈਮੇਲ ਸਿਸਟਮ ਅਤੇ API ਕਾਲ ਇਸ 'ਤੇ ਨਿਰਭਰ ਹੈ ਕਿ ਨਾਮ (ਜਿਵੇਂ example.com) ਨੂੰ ਨੈੱਟਵਰਕ ਥਾਂ 'ਤੇ ਕਿਵੇਂ ਤਬਦੀਲ ਕੀਤਾ ਜਾਵੇ।
ਜਦੋਂ DNS ਵਰਗੇ ਮੁੱਖ ਨਿਰਭਰਤਾ ਵਿੱਚ ਸੁਰੱਖਿਆ ਦੀ ਕਮਜ਼ੋਰੀ ਹੋਵੇ, ਤਾਂ ਬਲਾਸਟ ਰੇਡੀਅਸ ਅਸਾਧਾਰਣ ਤੌਰ 'ਤੇ ਵੱਡਾ ਹੁੰਦਾ ਹੈ। ਇਕ ਹੀ ਤਕਨੀਕ ਉਦਯੋਗਾਂ, ਭੂਗੋਲਿਕ ਖੇਤਰਾਂ, ਅਤੇ ਕੰਪਨੀ ਮਾਪਾਂ 'ਤੇ ਦੁਹਰਾਈ ਜਾ ਸਕਦੀ ਹੈ—ਅਕਸਰ ਹਮਲਾਵਰਾਂ ਨੂੰ ਹਰ ਨਿਸ਼ਾਨੇ ਦੀ ਗਹਿਰਾਈ ਨਾਲ ਸਮਝਣ ਦੀ ਲੋੜ ਨਹੀਂ ਪੈਂਦੀ।
ਅਕਸਰ ਸੰਸਥਾਵਾਂ DNS ਨੂੰ ਵੱਖ-ਰੇ ਤਰੀਕਿਆਂ ਨਾਲ ਚਲਾਉਂਦੀਆਂ ਹਨ। ਉਹ recursive resolvers ਤੇ ISP, उदਯੋਗ, ਕਲਾਉਡ ਪ੍ਰਦਾਤਾ, ਅਤੇ ਮੈਨੇਜਡ DNS ਸੇਵਾਵਾਂ ਤੇ ਨਿਰਭਰ ਹੁੰਦੀਆਂ ਹਨ। ਇਹ ਸਾਂਝੀ ਨਿਰਭਰਤਾ ਇਕ ਗੁਣਾ ਪ੍ਰਭਾਵ ਬਣਾਉਂਦੀ ਹੈ:
ਇਸ ਤਰ੍ਹਾਂ ਰਿਸਕ ਇਕੱਠਾ ਹੁੰਦਾ ਹੈ: ਇੱਕ ਸੰਸਥਾ ਨੂੰ ਠੀਕ ਕਰਨ ਨਾਲ ਵਿਸ਼ਵ ਪੱਧਰੀ ਖੁਲਾਸਾ ਹਲ ਨਹੀਂ ਹੁੰਦਾ ਜੇ ਪੂਰੀ ਸਿਸਟਮ ਐਕੋਸਿਸਟਮ ਸਮਾਨ ਤੌਰ 'ਤੇ ਪੈਚ ਨਹੀਂ ਕੀਤਾ ਗਿਆ।
DNS ਬਹੁਤ ਸਾਰੇ ਸੁਰੱਖਿਆ ਨਿਯੰਤਰਣਾਂ ਤੋਂ upstream 'ਤੇ ਬੈਠਦਾ ਹੈ। ਜੇ ਹਮਲਾਵਰ ਕਿਸੇ ਨਾਮ ਦੇ ਰਿਜ਼ੋਲੂਸ਼ਨ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦਾ ਹੈ, ਤਾਂ ਡਾਊਨਸਟਰੀਮ ਡਿਫੈਂਸਸ ਨੂੰ ਮਦਦ ਕਰਨ ਦੀ ਮੌਕਾ ਹੀ ਨਹੀਂ ਮਿਲਦੀ। ਇਹ ਸੱਚੇ ਫਿਸ਼ਿੰਗ (ਯੂਜ਼ਰਾਂ ਨੂੰ ਯਕੀਨੀ ਨੱਕਲ ਕਾਰਜ-ਪੰਨਿਆਂ ਵੱਲ ਭੇਜਣਾ), ਮੈਲਵੇਅਰ ਡਿਲਿਵਰੀ (ਅੱਪਡੇਟ ਜਾਂ ਡਾਊਨਲੋਡ ਹਮਲਾਵਰ ਸਰਵਰਾਂ 'ਤੇ ਹੁੰਦੀ), ਅਤੇ ਟ੍ਰੈਫਿਕ ਇੰਟਰਸੈਪਸ਼ਨ (ਗਲਤ ਐਂਡਪੋਇੰਟ 'ਤੇ ਕਨੈਕਸ਼ਨ ਸ਼ੁਰੂ ਹੋਣਾ) ਨੂੰ ਯੋਗ ਬਣਾ ਸਕਦਾ ਹੈ। ਸਿੱਖਿਆ ਸਧਾਰਨ ਹੈ: ਪ੍ਰਣਾਲੀਗਤ ਕਮਜ਼ੋਰੀਆਂ ਛੋਟੇ ਛੇਦਾਂ ਨੂੰ ਵਿਆਪਕ, ਦੁਹਰਾਊ ਪ੍ਰਭਾਵਾਂ ਵਿੱਚ ਬਦਲ ਦਿੰਦੇ ਹਨ।
ਕਾਮਿੰਸਕੀ ਦੀ DNS ਖੋਜ ਨੂੰ ਅਕਸਰ “2008 ਵਿੱਚ ਇਕ ਵੱਡਾ ਬਗ” ਵਜੋਂ ਸੰਖੇਪ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਪਰ ਸਭ ਤੋਂ ਸਿੱਖਣਯੋਗ ਗੱਲ ਇਹ ਹੈ ਕਿ ਇਸਨੂੰ ਕਿਵੇਂ ਹੱਥਲਿਆ ਗਿਆ। ਟਾਈਮਲਾਈਨ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਜਦੋਂ ਪ੍ਰਭਾਵਿਤ “ਉਤਪਾਦ”ਾਹੀ ਇੰਟਰਨੈੱਟ ਹੋਵੇ ਤਾਂ ਸਮਨਵਿਤ ਖੁਲਾਸਾ ਕਿਵੇਂ ਦਿਖਦਾ ਹੈ।
resolverਾਂ ਵਿੱਚ ਅਜੀਬ ਵਿਹਾਰ ਨੂੰ ਨੋਟ ਕਰਕੇ, ਕਾਮਿੰਸਕੀ ਨੇ ਆਪਣੀ ਪਰਿਕਲਪਨਾ ਨੂੰ ਆਮ ਇੰਪਲਮੈਂਟੇਸ਼ਨਾਂ 'ਤੇ ਟੈਸਟ ਕੀਤਾ। ਮੁੱਖ ਕਦਮ ਫਲੈਸ਼ੀ ਡੈਮੋ ਲਿਖਣ ਦੀ ਬਜਾਏ ਇਹ ਪੁਸ਼ਟੀ ਕਰਨਾ ਸੀ ਕਿ ਮੁੱਦਾ ਹਕੀਕਤੀ, ਦੁਹਰਾਉਯੋਗ, ਅਤੇ ਵਿਸ਼ਾਲ ਪੈਮਾਨੇ 'ਤੇ ਲਾਗੂ ਹੈ।
ਉਸਨੇ ਜੋ ਚੰਗੇ ਰਿਸਰਚਰ ਕਰਦੇ ਹਨ ਕੀਤਾ: ਨਤੀਜਿਆਂ ਦੀ ਸੈਨਿਟੀ-ਚੈੱਕਿੰਗ, ਉਹ ਹਾਲਤਾਂ ਘੱਟ ਕਰਨਾ ਜੋ ਕਿਸੇ ਕਮਜ਼ੋਰੀ ਨੂੰ ਸੰਭਵ ਬਣਾਉਂਦੀਆਂ ਹਨ, ਅਤੇ ਇਹ ਪੱਕਾ ਕਰਨਾ ਕਿ ਰਾਹਤ-ਉਪਾਇ ਓਪਰੇਟਰਾਂ ਲਈ ਪ੍ਰਯੋਗਯੋਗ ਹੋਣਗੇ।
ਤੁਰਨ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਦੀ ਥਾਂ, ਉਸਨੇ ਵੱਡੇ DNS ਸੌਫਟਵੇਅਰ ਮੈਟੇਨਰਾਂ, OS ਵੇਂਡਰਾਂ, ਅਤੇ ਢਾਂਚਾਗਤ ਸੰਸਥਾਵਾਂ ਨੂੰ ਨਿੱਜੀ ਤੌਰ 'ਤੇ ਸੰਪਰਕ ਕੀਤਾ। ਇਸ ਵਿੱਚ ਲੋਕਪ੍ਰਿਯ resolvers ਅਤੇ ਏਨਟਰਪ੍ਰਾਈਜ਼ ਨੈਟਵਰਕ ਗੀਅਰ ਦੇ ਟੀਮਾਂ ਸ਼ਾਮਿਲ ਸਨ।
ਇਸ ਦੌਰਾਨ ਭਰੋਸਾ ਅਤੇ ਵਿਵੇਕ ਦੀ ਭੂਮਿਕਾ ਮਹੱਤਵਪੂਰਨ ਸੀ। ਰਿਸਰਚਰਾਂ ਅਤੇ ਵੇਂਡਰਾਂ ਨੂੰ ਇਹਨੂੰ ਮੰਨਣਾ ਪਇਆ ਕਿ:
ਕਿਉਂਕਿ DNS ਆਪਰੇਟਿੰਗ ਸਿਸਟਮਾਂ, ਫਾਇਰਵਾਲ, ਰਾਊਟਰ ਅਤੇ ISP ਇੰਫਰਾਸਟਰਕਚਰ ਵਿੱਚ ਏਂਬੈਡ ਹੈ, ਇਕ ਵਿਭਜਿਤ ਰਿਲੀਜ਼ ਹਮਲਾਵਰਾਂ ਲਈ ਇੱਕ ਜਾਣਿਆ-ਪਛਾਣ ਵਾਲਾ “patch gap” ਪੈਦਾ ਕਰ ਸਕਦੀ ਸੀ। ਇਸ ਲਈ ਲਕੜੀ ਦਾ ਮੰਤਵ ਸਮਨਵਿਤ ਤਿਆਰੀ ਸੀ: ਫਿਕਸ ਡਿਵੈਲਪ ਕੀਤੇ ਜਾਣ, ਟੈਸਟ ਕੀਤੇ ਜਾਣ, ਅਤੇ ਪੈਕੇਜ ਕੀਤੇ ਜਾਣ ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਲੋਕਾਂ ਨੂੰ ਜਨਤਕ ਚਰਚਾ ਲਈ ਸਭਤੋਂ ਪਹਿਲਾਂ ਮਿਲੇ।
ਜਦੋਂ ਮੁੱਦਾ ਜਨਤਕ ਉੱਤੇ ਆਇਆ, ਤਾਂ ਪੈਚ ਅਤੇ ਰਾਹਤ-ਉਪਾਇ ਪਹਿਲਾਂ ਹੀ ਜਾਰੀ ਹੋ ਰਹੇ ਸਨ (ਖ਼ਾਸ ਕਰਕੇ ਇੱਕ ਮੁੱਖ ਵੇਂਡਰ ਅਪਡੇਟ ਸਾਈਕਲ ਨਾਲ ਮੇਲ ਖਾਂਦਿਆਂ)। ਇਸ ਸਮੇਂ ਦਾ ਮਹੱਤਵ ਇਹ ਸੀ: ਇਸਨੇ ਉਸ ਵਿੰਡੋ ਨੂੰ ਘਟਾ ਦਿੱਤਾ ਜਿੱਥੇ ਰੱਖ-ਰੱਖਾਅ ਕਰਨ ਵਾਲੇ ਜਾਣਦੇ ਸਨ ਕਿ ਉਹ ਜ਼ਖਮੀ ਹਨ ਪਰ ਕੁਝ ਨਹੀਂ ਕਰ ਸਕਦੇ।
ਟਿਕਾਣਾ: ਪ੍ਰਣਾਲੀਗਤ ਖਾਮੀਆਂ ਲਈ, ਸਮਨਵਣ ਬਿਊਰੋਕ੍ਰਸੀ ਨਹੀਂ—ਇਹ ਇੱਕ ਸੁਰੱਖਿਆ ਮਕੈਨੀਜ਼ਮ ਹੈ।
ਜਦੋਂ ਕੋਈ ਬਗ ਢਾਂਚੇ ਵਿੱਚ ਹੁੰਦਾ ਹੈ, “ਸਿਰਫ਼ ਪੈਚ ਕਰੋ” ਇੱਕ ਸਧਾਰਨ ਹੁਕਮ ਨਹੀਂ ਰਹਿੰਦਾ—ਇਹ ਸਮਨਵਣ ਸਮੱਸਿਆ ਬਣ ਜਾਂਦੀ ਹੈ। DNS ਇਕ ਚੰਗਾ ਉਦਾਹਰਨ ਹੈ ਕਿਉਂਕਿ ਇਹ ਇਕ ਉਤਪਾਦ ਨਹੀਂ, ਇਕ ਕੰਪਨੀ ਦੁਆਰਾ ਮਾਲਕੀ ਬਣਾਇਆ ਹੋਇਆ ਨਹੀਂ, ਜਾਂ ਇਕ ਥਾਂ 'ਤੇ ਤੈਨਾਤ ਨਹੀਂ ਹੈ। ਇਹ ਹਜ਼ਾਰਾਂ ਆਜ਼ਾਦ ਢੰਗ ਨਾਲ ਚਲਾਏ ਜਾਣ ਵਾਲੇ ਸਿਸਟਮ ਹਨ—ISP, ਕੰਪਨੀਆਂ, ਯੂਨੀਵਰਸਿਟੀਆਂ, ਮੈਨੇਜਡ ਸਰਵਿਸ ਪ੍ਰਦਾਤਾ—ਹਰ ਇਕ ਦੇ ਆਪਣੇ ਤਰਜੀਹਾਂ ਅਤੇ ਪਾਬੰਦੀਆਂ ਹਨ।
ਇੱਕ ਵੈੱਬ ਬ੍ਰਾਊਜ਼ਰ ਰਾਤਾਂ ਰਾਤ ਮਿਲੀਅਨ ਯੂਜ਼ਰਾਂ ਲਈ ਆਟੋ-ਅਪਡੇਟ ਕਰ ਸਕਦਾ ਹੈ। DNS resolvers ਇਉਂ ਨਹੀਂ ਚੱਲਦੇ। ਕੁਝ ਵੱਡੀਆਂ ਟੀਮਾਂ ਦੁਆਰਾ ਚਲਾਏ ਜਾਂਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਕੋਲ ਚੇੰਜ ਮੈਨੇਜਮੈਂਟ ਅਤੇ ਸਟੇਜਿੰਗ ਮਾਹੌਲ ਹੁੰਦੇ ਹਨ; ਹੋਰਾਂ ਨੂੰ ਅਪਲਾਇੰਸਾਂ, ਰਾਊਟਰਾਂ, ਜਾਂ ਲੇਗਸੀ ਸਰਵਰਾਂ ਵਿੱਚ ਏਂਬੈਡ ਕੀਤਾ ਗਿਆ ਹੁੰਦਾ ਹੈ ਜੋ ਸਾਲਾਂ ਤੋਂ ਛੂਹੇ ਨਹੀਂ ਗਏ। ਭਾਵੇਂ ਇਕ ਫਿਕਸ ਉਪਲਬਧ ਹੋਵੇ, ਉਹ ਪ੍ਰਸਾਰਿਤ ਹੋਣ ਵਿੱਚ ਹਫ਼ਤੇ ਜਾਂ ਮਹੀਨੇ ਲੱਗ ਸਕਦੇ ਹਨ ਕਿਉਂਕਿ ਕਿਸੇ ਕੋਲ ਪੂਰੇ ਇਕੋ-ਬਟਨ ਨਹੀਂ ਹੁੰਦਾ ਜੋ ਸਾਰੇ ਇਕੋ ਜਿਹੇ ਢਾਂਚਿਆਂ ਨੂੰ ਅਪਡੇਟ ਕਰ ਦੇਵੇ।
Resolvers ਆਲੋਚਕ ਰਾਹਾਂ 'ਤੇ ਬੈਠੇ ਹੁੰਦੇ ਹਨ: ਜੇ ਉਹ ਟੁੱਟ ਜਾਂਦੇ ਹਨ, ਯੂਜ਼ਰ ਈਮੇਲ, ਭੁਗਤਾਨ ਪੰਨੇ, ਅੰਦਰੂਨੀ ਐਪ—ਕੁਝ ਵੀ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦੇ। ਇਸ ਕਰਕੇ ਆਪਰੇਟਰ ਸੰਭਾਲਦੇ ਹਨ। ਐਂਡਪੋਇੰਟ ਪੈਚਿੰਗ ਅਕਸਰ ਨਰਮ ਗੜਬੜ ਨੂੰ ਸਹਿਣ ਕਰਦੀ; ਇਕ resolver ਅਪਡੇਟ ਜੋ ਗਲਤ ਹੋ ਜਾਵੇ ਉਹ ਇੱਕ ਵਾਰ ਵਿੱਚ ਹਰ ਕਿਸੇ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਨ ਵਾਲੀ ਆਊਟੇਜ ਵਾਂਗ ਲੱਗ ਸਕਦੀ ਹੈ।
ਇੱਥੇ ਇੱਕ ਦਿੱਖ-ਫਰਕ ਵੀ ਹੈ: ਕਈ ਸੰਸਥਾਵਾਂ ਕੋਲ ਪੂਰੀ ਇਨਵੈਂਟਰੀ ਨਹੀਂ ਹੁੰਦੀ ਕਿ DNS ਕਿੱਥੇ ਸੰਭਾਲਿਆ ਜਾ ਰਿਹਾ ਹੈ (on-prem, ਕਲਾਉਡ, ਪ੍ਰਦਾਤਾ ਦੁਆਰਾ, ਬ੍ਰਾਂਚ ਗੀਅਰ ਵਿੱਚ)। ਤੁਸੀਂ ਉਹ ਨਹੀਂ ਪੈਚ ਕਰ ਸਕਦੇ ਜੋ ਤੁਹਾਨੂੰ ਪਤਾ ਨਹੀਂ ਤੁਸੀਂ ਚਲਾ ਰਹੇ ਹੋ।
ਇੰਫਰਾਸਟਰਕਚਰ ਬਦਲਾਵ ਵਪਾਰਕ ਸਮੈਤ ਨਾਲ ਮੁਕਾਬਲਾ ਕਰਦੇ ਹਨ। ਕਈ ਟੀਮਾਂ ਸਿਰਫ਼ ਸੰਕੁਚਿਤ ਰਖ-ਰਖਾਅ ਵਿਕਿੰਡੋਜ਼ ਦੌਰਾਨ ਪੈਚ ਕਰਦੀਆਂ ਹਨ, ਟੈਸਟਿੰਗ, ਮਨਜ਼ੂਰੀਆਂ, ਅਤੇ ਰੋਲਬੈਕ ਯੋਜਨਾ ਤੋਂ ਬਾਅਦ। ਕਈ ਵਾਰੀ ਫੈਸਲਾ ਸਪੱਸ਼ਟ ਜੋਖਮ ਸਵੀਕਾਰ ਹੋਵਣ ਦਾ ਹੁੰਦਾ ਹੈ: “ਅਸੀਂ ਇਸਨੂੰ ਅਪਡੇਟ ਨਹੀਂ ਕਰ ਸਕਦੇ ਜਦ ਤੱਕ ਵੇਂਡਰ ਸਪੋਰਟ ਨਹੀਂ ਕਰਦਾ,” ਜਾਂ “ਇਸਨੂੰ ਬਦਲਣਾ ਛੱਡਣ ਤੋਂ ਜ਼ਿਆਦਾ ਖਤਰਨਾਕ ਹੋ ਸਕਦਾ ਹੈ।”
ਅਸੁਖਦਾਇਕ ਨਤੀਜਾ: ਪ੍ਰਣਾਲੀਗਤ ਮੁੱਦਿਆਂ ਨੂੰ ਠੀਕ ਕਰਨਾ ਕੋਡ ਦੇ ਨਾਲ-ਨਾਲ ਓਪਸ, ਉਤਸ਼ਾਹਾਂ, ਅਤੇ ਸਮਨਵਣ ਬਾਰੇ ਵੀ ਹੈ।
ਜਦੋਂ ਪ੍ਰਭਾਵਤ “ਉਤਪਾਦ” ਇਕ ਵੈਂਡਰ ਦੇ ਸੌਫਟਵੇਅਰ ਨਹੀਂ—ਬਲਕਿ ਇਕ ਪੂਰੇ ਏਕੋਸਿਸਟਮ ਦਾ ਹਿੱਸਾ ਹੁੰਦਾ ਹੈ—ਤਦ ਸੰਪੂਰਨ CVD ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦੀ ਹੈ। DNS ਕਮਜ਼ੋਰੀ ਸਿਰਫ਼ ਇਕ resolver ਵਿੱਚ ਬੱਗ ਨਹੀਂ ਹੁੰਦੀ; ਇਹ ਅਪਰੇਟਿੰਗ ਸਿਸਟਮਾਂ, ਰਾਊਟਰ ਫਰਮਵੇਅਰ, ISP ਇੰਫਰਾਸਟਰਕਚਰ, ਐਂਟਰਪ੍ਰਾਈਜ਼ DNS ਅਪਲਾਇੰਸ, ਅਤੇ ਮੈਨੇਜਡ DNS ਸੇਵਾਵਾਂ ਨੂੰ ਛੂਹਦੀ ਹੈ। ਇਸਨੂੰ ਠੀਕ ਕਰਨ ਲਈ ਉਹਨਾਂ ਸਗਠਨਾਵਾਂ 'ਤੇ ਸਮਨਵਿਤ ਕਾਰਵਾਈ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਇਕੋ ਸਡਢਿਊਲ 'ਤੇ ਸ਼ਿਪ ਨਹੀਂ ਹੁੰਦੀਆਂ।
ਪੈਮਾਨੇ 'ਤੇ, CVD ਇੱਕ ਇਕਲੋਤਾ ਐਲਾਨ ਨਹੀਂ—ਇੱਕ ਧੀਰਜ ਨਾਲ ਚਲਾਇਆ ਜਾਣ ਵਾਲਾ ਪ੍ਰੋਜੈਕਟ ਹੁੰਦਾ ਹੈ।
ਵੇਂਡਰ ਭਰੋਸੇਯੋਗ ਚੈਨਲਾਂ ਰਾਹੀਂ ਕੰਮ ਕਰਦੇ ਹਨ (ਅਕਸਰ CERT/CC ਜਾਂ ਸਮਾਨ ਸੰਘਠਨਾਂ ਦੁਆਰਾ) ਤांकि ਪ੍ਰਭਾਵ ਵੇਰਵੇ ਸਾਂਝੇ ਕੀਤੇ ਜਾ ਸਕਣ, ਟਾਈਮਲਾਈਨ 'ਤੇ ਸਮਨਵਯਤਾ ਹੋਵੇ, ਅਤੇ ਪੈਚਜ਼ ਜੋ ਇੱਕੋ ਜੜੀ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਦੇ ਹਨ ਉਹ ਪੁਸ਼ਟੀ ਕੀਤੇ ਜਾਣ। ISP ਅਤੇ ਵੱਡੀਆਂ ਸੰਸਥਾਵਾਂ ਨੂੰ ਜਲਦੀ ਲੂਪ ਵਿੱਚ ਲਿਆਉਣਾ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਉਹ ਉੱਚ-ਵਾਲੀਅਮ resolvers ਚਲਾਉਂਦੀਆਂ ਹਨ ਅਤੇ ਇੰਟਰਨੈੱਟ-ਪੱਧਰੀ ਖ਼ਤਰੇ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਘਟਾ ਸਕਦੀਆਂ ਹਨ। ਟੀਕ ਵਿੱਚ ਰਾਜ਼ੀਬਾਜ਼ੀ ਲਈ ਨਹੀਂ—ਬਲਕਿ ਪੈਚ ਡਿਪਲੋਇਮੈਂਟ ਹੋਣ ਤੱਕ ਹਮਲਾਵਰਾਂ ਲਈ ਸਮਾਂ ਖਰੀਦਣ ਲਈ ਹੈ।
“ਚੁੱਪਚਾਪ” ਦਾ ਮਤਲਬ ਲੁਕਾਇਆ ਹੋਣਾ ਨਹੀਂ; ਇਹ ਮੱਤਲਬ ਹੈ ਕਿਵੇਂ ਫੇਜ਼ ਕੀਤਾ ਗਿਆ।
ਤੁਸੀਂ ਵੇਖੋਂਗੇ ਸੁਰੱਖਿਆ ਸਲਾਹਕਾਰੀਆਂ ਜੋ ਤਾਤਕਾਲੀਅਤ ਅਤੇ ਰਾਹਤ-ਉਪਾਈਆਂ 'ਤੇ ਧਿਆਨ ਦਿੰਦੀਆਂ ਹਨ, ਸੌਫਟਵੇਅਰ ਅਪਡੇਟ ਜੋ ਆਮ ਪੈਚ ਚੈਨਲਾਂ ਵਿੱਚ ਵਰਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਕੰਫਿਗਰੇਸ਼ਨ ਸਖਤੀ ਦੇ ਰਹਿੰਦੀਆਂ ਹਦਾਇਤਾਂ (ਉਦਾਹਰਨ ਲਈ, ਸੇਫਰ ਡੀਫੌਲਟ ਐਨੇਬਲ ਕਰਨਾ ਜਾਂ ਕਵੈਰੀ ਬਿਹੈਵਿਅਰ ਵਿੱਚ ਜ਼ਿਆਦਾ ਰੈਂਡਮਨੈਸ ਵਰਤਣਾ). ਕੁਝ ਬਦਲਾਅ ਡਿਫੈਂਸ-ਇਨ-ਡੀਪ्थ ਦੇ ਤੌਰ 'ਤੇ ਆਉਂਦੇ ਹਨ ਜੋ ਉਸੇ ਸਮੇਂ ਉਪਲਬਧ ਨਿੱਜੀ ਡਿਵਾਈਸਾਂ ਲਈ ਨਿਰਭਰ ਨਹੀਂ ਰਹਿੰਦੇ।
ਚੰਗੀ ਮੈਸੇਜਿੰਗ ਇੱਕ ਸੁਤੰਤਰਤਾ ਨੂੰ ਧਾਰਦੀ ਹੈ: ਪਰਿਚਾਲਕਾਂ ਲਈ ਕਾਫ਼ੀ ਸਪਸ਼ਟ, ਅਤੇ ਹਮਲਾਵਰਾਂ ਲਈ ਨਕਸ਼ਾ ਨਾ ਦੇਣ ਵਾਲੀ।
ਕਾਰੀ ਸਲਾਹਕਾਰੀਆਂ ਦੱਸਦੀਆਂ ਹਨ ਕਿ ਕੌਣ ਜੋਖਮ ਵਿੱਚ ਹੈ, ਪਹਿਲਾਂ ਕੀ ਪੈਚ ਕਰਨਾ ਹੈ, ਅਤੇ ਕੋਈ ਆਗੇ-ਸਥਾਪਨਤ ਕੰਟਰੋਲ ਕੀ ਹਨ। ਉਹ ਲੜੀਵਾਰ ਤਰਤੀਬਾਂ ਦਿੰਦੀਆਂ ਹਨ (“ਅੱਜ ਕੀ ਕਰਨਾ ਹੈ, ਇਸ ਹਫ਼ਤੇ ਕੀ, ਅਤੇ ਇਸ ਤਿਮਾਹੀ ਵਿਚ ਕੀ”)। ਅੰਦਰੂਨੀ ਸੰਚਾਰ ਨੂੰ ਵੀ ਉਸੇ ਢਾਂਚੇ ਦੀ ਨਕਲ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ, ਇੱਕ ਸਿੰਗਲ ਮਾਲਕ ਨਾਲ, ਰੋਲਆਊਟ ਯੋਜਨਾ, ਅਤੇ ਇੱਕ ਸਪਸ਼ਟ “ਅਸੀਂ ਕਿਵੇਂ ਜਾਣਾਂਗੇ ਕਿ ਅਸੀਂ ਮੁਕੰਮਲ ਹੋਏ”।
ਕਾਮਿੰਸਕੀ ਦੀ ਖੋਜ ਤੋਂ ਬਾਅਦ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਬਦਲਾਅ ਇਕ ਇਕਲੌਤਾ “ਇਹ ਸੈਟਿੰਗ ਬਦਲੋ” ਹਲ ਨਹੀਂ ਸੀ। ਉਦਯੋਗ ਨੇ ਇਸਨੂੰ ਇਕ ਢਾਂਚਾਗਤ ਸਮੱਸਿਆ ਵਾਂਗ ਲਿਆ ਜਿਸ ਲਈ defense-in-depth ਦੀ ਲੋੜ ਸੀ: ਘਣੇ-ਛੋਟੇ ਰੋਕ-ਬਧਾਵ ਜਿਹੜੇ ਮਿਲਕੇ ਵੱਡੇ ਪੈਮਾਨੇ 'ਤੇ ਦੁਰਵਰਤੀ ਕਰਨ ਨੂੰ ਗ਼ੈਰ-ਪ੍ਰਯੋਗਯੋਗ ਬਣਾਉਂਦੇ ਹਨ।
DNS ਡਿਜ਼ਾਈਨ ਹੀ ਵੰਡਿਆ ਗਿਆ ਹੈ। ਇਕ ਕਵੈਰੀ ਕਈ resolvers, caches, ਅਤੇ authoritative servers ਰਾਹੀਂ ਲੰਘ ਸਕਦੀ ਹੈ, ਜਿਨ੍ਹਾਂ ਦੇ ਵੱਖ-ਵੇੱਖ ਸੌਫਟਵੇਅਰ ਵਰਜਨ ਅਤੇ ਕੰਫਿਗਰੇਸ਼ਨ ਹੁੰਦੀਆਂ ਹਨ। ਭਲੇ ਹੀ ਇਕ ਵੇਂਡਰ ਜਲਦੀ ਪੈਚ ਸ਼ਿਪ ਕਰੇ, ਤੁਹਾਡੇ ਕੋਲ ਫਿਰ ਵੀ ਵਿਭਿੰਨ ਤਰ੍ਹਾਂ ਦੇ ਡਿਪਲੋਇਮੈਂਟ, ਏਂਬੈਡ ਕੀਤੀਆਂ ਐਪਲਾਇੰਸਾਂ, ਅਤੇ ਅਪਡੇਟ ਕਰਨ-ਗਏ ਸਿਸਟਮ ਰਹਿ ਜਾਂਦੇ ਹਨ। ਇਕ ਦਾਇਮੀ ਜਵਾਬ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਜੋਖਮ ਕਈ ਫੇਲ-ਮੋਡਾਂ ਵਿੱਚ ਘੱਟ ਹੋਣ।
ਆਮ resolver implementation ਵਿੱਚ ਕਈ ਪਰਤਾਂ ਮਜਬੂਤ ਕੀਤੀਆਂ ਗਈਆਂ:
ਕੁਝ ਸੁਧਾਰ Resolver ਬਣਾਉਣ ਅਤੇ ਕਨਫਿਗਰ ਕਰਨ ਦੇ ਤਰੀਕੇ ਬਾਰੇ ਸਨ (implementation hardening). ਹੋਰ ਸੁਧਾਰ ਪ੍ਰੋਟੋਕੋਲ ਪਰਿਯਾਵਰਣ ਬਾਰੇ ਸਨ ਤਾਂ ਜੋ DNS ਸਮੇਂ ਦੇ ਨਾਲ ਜ਼ਿਆਦਾ ਭਰੋਸੇਯੋਗ ਬਣੇ।
ਇੱਕ ਮੁੱਖ ਸਿੱਖਿਆ: ਪ੍ਰੋਟੋਕੋਲ ਕੰਮ ਅਤੇ ਸੌਫਟਵੇਅਰ ਬਦਲਾਅ ਇਕ-ਦੂਜੇ ਨੂੰ ਮਜ਼ਬੂਤ ਕਰਦੇ ਹਨ। ਪ੍ਰੋਟੋਕੋਲ ਸੁਧਾਰ ਸੁਰੱਖਿਆ ਲਈ ਉੱਚੀ ਸੀਮਾ ਰੱਖ ਸਕਦੇ ਹਨ, ਪਰ ਮਜ਼ਬੂਤ ਡੀਫੌਲਟ, ਸੁਰੱਖਿਅਤ ਵੈਰੀਫਿਕੇਸ਼ਨ, ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਦਿਖਾਈ ਦੇਣਯੋਗਤਾ ਹੀ ਉਹ ਹਨ ਜੋ ਇਨ੍ਹਾਂ ਲਾਭਾਂ ਨੂੰ ਇੰਟਰਨੈੱਟ 'ਤੇ ਹਕੀਕਤ ਬਣਾਂਦੇ ਹਨ।
DNS “ਸੀਟ-ਅਤੇ-ਭੁੱਲ ਜਾਓ” ਲੱਗਦਾ ਹੈ ਜਦ ਤੱਕ ਇਹ ਨਹੀਂ ਹੁੰਦਾ। ਕਾਮਿੰਸਕੀ ਦਾ ਕੰਮ ਇਹ ਯਾਦ ਦਿਲਾਉਂਦਾ ਹੈ ਕਿ DNS resolvers ਸੁਰੱਖਿਆ-ਆਵਸ਼ਕ ਸਿਸਟਮ ਹਨ, ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਚਲਾਉਣਾ ਡਿਸੀਪਲਿਨ ਦਾ ਮਾਮਲਾ ਹੈ ਨਾ ਕਿ ਸਿਰਫ਼ ਸੌਫਟਵੇਅਰ।
ਸ਼ੁਰੂਆਤ ਕਰੋਂ ਆਪਣੇ ਚੱਲ ਰਹੇ ਹਿੱਸਿਆਂ ਤੇ ਇਹ ਸਮਝ ਕੇ ਕਿ ਹਰ ਹਿੱਸੇ ਲਈ “patched” ਦਾ ਕੀ ਮਤਲਬ ਹੈ।
DNS ਘਟਨਾਵਾਂ ਅਕਸਰ “ਅਜੀਬ” ਤਰੀਕੇ ਨਾਲ ਸਾਹਮਣੇ ਆਉਂਦੀਆਂ ਹਨ, ਸਾਫ਼ Errors ਨਹੀਂ।
ਧਿਆਨ ਦਿਓ:
ਇੱਕ DNS ਘਟਨਾ ਰਨਬੁਕ ਹੋਵੇ ਜੋ ਭੂਮਿਕਾਵਾਂ ਅਤੇ ਫੈਸਲਿਆਂ ਦਾ ਨਾਮ ਦਿੰਦਾ ਹੋਵੇ।
ਕੌਣ ਟ੍ਰਿਆਜ ਕਰਦਾ ਹੈ, ਕੌਣ ਸੰਚਾਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਕੌਣ ਪ੍ਰੋਡਕਸ਼ਨ resolver configs ਬਦਲ ਸਕਦਾ ਹੈ ਇਹ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ। ਨੈਟਵਰਕ, ਸੁਰੱਖਿਆ, ਅਤੇ ਵੇਂਡਰ/ISP ਲਈ ਉਚਿਤ ਤਰਤੀਬਾਂ ਅਤੇ ਪਹਿਲਾਂ ਮਨਜ਼ੂਰ ਕੀਤੀਆਂ ਕਾਰਵਾਈਆਂ ਸ਼ਾਮਿਲ ਕਰੋ ਜਿਵੇਂ ਕਿ ਅਸਥਾਈ ਤੌਰ ਤੇ ਫਾਰਵਰਡਰ ਬਦਲਨਾ, ਲੌਗਿੰਗ ਵਧਾਉਣਾ, ਜਾਂ ਸ਼ੱਕੀ ਕਲਾਇੰਟ ਸੈਗਮੈਂਟਾਂ ਨੂੰ ਅਲੱਗ ਕਰਨਾ।
ਅੰਤ ਵਿੱਚ, ਰੋਲਬੈਕ ਦੀ ਯੋਜਨਾ ਰੱਖੋ: ਜਾਣ-ਪਛਾਣ ਵਾਲੀਆਂ-ਅੱਛੀਆਂ ਕਨਫਿਗਰੇਸ਼ਨਾਂ ਅਤੇ ਤੁਰੰਤ ਰਾਹ ਤੇਜ਼ੀ ਨਾਲ ਵਾਪਸ ਲੈਣ ਦਾ ਰਸਤਾ ਰੱਖੋ। ਮਕਸਦ ਹੈ ਭਰੋਸੇਯੋਗ ਰਿਜੋਲਿਊਸ਼ਨ ਜਲਦੀ ਮੁੜ ਲੈ ਆਉਣਾ, ਫਿਰ ਬਿਨਾ ਅਨੁਮਾਨ ਲਗਾਉਂਦੇ ਜਾਂਚ ਕਰਨਾ।
ਜੇ ਤੁਹਾਨੂੰ ਲੱਗਦਾ ਹੈ ਕਿ ਤੁਹਾਡੇ ਰਨਬੁਕਸ ਜਾਂ ਅੰਦਰੂਨੀ ਚੈੱਕਲਿਸਟ ਵਿਖੇਰੇ ਹੋਏ ਹਨ, ਤਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਇੱਕ ਛੋਟੀ ਸੌਫਟਵੇਅਰ ਪ੍ਰੋਡਕਟ ਵਾਂਗ ਇਲਾਜ ਕਰੋ: ਵਰਜਨਡ, ਸਮੀਖਿਆਯੋਗ, ਅਤੇ ਅਸਾਨੀ ਨਾਲ ਅਪਡੇਟ ਹੋਣ ਯੋਗ। ਪਲੇਟਫਾਰਮਾਂ ਜਿਵੇਂ Koder.ai ਟੀਮਾਂ ਨੂੰ ਚੈਟ-ਡ੍ਰਾਈਵਨ ਵਿਕਾਸ ਰਾਹੀਂ ਹਲਕੇ ਵਜ਼ਨ ਦੇ ਅੰਦਰੂਨੀ ਟੂਲ (ਜਿਵੇਂ ਇੱਕ ਰਨਬੁਕ ਹੱਬ ਜਾਂ ਇਨਸੀਡੈਂਟ ਚੈਕਲਿਸਟ ਐਪ) ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ—ਉਪਯੋਗੀ ਜਦੋਂ ਤੁਹਾਨੂੰ ਨੈੱਟਵਰਕ, ਸੁਰੱਖਿਆ, ਅਤੇ SRE ਵਿੱਚ ਸੰਗਤਿਤਤਾ ਚਾਹੀਦੀ ਹੋਵੇ ਬਿਨਾਂ ਲੰਮੀ ਬਣਾਉਣ ਚਕ੍ਰ ਤੋਂ।
ਕਾਮਿੰਸਕੀ ਦਾ DNS ਕੰਮ ਯਾਦ ਦਿਵਾਉਂਦਾ ਹੈ ਕਿ ਕੁਝ ਖ਼ਾਮੀਆਂ ਇਕ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਨਹੀਂ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਂਦੀਆਂ—ਉਹ ਤੁਹਾਡੇ ਬਿਜ਼ਨਸ 'ਤੇ ਚਲ ਰਹੀਆਂ ਭਰੋਸੇ ਦੀਆਂ ਧਾਰਨਾਵਾਂ ਨੂੰ ਖਤਰੇ ਵਿੱਚ ਪਾ ਦਿੰਦੀਆਂ ਹਨ। ਲੀਡਰਸ਼ਿਪ ਸਿੱਖਿਆ ਇਹ ਨਹੀਂ ਕਿ "DNS ਡਰਾਉਣਾ ਹੈ"। ਇਹ ਹੈ ਕਿ ਜਦੋਂ ਬਲਾਸਟ ਰੇਡੀਅਸ ਤਕ ਦਿਖਾਈ ਨਹੀਂ ਦਿੰਦਾ ਅਤੇ ਠੀਕ ਕਰਨ ਲਈ ਕਈ ਪਾਰਟੀਆਂ ਤੇ ਨਿਰਭਰ ਹੋਣਾ ਪੈਂਦਾ, ਤਦ ਪ੍ਰਣਾਲੀਗਤ ਖ਼ਤਰੇ ਬਾਰੇ ਕਿਵੇਂ ਸੋਚਣਾ।
ਕੀ ਹੋ ਸਕਦਾ ਸੀ: ਜੇ cache poisoning ਪੈਮਾਨੇ 'ਤੇ ਦੌਰਾ ਹੋਣਾ ਸਥਿਰ ਹੋ ਜਾਂਦਾ, ਤਾਂ ਹਮਲਾਵਰ ਯੂਜ਼ਰਾਂ ਨੂੰ ਅਸਲੀ ਸੇਵਾਵਾਂ (ਬੈਂਕਿੰਗ, ਈਮੇਲ, ਸੌਫਟਵੇਅਰ ਅਪਡੇਟ, VPN ਪੋਰਟਲ) ਤੋਂ ਨਕਲੀ ਸਾਈਟਾਂ 'ਤੇ ਰੀਡਾਇਰੈਕਟ ਕਰ ਸਕਦੇ ਸਨ। ਇਹ ਸਿਰਫ਼ ਫਿਸ਼ਿੰਗ ਨਹੀਂ—ਇਹ DNS 'ਤੇ ਭਰੋਸਾ, ਗੁਪਤਤਾ, ਅਤੇ ਡਾਟਾ ਦੀ ਅਖੰਡਤਾ ਨੂੰ ਭੰਨ ਦੇ ਸਕਦਾ ਹੈ ਜੋ ਡਾਊਨਸਟਰੀਮ ਸਿਸਟਮ "DNS ਨੂੰ ਭਰੋਸੇਯੋਗ" ਮੰਨ ਜਾਂਦੇ ਹਨ। ਬਿਜ਼ਨਸ ਪ੍ਰਭਾਵ ਚਾਹੇ ਕ੍ਰੈਡੰਸ਼ੀਅਲ ਚੋਰੀ, ਧੋਖਾਧੜੀ, ਜਾਂ ਵਿਆਪਕ ਘਟਨਾ-ਪ੍ਰਤੀਕਿਰਿਆ ਅਤੇ ਖ਼ਰਾਬ ਨਾ ਰੁਪ-ਨਾਮ ਹੋ ਸਕਦੇ ਹਨ।
ਕੀ ਦੇਖਿਆ ਗਿਆ: ਉਦਯੋਗ ਦਾ ਸਮਨਵਿਤ ਜਵਾਬ ਹਕੀਕਤੀ ਨੁਕਸਾਨ ਨੂੰ ਘਟਾ ਦਿੱਤਾ। ਜਦ ਕਿ ਡੈਮੋ ਅਤੇ ਇਕੱਲੇ-ਇੱਕਲੇ ਘਟਨਾਵਾਂ ਹੋਈਆਂ, ਵੱਡੀ ਕਹਾਣੀ ਇਹ ਹੈ ਕਿ ਤੇਜ਼, ਨਿੱਜੀ ਪੈਚਿੰਗ ਨੇ ਇੱਕ ਵਿਆਪਕ ਸ਼ੋਖੇਰਾ ਦੁਰਪਯੋਗ ਰੋਡ ਤੇ ਨਹੀਂ ਆਉਣ ਦਿੱਤਾ। ਇਹ ਨਤੀਜਾ ਕਿਸੇ ਕਿਸਮ ਦੀ ਕਿਸਮਤ ਨਹੀਂ ਸੀ; ਇਹ ਤਿਆਰੀ, ਸਮਨਵਣ, ਅਤੇ ਅਨੁਸ਼ਾਸਿਤ ਸੰਚਾਰ ਦਾ ਨਤੀਜਾ ਸੀ।
ਪ੍ਰਕਟਿਕਲ ਰੂਪ ਵਿੱਚ, ਪਰਖ ਕਰਨ ਨੂੰ ਇੱਕ ਚੇੰਜ-ਮੈਨੇਜਮੈਂਟ ਕਸਰਤ ਸਮਝੋ, ਨਾ ਕਿ ਰੈੱਡ-ਟੀਮ ਸਟੰਟ।
ਜਦੋਂ ਸੰਸਾਧਨ ਸੀਮਿਤ ਹਨ, ਤਾਂ ਬਲਾਸਟ ਰੇਡੀਅਸ ਅਤੇ ਨਿਰਭਰਤਾ ਗਿਣਤੀ ਅਨੁਸਾਰ ਪ੍ਰਾਥਮਿਕਤਾ ਦਿਓ:
ਜੇ ਪੈਚ ਫੇਜ਼ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਨਿਰਬਲਤ کنਟਰੋਲ ਸ਼ਾਮਿਲ ਕਰੋ: recursion ਨੂੰ ਜਾਣੇ-ਪਛਾਣੇ ਕਲਾਇੰਟਾਂ ਤੱਕ ਸੀਮਿਤ ਕਰੋ, DNS ਲਈ egress/ingress ਨਿਯਮ ਕੜੇ ਕਰੋ, NXDOMAIN ਸਪਾਇਕਸ ਜਾਂ ਅਣਉਮੀਦ ਜਵਾਬ churn ਲਈ ਨਿਗਰਾਨੀ ਵਧਾਓ, ਅਤੇ ਅਸਥਾਈ ਜੋਖਮ ਸਵੀਕਾਰ ਕਰਨਾ ਦਸਤਾਵੇਜ਼ ਕਰੋ ਸਪਸ਼ਟ ਤਾਰੀਖ ਦੇ ਨਾਲ ਕਿ ਇਸਨੂੰ ਕਦੋਂ ਬੰਦ ਕੀਤਾ ਜਾਵੇਗਾ।
ਸੁਰੱਖਿਆ ਖੋਜ ਇੱਕ ਤਣਾਅ 'ਤੇ ਟਿਕੀ ਹੁੰਦੀ ਹੈ: ਉਹੀ ਗਿਆਨ ਜੋ ਰੱਖ-ਰੱਖਾਅ ਕਰਨ ਵਾਲਿਆਂ ਦੀ ਮਦਦ ਕਰਦਾ ਹੈ ਉਸੇ ਜਾਣਕਾਰੀ ਨਾਲ ਹਮਲਾਵਰਾਂ ਨੂੰ ਵੀ ਸਹਾਇਤਾ ਹੋ ਸਕਦੀ ਹੈ। ਕਾਮਿੰਸਕੀ ਦੀ DNS ਖੋਜ ਇਹ ਯਾਦ ਦਿਲਾਉਂਦੀ ਹੈ ਕਿ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ “ਸਹੀ ਹੋਣਾ” ਕਾਫੀ ਨਹੀਂ—ਤੁਹਾਨੂੰ ਸੋਚ-ਸਮਝ ਕੇ ਇਹ ਵੀ ਨਿਰਣ ਕਰਨਾ ਪੈਂਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਜੋ ਸਿੱਖਿਆ ਸਾਂਝੀ ਕਰ ਰਹੇ ਹੋ ਉਸਨੂੰ ਕਿਵੇਂ ਸਾਂਝਾ ਕੀਤਾ ਜਾਵੇ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਹਦ ਇਹ ਹੈ ਕਿ ਪ੍ਰਭਾਵ, ਪ੍ਰਭਾਵਿਤ ਹਾਲਤਾਂ, ਅਤੇ ਰਾਹਤ-ਉਪਾਇਆ 'ਤੇ ਧਿਆਨ ਦਿਤਾ ਜਾਵੇ—ਅਤੇ ਸਾਵਧਾਨੀ ਨਾਲ ਇਹ ਸੋਚਿਆ ਜਾਵੇ ਕਿ ਤੁਸੀਂ ਕੀ ਛੱਡ ਰਹੇ ਹੋ। ਤੁਸੀਂ ਇਹ ਸਮਝਾ ਸਕਦੇ ਹੋ ਕਿ ਕਿਸ ਤਰ੍ਹਾਂ ਦੀ ਕਮਜ਼ੋਰੀ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਓਪਰੇਟਰਾਂ ਕੀ ਦੇਖ ਸਕਦੇ ਹਨ, ਅਤੇ ਕਿਹੜੇ ਬਦਲਾਅ ਜੋਖਮ ਘਟਾ ਦਿੰਦੇ ਹਨ—ਬਿਨਾਂ ਉਹਨਾਂ ਕੋਡ-ਅਤੇ-ਪੇਸਟ ਨਿਰਦੇਸ਼ਾਂ ਨੂੰ ਪ੍ਰਕਾਸ਼ਿਤ ਕੀਤੇ ਜੋ ਦੁਰਪਯੋਗ ਦੀ ਲਾਗਤ ਘਟਾ ਦਿੰਦੇ।
ਇਹ ਗੁਪਤਤਾ ਦੀ ਗੱਲ ਨਹੀਂ; ਇਹ ਸਮਾਂ ਅਤੇ ਦਰਸ਼ਕਾਂ ਬਾਰੇ ਸੋਚਣ ਦੀ ਗੱਲ ਹੈ। ਜਦ ਤੱਕ ਪੈਚ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਉਪਲਬਧ ਨਹੀਂ ਹਨ, ਉਹ ਵੇਰਵੇ ਜੋ ਦੁਰਪਯੋਗ ਨੂੰ ਤੇਜ਼ ਕਰਦੇ ਹਨ निजी ਚੈਨਲਾਂ ਵਿੱਚ ਰਹਿਣੇ ਚਾਹੀਦੇ ਹਨ।
ਜਦੋਂ ਮਸਲਾ ਸਾਂਝੀ ਢਾਂਚਾ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ, ਇੱਕ ਹੀ inbox ਕਾਫੀ ਨਹੀਂ ਹੁੰਦੀ। CERT/CC-ਸਮਰੂਪ ਕੋਆਰਡੀਨੇਟਰ ਸਹਾਇਤਾ ਕਰਦੇ ਹਨ:
ਉਸ ਸਹਿਯੋਗ ਨੂੰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਬਣਾਉਣ ਲਈ, ਇੱਕ ਸਪਸ਼ਟ ਸ਼ੁਰੂਆਤੀ ਰਿਪੋਰਟ ਭੇਜੋ: ਤੁਸੀਂ ਕੀ ਦੇਖਿਆ, ਤੁਸੀਂ ਕਿਵੇਂ ਸੋਚਦੇ ਹੋ ਕਿ ਕੀ ਹੋ ਰਿਹਾ ਹੈ, ਕਿਉਂ ਇਹ ਤਤਕਾਲੀ ਹੈ, ਅਤੇ ਪ੍ਰਮਾਣਤਾ ਕਿਵੇਂ ਕਰਨੀ ਹੈ। ਧਮਕੀਆਂ ਤੋਂ ਬਚੋ, ਅਤੇ "ਮੈਂ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਬੱਗ ਲੱਭੀ" ਵਰਗੀਆਂ ਅਸਪਸ਼ਟ ਈਮੇਲਾਂ ਤੋਂ ਵੀ ਪਰਹੇਜ਼ ਕਰੋ।
ਚੰਗੀਆਂ ਨੋਟਾਂ ਇਕ ਨੈਤਿਕ ਸੰਦ ਹਨ: ਉਹ ਗਲਤ-ਫਹਿਮੀਆਂ ਨੂੰ ਰੋਕਦੀਆਂ ਹਨ ਅਤੇ ਖਤਰਨਾਕ ਬੈਕ-ਅਨ-ਫੋਰਥ ਨੂੰ ਘਟਾਉਂਦੀਆਂ ਹਨ।
ਲਿਖੋ ਤਾਂ ਕਿ ਦੂਜੇ ਇੰਜੀਨੀਅਰ ਮੁੜ-ਉਤਪਾਦ, ਪੁਸ਼ਟੀ, ਅਤੇ ਸੰਚਾਰ ਕਰ ਸਕਣ:
ਜੇ ਤੁਸੀਂ ਇੱਕ ਸੰਰਚਿਤ ਟੈਮਪਲੇਟ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਵੇਖੋ /blog/coordinated-vulnerability-disclosure-checklist।
ਕਾਮਿੰਸਕੀ ਦੀ DNS ਖੋਜ ਇਸ ਗੱਲ ਦੀ ਯਾਦ ਦਿਵਾਉਂਦੀ ਹੈ ਕਿ ਸਭ ਤੋਂ ਖਤਰਨਾਕ ਕਮਜ਼ੋਰੀਆਂ ਅਕਸਰ ਸਭ ਤੋਂ ਜਟਿਲ ਨਹੀਂ ਹੁੰਦੀਆਂ—ਉਹ ਉਹ ਹਨ ਜੋ ਤੁਹਾਡੇ ਚੱਲ ਰਹੇ ਸਿਸਟਮਾਂ ਦੁਆਰਾ ਸਾਂਝੇ ਕੀਤੀਆਂ ਜਾ ਰਹੀਆਂ ਹੁੰਦੀਆਂ ਹਨ। ਕੰਪਨੀ ਸਟੈਕ ਵਿੱਚ “ਪ੍ਰਣਾਲੀਗਤ ਖ਼ਤਰਾ” ਉਹ ਕੋਈ ਵੀ ਨਿਰਭਰਤਾ ਹੈ ਜੋ ਫੇਲ ਹੋਣ ਜਾਂ ਕਮ੍ਰੋਪ੍ਰੋਮਾਈਜ਼ ਹੋਣ 'ਤੇ ਬਹੁਤ ਸਾਰੇ ਹੋਰ ਸਿਸਟਮਾਂ ਨੂੰ ਚੁਪ-ਚਾਪ ਤੌਰ 'ਤੇ ਢਾਹ ਸਕਦੀ ਹੈ।
ਉਹ ਸੇਵਾਵਾਂ ਸੂਚੀਬੱਧ ਕਰਕੇ ਸ਼ੁਰੂ ਕਰੋ ਜਿਨ੍ਹਾਂ ਨੂੰ ਬਹੁਤ ਸਾਰੇ ਹੋਰ ਸਿਸਟਮ ਸਦੈਵ ਸਹੀ ਮੰਨਦੇ ਹਨ:
ਇੱਕ ਤੇਜ਼ ਟੈਸਟ: ਜੇ ਇਹ ਹਿੱਸਾ ਝੂਠ ਬੋਲ ਦੇਵੇ, ਰੁਕ ਜਾਏ, ਜਾਂ ਅਣਉਪਲਬਧ ਹੋ ਜਾਏ, ਤਾਂ ਕਿੰਨੇ ਬਿਜ਼ਨਸ ਪ੍ਰੋਸੈਸ ਫੇਲ ਹੋ ਜਾਂਦੇ ਹਨ—ਅਤੇ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ? ਪ੍ਰਣਾਲੀਗਤ ਖ਼ਤਰਾ ਅਕਸਰ ਪਹਿਲਾਂ ਸ਼ਾਂਤ ਰਹਿੰਦਾ ਹੈ।
ਰੈਜ਼ੀਲੀਅੰਸ ਟੂਲ ਖਰੀਦਣ ਨਾਲ ਘੱਟ ਨਹੀਂ ਬਣਦੀ—ਇਹ ਅਰਡBre_design ਦੇ ਬਾਰੇ ਹੈ।
** redundancy** ਸਿਰਫ਼ “ਦੋ ਸਰਵਰ” ਹੋਣ ਤੋਂ ਵੱਧ ਮਤਲਬ ਰੱਖਦੀ ਹੈ। ਇਹ ਦੋ ਅਜ਼ਾਦ ਪ੍ਰਦਾਤਾਵਾਂ, ਤੋੜ-ਵਿੱਛੋੜੇ ਲਈ ਵੱਖ-ਵੱਖ ਪ੍ਰਮਾਣਿਕਤਾ ਰਸਤੇ, ਅਤੇ ਕਈ ਪ੍ਰਮਾਣਿਕਤਾ ਸਰੋਤਾਂ (ਉਦਾਹਰਨ ਲਈ ਸਮਾਂ ਡਰਿਫਟ ਮਾਨਿਟਰਿੰਗ ਲਈ ਵੱਖ-ਵੱਖ ਅਦਾਰਿਆਂ ਤੋਂ) ਨੂੰ ਵੀ ਸ਼ਾਮਿਲ ਕਰਦੀ ਹੈ।
ਸੈਗਮੈਂਟੇਸ਼ਨ ਬਲਾਸਟ ਰੇਡੀਅਸ ਨੂੰ ਸੀਮਿਤ ਕਰਦੀ ਹੈ। ਅਹੰਕਾਰਪੂਰਨ ਕੰਟਰੋਲ-ਪਲੇਨ (ਆਈਡੈਂਟੀਟੀ, ਸੀਕ੍ਰੇਟਸ, DNS ਪ੍ਰਬੰਧਨ, ਸਰਟੀਫਿਕੇਟ ਜਾਰੀ ਕਰਨ) ਨੂੰ ਆਮ ਵਰਕਲੋਡ ਤੋਂ ਵੱਖ ਰੱਖੋ, ਕੜੀ ਪਹੁੰਚ ਅਤੇ ਲੌਗਿੰਗ ਨਾਲ।
ਨਿਰੰਤਰ ਪੈਚ ਪ੍ਰਕਿਰਿਆਵਾਂ ਮਹੱਤਵਪੂਰਨ ਹਨ ਕਿਉਂਕਿ ਇੰਫਰਾਸਟਰਕਚਰ ਆਪਣੇ ਆਪ ਪੈਚ ਨਹੀਂ ਹੁੰਦਾ। “ਬੋਰਿੰਗ” ਹਿੱਸਿਆਂ ਲਈ ਅਪਡੇਟ—DNS resolvers, NTP, PKI, ਲੋਡ ਬੈਲੈਂਸਰ—ਨੂੰ ਇੱਕ ਰੁਟੀਨਲ ਓਪਰੇਸ਼ਨਲ ਉਤਪਾਦ ਵਾਂਗ ਸਮਝੋ, ਨਾ ਕਿ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਪ੍ਰੋਜੈਕਟ।
ਜੇ ਤੁਸੀਂ ਇੱਕ ਹਲਕਾ-ਫੁਲਕਾ ਢਾਂਚਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਇਹੋਨੂੰ ਇੱਕ ਸਧਾਰਣ ਰਨਬੁਕ ਟੈਂਪਲੇਟ ਨਾਲ ਜੋੜੋ ਜੋ ਟੀਮਾਂ 'ਚ ਵਰਤੋਂ ਯੋਗ ਅਤੇ ਢੂੰਘਾ ਨਹੀਂ—ਅਤੇ ਆਸਾਨੀ ਨਾਲ ਲੱਭਿਆ ਜਾ ਸਕੇ (ਉਦਾਹਰਨ ਲਈ /blog/runbook-basics)।
ਕਾਮਿੰਸਕੀ ਦੀ 2008 ਦੀ DNS ਖੋਜ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਇਸਨੇ ਇਕ “ਅਜੀਬ ਪ੍ਰੋਟੋਕੋਲ ਸਮੱਸਿਆ” ਨੂੰ ਇੰਟਰਨੈੱਟ-ਪੈਮਾਨੇ ਦਾ, ਮਾਪਯੋਗ ਖ਼ਤਰਾ ਬਣਾਕੇ ਦਰਸਾਇਆ। ਇਸਨੇ ਦਿਖਾਇਆ ਕਿ ਜਦੋਂ ਕੋਈ ਸਾਂਝੀ ਪਰਤ ਕਮਜ਼ੋਰ ਹੁੰਦੀ ਹੈ ਤਾਂ ਪ੍ਰਭਾਵ ਸਿਰਫ਼ ਇੱਕ ਕੰਪਨੀ ਤੱਕ ਸੀਮਿਤ ਨਹੀ ਰਹਿੰਦਾ—ਬੇਸ਼ੱਕ ਬਹੁਤ ਸਾਰੀਆਂ ਅਲੱਗ-ਅਲੱਗ ਸੰਸਥਾਵਾਂ ਇੱਕੇ ਸਮੇਂ ਪ੍ਰਭਾਵਿਤ ਹੋ ਸਕਦੀਆਂ ਹਨ, ਅਤੇ ਇਸਨੂੰ ਠੀਕ ਕਰਨ ਲਈ ਕੋਡ ਦੇ ਨਾਲ-ਨਾਲ ਸਮਨਵਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
DNS ਨਾਮਾਂ (ਜਿਵੇਂ example.com) ਨੂੰ IP ਪਤੇ ਵਿੱਚ ਤਬਦੀਲ ਕਰਦਾ ਹੈ। ਆਮ ਤੌਰ 'ਤੇ:
ਇਹ caching DNS ਨੂੰ ਤੇਜ਼ ਬਣਾਉਂਦਾ—ਸਾਥ ਹੀ ਇਹ ਗਲਤੀਆਂ ਜਾਂ ਹਮਲਿਆਂ ਨੂੰ ਵੀ ਵਿਆਪਕ ਕਰ ਸਕਦਾ ਹੈ।
ਇੱਕ recursive resolver DNS ਜਵਾਬਾਂ ਨੂੰ cache ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ ਦੁਹਰਾਏ ਗਏ ਲੁੱਕਅੱਪ ਤੇਜ਼ ਅਤੇ ਸਸਤੇ ਹੋ ਜਾਣ।
Caching ਇੱਕ blast radius ਬਣਾਉਂਦਾ ਹੈ: ਜੇ ਕੋਈ resolver ਗਲਤ ਜਵਾਬ ਸਟੋਰ ਕਰ ਲੈਂਦਾ ਹੈ, ਤਾਂ ਉਹਨਾਂ resolvers 'ਤੇ ਨਿਰਭਰ ਕਈ ਯੂਜ਼ਰ ਅਤੇ ਸਿਸਟਮ ਉਸੇ ਗਲਤ ਜਵਾਬ ਨੂੰ TTL ਦੇ ਖਤਮ ਹੋਣ ਤੱਕ ਜਾਂ cache ਸਹੀ ਹੋਣ ਤੱਕ ਫਾਲੋ ਕਰ ਸਕਦੇ ਹਨ।
Cache poisoning ਉੱਡੇ-ਨਜ਼ਰੀਏ ਵਿੱਚ ਉਹ ਹੈ ਜਦੋਂ ਇੱਕ ਹਮਲਾਵਰ ਇੱਕ resolver ਨੂੰ ਗਲਤ DNS ਜਵਾਬ ਸਟੋਰ ਕਰਵਾ ਦਿੰਦਾ (ਉਦਾਹਰਨ ਲਈ, ਇਕ ਅਸਲੀ ਡੋਮੇਨ ਨੂੰ ਹਮਲਾਵਰ-ਨਿਯੰਤਰਿਤ ਗੰਠਾਂ ਵੱਲ ਪойнਟ ਕਰਨਾ).
ਖਤਰਾ ਇਹ ਹੈ ਕਿ ਨਤੀਜਾ “ਨਾਰਮਲ” ਦਿਖਾਈ ਦੇ ਸਕਦਾ ਹੈ:
ਇਹ ਲੇਖ ਇਰਾਦਾਤੀ ਤੌਰ 'ਤੇ ਹਮਲਿਆਂ ਨੂੰ ਦੁਹਰਾਉਣ ਵਾਲੀਆਂ ਕਦਮਾਂ ਦੇ ਨਿਰਦੇਸ਼ ਨਹੀਂ ਦਿੰਦਾ।
ਪ੍ਰਣਾਲੀਗਤ ਖ਼ਤਰਾ ਉਹ ਹੈ ਜਦੋਂ ਇੱਕ ਸਾਂਝੀ ਨਿਰਭਰਤਾ ਦੀ ਇੱਕ ਕਮਜ਼ੋਰੀ ਬਹੁਤ ਸਾਰੀਆਂ ਸੰਸਥਾਵਾਂ ਲਈ ਖ਼ਤਰਾ ਬਣ ਸਕਦੀ ਹੈ—ਇੱਕ ਹੀ ਕਮਜ਼ੋਰੀ ਅਨੇਕ ਟਾਰਗੇਟਾਂ 'ਤੇ ਵਿਆਪਕ ਅਸਰ ਕਰ ਸਕਦੀ ਹੈ।
DNS ਇਸਦਾ ਇਕ ਬਹੁਤ ਹੀ ਸਾਫ਼ ਉਦਾਹਰਨ ਹੈ ਕਿਉਂਕਿ ਲਗਭਗ ਹਰ ਸੇਵਾ ਇਸ 'ਤੇ ਨਿਰਭਰ ਹੈ। ਜੇ ਇੱਕ ਆਮ resolver ਵਿਹਾਰ ਖ਼ਤਰਨਾਕ ਹੈ, ਤਾਂ ਇੱਕ ਤਕਨੀਕ ਪੂੰਜੀਕਰਨ ਕਰਕੇ ਨਿੱਤ-ਭਰ ਦੇ ਉਦਯੋਗਾਂ, ਭੂਗੋਲ ਅਤੇ ਕੰਪਨੀ ਮਾਪਾਂ 'ਤੇ ਦੁਹਰਾਈ ਜਾ ਸਕਦੀ ਹੈ।
ਜਦੋਂ ਪ੍ਰਭਾਵਤ “ਉਤਪਾਦ” ਇਕ ਇਕੋ ਥਾਂ ਦਾ ਨਹੀਂ ਹੁੰਦਾ—ਬਲਕਿ ਇਕ ਪੂਰੇ Ecosystem ਦਾ ਹਿੱਸਾ ਹੁੰਦਾ—ਤਦ Coordinated Vulnerability Disclosure (CVD) ਜ਼ਰੂਰੀ ਹੋ ਜਾਂਦੀ ਹੈ।
ਅਸਲ ਵਿੱਚ CVD ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ:
ਪ੍ਰਣਾਲੀਗਤ ਮੁੱਦਿਆਂ ਲਈ ਸਮਨਵਣ ਉਸ “patch gap” ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ ਜੋ ਹਮਲਾਵਰ ਲਾਭ ਲਈ ਵਰਤ ਸਕਦੇ ਹਨ।
ਇੱਕ ਇਨვენਟਰੀ ਅਤੇ ਮਲਕੀਅਤ ਨਕਸ਼ੇ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ:
ਤੁਸੀਂ ਉਹ ਨਹੀਂ ਠੀਕ ਕਰ ਸਕਦੇ ਜੋ ਤੁਹਾਡੇ ਕੋਲ ਮਾਲੂਮ ਨਹੀਂ।
ਯੂਜ਼ਲ ਸਿਗਨਲ ਅਕਸਰ “ਅਜੀਬ” ਹੋਣਗੇ, ਸਾਫ਼ ਗਲਤੀਆਂ ਨਹੀਂ:
ਰੁਝਾਨਾਂ 'ਤੇ ਅਲਰਟ ਕਰਨਾ (ਸਿਰਫ ਇਕ ਘਟਨਾ ਨਹੀਂ) ਸਿਸਟਮਿਕ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਪਹਿਲਾਂ ਪਕੜਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।
2008 ਤੋਂ ਬਾਅਦ ਜੋ ਝੱਲੀਆਂ ਘਟਨਾਵਾਂ ਘਟਾਈਆਂ ਗਈਆਂ ਓਹ ਏਕ-ਜਹਾਂ ਵਾਲੇ ਹੱਲ ਦੀ ਬਜਾਏ ਰੱਖਿਆ-ਈਨ-ਗਹਿਰਾਈ (defense-in-depth) ਦੇ ਢੰਗ ਹਨ:
ਲੰਬੇ ਸਮੇਂ ਲਈ ਪ੍ਰੋਟੋਕੋਲ ਸੁਧਾਰ ਅਤੇ Implementation-level ਬਿਹਤਰ ਕੀਤੀ ਗਈਆਂ ਚੋਣਾਂ ਇਸ ਰਿਸਕ ਨੂੰ ਘਟਾਉਂਦੀਆਂ ਹਨ; ਪਰ ਸੇਫ ਡੀਫ਼ੌਲਟ ਅਤੇ ਓਪਸ ਡਿਸਪਲਿਨ ਸਚਮੁਚ ਨਤੀਜੇ ਲਿਆਉਂਦੇ ਹਨ।
ਇੱਕ ਪ੍ਰਾਪੱਟ ਕਰਨ-ਯੋਗ ਚਾਹ-ਮਾਪ ਆਧਾਰ 'ਤੇ ਜਾਂਚ ਕਰੋ, ਨਾ ਕਿ ਇੱਕ ਰੈੱਡ-ਟੀਮ ਸਟੰਟ ਵਾਂਗ:
ਲੀਡਰਾਂ ਲਈ: ਬਲਾਸਟ ਰੇਡੀਅਸ ਅਨੁਸਾਰ ਰਿਮੀਡੀਆਸ਼ਨ ਨੂੰ ਤਰਜੀਹ ਦਿਓ (ਜਿਹੜੇ resolvers ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਯੂਜ਼ਰ/ਵਿਸ਼ੇਸ਼ ਪਥ ਸੇਵਾ ਕਰਦੇ ਹਨ)।
