I'd like to be able to track how much traffic and from which source IPs apiban is actually blocking. I know it's doing a lot of good, but would be great to be able to put that into numbers

I came across https://github.com/influxdata/telegraf/tree/master/plugins/inputs/iptables which appears to do what I'd want - but it looks like theres some things needed in order for it to work with apiban client.

Let's work out whats needed and get some amazing stats

Testing a webhook.

From compuwizz:

I'd like to make a suggestion for a change on the Readme page for the go client. Instead of a generic "Download apibain-iptables-client" put a curl or wget to the raw.github location. It took me a bit to figure out if I needed to clone the repo, or which folder has the current code in it. I didn't realize the client was in the main directory. It would be nice to put the config.json in there too for reference instead of inside a directory

In order to allow more flexible use, it would be nice to separate the REST API calls to a separate package.

Since most modern systems use systemd, we should provide example service and timer units for executing apiban-iptables, rather than just crontab ones.

Rather than committing the binary directly, we should use goreleaser to build the binary and release it under the Github Releases feature. goreleaser is a good tool for this.

Additionally, it would be good to hook up a linter.

To allow greater flexibility to the user, we should allow them to use any arbitrary target chain as the place to send matching entries, rather than always using REJECT.

This would, for example, allow for DROP or for fancier tracking or monitoring chains.

There are some special cases, such as "unauthorized" and "rate limit exceeded" which need to be handled.

Changes from #3 broke the "No IP addresses detected" message, preventing it from firing in that condition.

It would be useful to generalize an interface for an apiban store so as to facilitate more clients and intermediate caching and storage.

Proposing the following definitions:

// Store defines and interface for storing and retrieving entries in the APIBan database, local or remote
type Store interface {

	// Add inserts the given Listing into the store.  Listing may be sparse, requiring only the IP.  Returned value will be fully populated.
	Add(ip *Listing) (*Listing, error)

	// Exists checks to see whether the given IP matches a Listing in the store, returning the first matching Listing, if one exists.
	Exists(ip net.IP) (*Listing, error)

	// List retrieves the contents of the store
	List() ([]*Listing, error)

	// ListFromTime retrieves the contents of the store from the given timestamp
	ListFromTime(t time.Time) ([]*Listing, error)

	// Remove deletes the given Listing from the store
	Remove(ip *Listing) error

	// Reset empties the store
	Reset() error
}

// Listing is an individually-listed IP address or subnet
type Listing struct {

	// ID is the unique identifier for this Listing
	ID string

	// Timestamp is the time at which this Listing was added to the apiban.org database
	Timestamp time.Time

	// IP is the IP address or IP network which is in the apiban.org database
	IP net.IPNet
}

This will set us up to have a pluggable system of stores by which we can make an extensible, pluggable set of client functions.

If there's no APIBAN chain, then there's no APIBAN data ;)

If the chain is added, reset the LKID to 100.

Thanks to @uk-david for finding the issue.

I've been using this on several systems for a while -- the iptables client, that is. I noticed on the last 2 servers I have run it on it blacklists a very small list of IPs, as opposed to earlier when the list was quite long.

Am I doing something wrong? Here's an example where I ran it on a fresh VM and it only blaclisted a single address.

sudo /usr/local/bin/apiban/apiban-iptables-client
root@ip-172-31-34-163:/home/admin# iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N APIBAN
-A INPUT -j APIBAN
-A FORWARD -j APIBAN
-A APIBAN -s 194.88.143.44/32 -j REJECT --reject-with icmp-port-unreachable

We should support additional standard locations for the config file, such as:

• XDG_CONFIG_HOME/apiban/config.json
• /etc/apiban/config.json
• ./config.json
• user-specified location via commandline option

When calling the /check api endpoint and enter any value for ip-address , the API still responds with {"ipaddress":"ok", "ID":"0"} ,

To reproduce the issue you can call this URL https://apiban.org/api/[APIKEY]/check/_.OR.%^_ note am passing _.OR.%^_ as the ip-address here.

You probably you would want to add ipv4 / ipv6 validation to the backend and return more clear error.