Access को सीमित करना

passwords से आगे, Apache requests को यह देखकर allow या block कर सकता है कि वे कहाँ से आ रही हैं -- IP address, IP range, या hostname से -- जो admin panels, internal tools, या known-bad traffic block करने के लिए useful है।

In this page:

Require ip
Conditions Combine करना
Allow करने की बजाय Block करना
IP Restriction एक Complete Security Model नहीं है

Require ip

Require ip 203.0.113.5 सिर्फ उस exact address को allow करता है; Require ip 192.168.1.0/24 एक पूरी CIDR range allow करता है, जो आमतौर पर किसी internal tool को किसी company के office या VPN network तक restrict करने के लिए इस्तेमाल होता है।

Conditions Combine करना

<RequireAny> और <RequireAll> blocks कई Require conditions को OR/AND logic से combine करते हैं। उदाहरण के लिए, एक <RequireAny> block में Require ip 192.168.1.0/24 और Require valid-user को wrap करना office network से *या* valid login credentials के साथ access allow करता है -- उन staff के लिए useful जिन्हें on-site और remotely दोनों जगह access चाहिए।

Allow करने की बजाय Block करना

Blocking के लिए same directives उल्टा काम करते हैं: Require all granted को एक <RequireAll><Require not ip 203.0.113.5> condition के साथ pair करना बाकी सबको allow करते हुए सिर्फ उस एक address को deny करता है -- पूरी site lock किए बिना एक specific abusive IP को block करने के लिए useful।

IP Restriction एक Complete Security Model नहीं है

IP-based restriction को एक determined attacker के लिए bypass करना आसान है (कुछ attack types के लिए IP addresses spoof किए जा सकते हैं, और shared NAT/proxy के पीछे legitimate users उस address पर बाकी सबके साथ block हो सकते हैं)। इसे एक useful layer मानें -- exposed surface area कम करना -- genuinely sensitive किसी भी चीज़ पर authentication का substitute नहीं।

Warning: किसी sensitive चीज़ जैसे admin panel को बचाने के लिए सिर्फ IP restriction पर भरोसा न करें -- जहाँ भी content actually मायने रखता है वहाँ इसे Basic Auth या application-level login के साथ pair करें।

उदाहरण: Allowing office network OR authenticated users

apacheconf

<Directory "/var/www/example.com/internal">
    AuthType Basic
    AuthName "Internal Tools"
    AuthUserFile /etc/apache2/.htpasswd

    <RequireAny>
        Require ip 192.168.1.0/24
        Require valid-user
    </RequireAny>
</Directory>

{# Flagged by hand after confirming a runner can't handle this example (a shell command / go.mod file stored as a TopicExample, a language feature the configured runner version doesn't support, or output that blows a runner's sandbox limit) -- see TopicExample.norun. Never render the run button for these, regardless of language, since it would just fail at execute_code (or worse, hang the Judge0 queue on a submission that can never finish cleanly). #}

{# common_mistakes/chapter_summary/browser_support: on Hindi pages the view already swaps in the hi_ translation fields (or blanks these out if untranslated), so this renders correctly for both languages without a lang_code check here. #}

आम गलतियां

किसी sensitive चीज़ के लिए IP restriction को इकलौता protection मानना, जब यह असल में सिर्फ एक coarse पहली layer है, real authentication नहीं।
RequireAny/RequireAll logic को उल्टा समझना, गलती से दोनों conditions को true होना ज़रूरी बना देना जब सिर्फ एक ही काफी होना चाहिए था (या इसका उल्टा)।
किसी home/office IP से restrict करना जो बदलती रहती है (कई residential ISPs dynamic addresses देते हैं), अगली बार बदलने पर चुपचाप खुद को lock out कर लेना।

🔒

Chapter Quiz — Complete all 4 topics to unlock

0/4 topics done

Complete these topics first:

← Previous Lesson SSL/TLS Setup Next Lesson → Security Headers