[GH-ISSUE #76] Fail2Ban Whitelist Step

kerem commented

2026-03-02 02:59:16 +03:00

Owner

Originally created by @Kuuchuu on GitHub (Nov 16, 2025).
Original GitHub issue: https://github.com/buildplan/du_setup/issues/76

Fail2Ban was banning my IP address after the post-du_setup reboot, likely due to some automation I had set up before my server rebuild. A step to whitelist IPs (or suggest whitelisting your current connection) might be nice. I can submit a PR later if desired.

Originally created by @Kuuchuu on GitHub (Nov 16, 2025). Original GitHub issue: https://github.com/buildplan/du_setup/issues/76 Fail2Ban was banning my IP address after the post-du_setup reboot, likely due to some automation I had set up before my server rebuild. A step to whitelist IPs (or suggest whitelisting your current connection) might be nice. I can submit a PR later if desired.

kerem

2026-03-02 02:59:16 +03:00

closed this issue
added the
enhancement
label

kerem commented

2026-03-02 02:59:17 +03:00

Author

Owner

@buildplan commented on GitHub (Nov 16, 2025):

Good idea. I think it happened with me once in testing just checked my notes and I had thought of sorting this but of course forgot. You're more than welcome to PR.
Thanks.

@buildplan commented on GitHub (Nov 16, 2025): Good idea. I think it happened with me once in testing just checked my notes and I had thought of sorting this but of course forgot. You're more than welcome to PR. Thanks.

kerem commented

2026-03-02 02:59:17 +03:00

Author

Owner

@buildplan commented on GitHub (Nov 16, 2025):

Actually maybe it would be good to add tailscale or any other ip address in white list and give user an option to whitelist what they want... what you think?

@buildplan commented on GitHub (Nov 16, 2025): Actually maybe it would be good to add tailscale or any other ip address in white list and give user an option to whitelist what they want... what you think?

kerem commented

2026-03-02 02:59:17 +03:00

Author

Owner

@buildplan commented on GitHub (Nov 17, 2025):

I had a little bit of free time today so added this configurable ignoreip functionality for configure_fail2ban function. I will test it before I merge but if you want check the code and test it. thanks.

@buildplan commented on GitHub (Nov 17, 2025): I had a little bit of free time today so added this configurable ignoreip functionality for configure_fail2ban function. I will test it before I merge but if you want check the code and test it. thanks.

kerem commented

2026-03-02 02:59:17 +03:00

Author

Owner

@buildplan commented on GitHub (Nov 17, 2025):

After testing v0.77 and confirming it all works - now user can add ignoreip and it also shows a little help on how to add more later. hope this will work for you.

@buildplan commented on GitHub (Nov 17, 2025): After testing v0.77 and confirming it all works - now user can add ignoreip and it also shows a little help on how to add more later. hope this will work for you.

kerem commented

2026-03-02 02:59:17 +03:00

Author

Owner

@Kuuchuu commented on GitHub (Nov 17, 2025):

Just finished my version. Made most of it last night, was going to send my PR but my computer decided to freeze so I called it a night. Didn't see you pushed your version until now.

Here is my branch with the whitelist functionality if you are interested: https://github.com/Kuuchuu/du_setup/tree/fail2ban-whitelist

I added a very simple but fully functional IP validator, the whitelisting functionality, and another function to append new IPs (Tailscale) to the ignoreip list.

EDIT: Added support for CIDR notation after seeing yours. Also, IP validation method I am using that I found somewhere on Stack *Exchange should be very reliable in rejecting syntactically invalid inputs:

# Works:
$ ip route get 10.0.0.1
10.0.0.1 dev ens10 src 10.0.0.2 uid 1000
    cache
$ ip route get 254.254.254.254
254.254.254.254 via 172.31.1.1 dev eth0 src 65.21.61.115 uid 1000
    cache

# Fails, as expected:

$ ip route get 254.254.254.425
Error: any valid prefix is expected rather than "254.254.254.425".

EDIT 2: I don't personally use Tailscale, so I am unsure if I am adding the correct IP address with my fail2ban_append_ignoreip "$TS_IPV4" function call in the install_tailscale function

@Kuuchuu commented on GitHub (Nov 17, 2025): Just finished my version. Made most of it last night, was going to send my PR but my computer decided to freeze so I called it a night. Didn't see you pushed your version until now. Here is my branch with the whitelist functionality if you are interested: https://github.com/Kuuchuu/du_setup/tree/fail2ban-whitelist I added a very simple but fully functional IP validator, the whitelisting functionality, and another function to append new IPs (Tailscale) to the ignoreip list. **EDIT**: Added support for CIDR notation after seeing yours. Also, IP validation method I am using that I found [somewhere](https://unix.stackexchange.com/questions/248610/validating-ip-addresses-ipv4-and-ipv6) on Stack *Exchange should be very reliable in rejecting syntactically invalid inputs: ``` # Works: $ ip route get 10.0.0.1 10.0.0.1 dev ens10 src 10.0.0.2 uid 1000 cache $ ip route get 254.254.254.254 254.254.254.254 via 172.31.1.1 dev eth0 src 65.21.61.115 uid 1000 cache # Fails, as expected: $ ip route get 254.254.254.425 Error: any valid prefix is expected rather than "254.254.254.425". ``` **EDIT 2**: I don't personally use Tailscale, so I am unsure if I am adding the correct IP address with my `fail2ban_append_ignoreip "$TS_IPV4"` function call in the `install_tailscale` function

kerem commented

2026-03-02 02:59:17 +03:00

Author

Owner

@buildplan commented on GitHub (Nov 18, 2025):

Thanks a lot for taking time to do this. I should have waited for you to do it. I think we could create a hybrid approach maybe...

I like that your implementation automatically offers to whitelist the IP you're connecting from - very user-friendly.
but some of the things are little complex maybe dependency on ip command may fail in restricted environments.

Would you mid creating a new PR based on latest version to do somehing like ...

configure_fail2ban() {
    print_section "Fail2Ban Configuration"

    local IGNORE_IPS="127.0.0.1/8 ::1"
    local INVALID_IPS=""
    
    # NEW: Auto-detect and offer to whitelist current SSH connection
    if [[ -n "$SSH_CONNECTION" ]]; then
        local CURRENT_IP="${SSH_CONNECTION%% *}"
        print_info "Detected SSH connection from: $CURRENT_IP"
        
        if confirm "Whitelist your current IP ($CURRENT_IP) in Fail2Ban?"; then
            if validate_ip_or_cidr "$CURRENT_IP"; then
                IGNORE_IPS="$IGNORE_IPS $CURRENT_IP"
                print_success "Added your current IP to whitelist."
                log "Auto-whitelisted SSH connection IP: $CURRENT_IP"
            else
                print_warning "Could not validate current IP. You can add it manually."
            fi
        fi
    fi

    # Rest of your existing implementation...
    if confirm "Add additional IP addresses or ranges to Fail2Ban ignore list?"; then
        # Your existing code here
    fi
    
    # ... rest remains the same
}

Would it be ok? I am not sure how to merge this one so a new issue and a new PR would be great if you get some time to do it.

Thanks again.

Edit: I wouldnt worry about tailscale I think by giving user an option to add the ip ranges they can choose to add tailscale ip ranges....

@buildplan commented on GitHub (Nov 18, 2025): Thanks a lot for taking time to do this. I should have waited for you to do it. I think we could create a hybrid approach maybe... I like that your implementation automatically offers to whitelist the IP you're connecting from - very user-friendly. but some of the things are little complex maybe dependency on ip command may fail in restricted environments. Would you mid creating a new PR based on latest version to do somehing like ... ``` configure_fail2ban() { print_section "Fail2Ban Configuration" local IGNORE_IPS="127.0.0.1/8 ::1" local INVALID_IPS="" # NEW: Auto-detect and offer to whitelist current SSH connection if [[ -n "$SSH_CONNECTION" ]]; then local CURRENT_IP="${SSH_CONNECTION%% *}" print_info "Detected SSH connection from: $CURRENT_IP" if confirm "Whitelist your current IP ($CURRENT_IP) in Fail2Ban?"; then if validate_ip_or_cidr "$CURRENT_IP"; then IGNORE_IPS="$IGNORE_IPS $CURRENT_IP" print_success "Added your current IP to whitelist." log "Auto-whitelisted SSH connection IP: $CURRENT_IP" else print_warning "Could not validate current IP. You can add it manually." fi fi fi # Rest of your existing implementation... if confirm "Add additional IP addresses or ranges to Fail2Ban ignore list?"; then # Your existing code here fi # ... rest remains the same } ``` Would it be ok? I am not sure how to merge this one so a new issue and a new PR would be great if you get some time to do it. Thanks again. Edit: I wouldnt worry about tailscale I think by giving user an option to add the ip ranges they can choose to add tailscale ip ranges....

kerem referenced this issue

2026-03-02 02:59:21 +03:00

[PR #1] [MERGED] Test #9

Rows
Columns

[GH-ISSUE #76] Fail2Ban Whitelist Step #1