invalid CONSOLE login attempts not considered in IP blacklist ?

[kwen1x]

Hi,

I see the eventlog that is (over)loaded with 30037 events: User or password is invalid from .. (3CX Phone System Management Console).
Console access has been restricted to limited list of IP addresses, yet console page is still 'accessible' from internet ??
However, if I try to connect with VALID admin credentials, the connection is refused.
Seems odd 'implementation' of this IP restriction option.

Furthermore an event 30037 is logged when INVALID credentials are detected, yet these attempts do not result in the IP address in question being put on the IP blacklist ??
Only events 12290 (as far as I've seen) trigger their IP address being added to blacklist...

Why not blacklist illegal admin console attempts ?

 

[Alphabetic]

It's morethanlikely they're not hitting your threshhold for failed login attempts.

 

[kwen1x]

Thanks for the suggestion kieferschild, but I lowered the lockout treshold to 2 attempts, were I saw that even the attempts were more then what the default threshold (3) was.

It seems to me these 'attempts' are simply NOT taken into account.

It used to be that the console restrictions forced nginx to spit out some kind of error page, but this release xx this has changed into a valid login page that is presented (but where valid logins are refused when IP address not in whitelist), which opens the window for these fraudulent login attempts.

You can try for yourself and try to login x times with wrong console password from IP address that is not in the console whitelist: you will see...(I hope)

 

[Alphabetic]

Update..

Make sure that youre not testing this anti-hack feature from an IP that is in your allowed list for MGMT console.

If you set your MGMT console restriction to access from anywhere then the desired result is acheived.



If you lock down MGMT console to IPs then these attempts from non-allowed IPs arent registered at all.

 

[kwen1x]

thanks for testing this.
Can you confirm what your threshold is ?

 

[Alphabetic]

I set mine to 5

 

[kwen1x]

which is default IP list, yet I get all of these..



something wrong in nginx config ?!

 

[kwen1x]

running v18.0 (Build 908)

 

[kwen1x]

nginx settings (nginx.conf in /var/lib/3cxpbx/Bin/nginx/conf folder) don't seem in sync with gui ?
nginx should return an error 403, as far as I can read confg..
Or am I reading wrong setting ?

 

[jpluimmm]

I am have the same problem. My console restrictions are allowing access from internal network only.
Same version of the software v18.0 (Build 908)
I have manually blocked the IP's, that silenced for now.

 

[Soren]

I also have this problem and have restricted IP and still receive a lot of attempts.
When I try to connect from another IP I'm blocked, but still other doesn't get blocked.

 

[RichB]

I'm also on Update 6 and have console restrictions for specific IP addresses set but am able to browse the login page from external addresses outside of the allowed ranges and the event logs show that other can as well.

 

[RichB]

The Management Console login page loads but you can't login, you might expect the page not to load at all. The event log reports failed login from the webclient but this is possibly misleadingly as it appears that those attempts were the Management Console.

 

[RichB]

3CX, I understand this is probably based on the service but it would be good if it could distinguish between Management Console and Webclient.

 

[JohnS_3CX]

Console restrictions were designed to allow you to reach the login prompt, but nothing you enter will work.
It should not return 403.

The anti-hacking module is for SIP attempts, not for web login.

If your goal is to protect the management console login, then use stongs passwords, and enable console restrictions.
The attempts will always appear, but they will of course fail.
Just make sure you don't lock yourself out!

 

[rjamesm2884]

Noticing a lot of fail attempts same IP address as above. They are hitting several consoles with failed passwords.

 

[kwen1x]

>>The anti-hacking module is for SIP attempts, not for web login.
Then this should be clarified in interface...
Hacking is hacking (for me), be it on SIP attempts or console login.
From security perspective it would be more sensible to handle BOTH cases, no ?

 

[kwen1x]

Console restrictions were designed to allow you to reach the login prompt, but nothing you enter will work.
It should not return 403.

The anti-hacking module is for SIP attempts, not for web login.

If your goal is to protect the management console login, then use stongs passwords, and enable console restrictions.
The attempts will always appear, but they will of course fail.
Just make sure you don't lock yourself out!

Strange though that this thread started with a reply from user 'kieferschild' indicating that IP blacklisting for console attempt IS working on his side ?!
This would suggest console 'attacks' were at some point in time part of the IP blacklisting mechanism but were dropped in some version ?
Looks more then like a bug to me...

 

[rjamesm2884]

Strange though that this thread started with a reply from user 'kieferschild' indicating that IP blacklisting for console attempt IS working on his side ?!
This would suggest console 'attacks' were at some point in time part of the IP blacklisting mechanism but were dropped in some version ?
Looks more then like a bug to me...

I agree, why would you drop IP blacklist to the console? This should a a global feature, there are constant attacks across all of our hosted instances.

 

[JohnS_3CX]

I agree, why would you drop IP blacklist to the console? This should a a global feature, there are constant attacks across all of our hosted instances.

I think that's a wrong assumption there, never said that we dropped MC blacklisting.

It worked before, and it still works in U6 - Just go ahead and try it on a U5 and a U6 and you will get blacklisted on both occasions.