IP banning

a_5mith

Reloading nginx is something that can be worked around, and only happens say, once every now and then.

Modern proxies (including free ones) are very good at getting a new IP address. Failing that, disconnecting and reconnecting would also get you a new IP address on software based proxies (VPNs etc)

Automated attacks are slightly different, it depends on the attack, if it's one user being a nerd, then I would IP ban them in nginx. If it's a ddos attack, then there's no way I could prevent this using software as by the time theyd reached the software, the connection would already be bottle necked and the best course of action at that point would be damage control. Not prevention.

dwn

So there's obviously something getting lost in translation here... I work in security, I know how proxies and botnets work very well.

@a_5mith said:

Reloading nginx is something that can be worked around, and only happens say, once every now and then.

Not if I've got a net of 20k coming at you. I can stagger them so that your reloads alone(if automated) interrupt service for users for a significant period of time or cause significant annoyance.

Modern proxies (including free ones) are very good at getting a new IP address. Failing that, disconnecting and reconnecting would also get you a new IP address on software based proxies (VPNs etc)

So, the modern internet has the concept of "IP Blacklists." You are not going to find a proxy quickly that is not already on one of these lists. VPNs have a very limited pool of addresses that they pull from.

Not that this matters to any remotely sophisticated attacker: their proxy lists will be from a botnet they control(still going to be a fairly limited pool), or a scan of a large swath of the ipv4 address space that they performed at an earlier time(prob < 1k working from this). The average kid you'd IP ban doesn't have access to this kind of thing, though.

Automated attacks are slightly different, it depends on the attack, if it's one user being a nerd, then I would IP ban them in nginx. If it's a ddos attack, then there's no way I could prevent this using software as by the time theyd reached the software, the connection would already be bottle necked and the best course of action at that point would be damage control. Not prevention.

So ddos is a terrible generic term. It can mean a LOT of things.

The case you described is a bandwidth based DDoS which is actually sorta rare when it comes to them(solutions like cloudflare help prevent bandwidth-based and other simple DDoS methods very well).

The type of DoS that nothing but the application can help you with will take advantage of requests that trigger slow-running or resource intensive code paths. It turns out there's a lot of these and really no external tools that can help you in a websocket-based application. This kind of DoS can be done via a single IP at a time as they don't usually take a lot of bandwidth (of course if you ban one IP it's trivial to automate having another bot continue the attack). They are not complex attacks.

You've got to look for these and stop them at the application layer. This is done via behavioral/attack pattern analysis. If you know a certain code path will easily DoS your site, you can block these attacks via code -- it's very simple. If the software doesn't give you an easy way to programmatically ignore traffic from a certain address/range, you're sort of left to ratelimit everyone(which sucks).

This is just one kind of attack. IP banning applies to a myriad of attacks and is really something necessary for the application to be able to do.

Peter-Zoltan Keresztes

Why don't you do that on firewall level. If you don't want to add rules manually try fail2ban

dwn

@Peter-Zoltan-Keresztes said:

Why don't you do that on firewall level. If you don't want to add rules manually try fail2ban

Here's a UX example: What if someone's on an IP blacklist? Timing out their connection to the site is a terrible UX compared to a static page saying they are IPbanned.

Scuzz

I would also like some type of IP banning and Search user by IP function.

julian

@Scuzz said:

I would also like some type of IP banning and Search user by IP function.

This is coming

? Offline

@julian said:

This is coming

Just like that, one of my plugin ideas got a lot more simple. And that, my children, is why we wait on @julian to make the magic happen.

julian

@Ted Thanks haha... although the kudos should go to @baris, who handled the updates to the user search field in the ACP

PitaJ

@dwn I would create a node.js layer on top of the NodeBB layer that detects current traffic and denies passthrough to anyone on a black list

julian

@dwn said:

Here's a UX example: What if someone's on an IP blacklist? Timing out their connection to the site is a terrible UX compared to a static page saying they are IPbanned.

Are you saying if the user is on an IP blacklist that I put him/her on? Then in that case, I'd say they deserve it, and I wouldn't need to put extra effort into displaying a nice HTTP 400 page.

In terms of false positives, that's an other issue altogether.

dwn

"IP Blacklist" as in a spam/malware blacklist. These are lists that security-conscious owners would naturally block, but occasionally contain innocent infected users.