12place
AAISP Ideas All the ideas and discussions
62 votes Vote

specify firewall rules to block IPs on the internet side of ADSL link, rather than on the consumer side, using an API that can be interfaced to local snort/fail2ban-like functionality

At the moment IPs can be block (only on test LNS?) when requested. So there's a manual step in the "detect IP senidng too much undesired traffic... cause it to be blocked" process. It would be cool if that could be automated so that the blocking is under customer control, but its on the far side of the ADSL (and hence the far side of unit utilisation and bandwidth utilisation)

benc , 03.06.2011, 14:07
Idea status: under consideration

Comments

mjwensley, 18.03.2012, 23:43
When I had this situation, I resorted to stop IPv4 service completely on pppd with “noip” (leaving IPv6 running) rather than shutdown my line for the day, until the source could be added to the test filter.

It will be useful to specify the addresses not wanted in the pppd login or some parameter such as 192.0.2.2/32,192.0.2.0/32-test@a so that line peace can be restored prior to sending the abuse report to the source.
Reply
Owen Smith, 16.10.2015, 11:32
I'd find this useful too, I run a server at home and I have 13 blocked IP addresses in it's config to block abusive users. It would be much better if I could do this at the AA end so that the blocked traffic does not consume any capacity or data on my line (puny slow ADSL).

Personally I would want web browser based control of this in the control pages for my line, just like the line profile, DNS entries and CQM monitoring etc.
Reply
Cecil Ward, 08.11.2015, 15:29
Strongly approve of this. It would be nice to have a tool (ideally partly in xslt, so that it could be customised more easily) to extract certain appropriate basic fire-walling rules from a user's Firebrick config and push this to the ISP-side firewall.
Reply
Cecil Ward, 29.11.2016, 09:56
Any progress on this? This would be so great, especially for those of us who are being charged for inbound evil that we can't control or may not notice in time.
Reply
Cecil Ward, 29.11.2016, 10:11
It would be fine to make this an extra-cost option, imho.
Reply
Richard, 20.07.2018, 09:06
If this is for a web server/site based on your ISP connection. A CDN would give you this for free in some / most cases via ACLs. Plus the "bad actor" would not see DNS A records pointing at your home IP if you used the CDN's A records which adds another level of protection (through obfuscation)
Reply

Leave a comment