1

I'm trying to work out why this keeps crashing my server. Weirdly, the server stays up - but nothing can be reached (FTP, Apache, nginx, emails etc). The script is:

#!/bin/bash
ipset -q flush maltrailoutgoing
ipset -q create maltrailoutgoing hash:net
for ip in $(curl http://127.0.0.1:8338/fail2ban 2>/dev/null | grep -P '^[0-9.]+$'); do ipset add maltrailoutgoing $ip; done
iptables -I OUTPUT -m set --match-set maltrailoutgoing src -j DROP

ALL of these run fine when I do it manually - but as soon as I try and run it as manually as:

bash /root/block-spammers.sh

The terminal locks up, and then kicks me off SFTP , browsers etc.

http://127.0.0.1:8338/fail2ban

This command just returns stuff like:

123.123.123.1234
234.234.234.234
i.e one IP per line

Can anyone see why this would fail? I'm baffled as to why it keeps killing my server :/

OS: Ubuntu 18.04

UPDATE: As suggested, I have added an ACCEPT rule, to bypass our own IP:

iptables -A INPUT -s 213.168.249.115 -j ACCEPT

I'm not sure why that would help, but it seems to (I can't see our server IP, 192.0.0.x or my own IP in the list, so pretty sure its not blocking me)

Andrew Newby
  • 1,102
  • 2
  • 25
  • 58
  • 2
    Matching on IP source address in OUTPUT chain doesn't make a lot of sense. But it in no way explains your problem unless one of the addresses is your own IP address. – Tomek Oct 02 '20 at 17:14
  • 1
    Add an explicit rule that permits your traffic that is before the drop rule. – Zoredache Oct 03 '20 at 02:18
  • @Tomek the logic is that I'm trying to stop myself from accessing sinkhole ips, that keep getting our IP blacklisted for a spidering project. All above board, but we are using WHOIS data and this includes domains that we don't want to spider as well – Andrew Newby Oct 03 '20 at 05:44
  • @Zoredache thanks - that did the trick :) `iptables -A INPUT -s 213.168.123.123 -j ACCEPT` if anyone comes across this in the future – Andrew Newby Oct 03 '20 at 05:44
  • 1
    @Andrew Newby, per your comment, you probably should match against destination IP: `iptables -I OUTPUT -m set --match-set maltrailoutgoing dst -j DROP`. – Tomek Oct 03 '20 at 08:01
  • @Tomek interesting. I wasn't aware of the "dst" setting. Is it worth doing it on both? Or one-or-the-other? – Andrew Newby Oct 03 '20 at 08:28
  • 2
    For me I usually look at src IP in INPUT chain and it makes more sense to look at dst IP in OUTPUT chain (and FORWARD could look at either or even both). You should have a look at `iptables` and `iptables-extensions` man pages and the possible combinations you can use with `--match-set` and different set types. – Tomek Oct 03 '20 at 17:13

0 Answers0