Banned My IP address - I think this is a bug?

snowweb

snowweb

Verified User
Joined
Aug 31, 2007
Messages
144
Location
Antipolo City, Rizal, Philippines (a British Natio
Hi, I've just installed DA on a VPS.

I then logged in and tuned the settings to my liking. I set the number of failed logins before blocking the IP address, to 5.

I then left it for probably 2 hours and I guess my login had timed out by the time I returned, although a page was still displayed in my admin control panel.

At that time I hadn't considered my login status, so went to continue in the control panel where I left off. However, I noticed that as I moved my mouse across the icons (Home, Webmail, Passwords, etc), where the icons would normally flip, they didn't but just changed to 'missing image'. At first I was concerned that there was a server problem, so I tried hovering over the other images also and found the same thing.

I'm wondering whether DA was counting those attempts to download the images as failed logins? Because when I then clicked one of the links it went directly to the blank page.

I have never had even one failed login on that server! Nobody else is sharing my IP address and now I guess it's blocked!

If I ever get back in, the first thing I plan to do is disable that!

My question now is, how will I get back in? Is there a file that I can edit through SSH, to remove my IP address?

If so, where?

Thanks

pete
 
chatwizrd said:
http://directadmin.com/features.php?id=705
Click to expand...

I understand that, but the point is, something is wrong. The option is clearly labeled as blocking an IP address after a specified number of failed logins. The fact is, I didn't have even one failed login!

In fact, I believe my IP address was probably entered in the blacklist before I had even clicked on a link in the existing page, simply because I hovered over some (swap on mouseover) images which are not accessible if your session has timed out.

I like the feature and would love to use it, but I can't use it while it's doing this. And I can't add my IP address to the whitelist because my IP address at home changes roughly every 3 days.

I'll just wait and use it again if ever I notice in the changelog that it's been fixed. Overall I love DA though and wouldn't go with another system for world!

:)
 
Every time the login screen is refreshed it counts as a bad login.

Jeff
 
No one else has recorded this as a bug. I'd think if it were, lots of others would be reporting it.

If your license includes support you might want to contact DirectAdmin support.

Jeff
 
I have just had this issue, I cannot login to DA now, I had already added my IP to the Whitelist as well, Also one of my clients keeps having this issue as well, I have to repeatedly remove his IP from the blacklist,

As soon as we login the screnn does something then goes stright to Page cannot be found.
We do not refresh the page, its not a lost password issue either. It just happens. Its
happened to me about 4 times since the last update of DA but my client has had the
issue for about a year now, Although he said he has changed something on his computer
with regards to his IP and network connections and he says he dont have the issues
anymore, I cannot do this as i have a router and its not possible!

My problem is now, How do i remove myself from the blacklist if i cannot access Direct Admin? I am baffled though as my IP is in the whitelist as was my clients IP address.....

I have and can access SSH
 
hello buddy,

I managed to gain access again by using a web proxy. Search google for "web proxy". You're looking for a page where you can enter your admin URL in the address field and the web site will then use it's own IP address to access your admin area.

Make sure that the proxy you use supports cookies. Make sure you get your login right first time too, or you'll blacklist the proxy too!

Also make sure that you change your admin password after wards as it is possible for the proxy owner to harvest your password etc.

When you get in, make a beeline directly to admin settings to disable the offending feature until it's fixed.

Good luck,

pete
 
Hi Pete

I really Appreciate your help, I have found a proxy that worked and im just about to disable
that feature, thanks again...
 
Is it this feature that your on about? Blacklist IPs for excessive login attempts
If so will it cure the problem, the reason i am asking is because it didnt even need
an invalid login to block me, it just did it!

Also whats more baffling is the Whitelist does not work at all :(
 
bashy said:
Is it this feature that your on about? Blacklist IPs for excessive login attempts
If so will it cure the problem, the reason i am asking is because it didnt even need
an invalid login to block me, it just did it!

Also whats more baffling is the Whitelist does not work at all :(
Click to expand...

Glad you got back in. I'm not sure about the whitelist, as I've not tried it yet, since I'm on a dynamic IP, but regarding the blocking of excessive failed login attempts; it would appear that this bug appears if you are using the default theme, which swaps images on rollover.

When I first installed DA, I had more important things to setup, before selecting a better theme, so I was using the default, graphically enhanced theme. I set the excessive failed login attempts, to 5, believing that it was highly unlikely, that I would ever experience more than one typo in a row, during login.

I leave DA open in a tab in my browser, all the time and sometimes, my session times out while I'm away, although you wouldn't know that it had, until you try to refresh the screen. It would then go to the login page. This is fine.

However, if when you return to your PC, instead of refreshing the screen, or following a link, you idly move the mouse, enjoying the rollover effects on the images (while you chat on the phone, or something), each time you rollover an image, the server blocks the 'on' image from being accessed, due to you not being logged in. It marks this as a failed login! (yeah, I know it's a bit harsh) but wait, the worse is yet to come... after you have rolled over it (or other images), 5 times - you're blacklisted! (and my wife says I'M a disciplinarian!)

Chances are, it might be ok to use this feature with themes that don't use rollover images, but just to be safe, I have set the failed login attempts to '100' now. It will still be effective against a brute force attack.

Hope the extra info helped.

Regards, pete
 
Last edited:
Thanks for the detailed description snowweb.

Yes, the images require you to be logged in to view them.

DirectAdmin does force the browser to *not* cache any of it's pages, meaning if you click "back", a new page should be retrieved, not the cached one. This will enforce the login.

If the browser ignores that "forced update" and uses a cached html page, but *doesn't* use the cached images, then there would be a high likelyhood of you getting blacklisted, since each image would be a login hit.

The "roll-over" one is also a bit odd to me.. the images are downloaded with the page when it loads, so I'm not sure why a browser would decided to go get them again.

In any case, we cannot always predict what a browser will do.. the job of the daemon is to accept the fact that things may not always go as planned ;)

I've gone through the code in DirectAdmin that controls the sending of entire files. There is a cache timer set in the headers which I can control either way. Right now it's set to 65536 seconds... so I'm guessing that's the issue with the roll-over right there.. which is equivalent to 18.2 hours. (note this is only for entire files, this is not passed with the DA generated html pages, which are not allowed to be cached). So what likely happend, is you left your browser open for more than 18.2 hours, moved your mouse over, the browser decided to update the images from the server, and with the low blacklist setting, you'll get blocked.

So I could make this numerical value lower.. but if you leave the browser open for more than 18.2 hours, you'll still be screwed. The only real solution is to set this cache timer to "unlimited"... but then that's bad because then the images, should they ever change, you'll still be looking at the cached value, which would caused confusion (note the filemanger file downloads uses this too, which can be changed of course)

So there really isn't a great solution for this issue.
Setting the brute force counter high enough to prevent it is probably one good option. I'm not sure about the rollover code, maybe someone has a nifty way of telling the browser never to redownload the images since the html hasn't been changed. And of course, don't leave your browsers open for more than 18 hours ;)

Other suggestions are welcome if there are any.

Setting it lower will only make it worse.
Setting it higher will confuse people as they'll get incorrect data for images and their own files in the filemanager when they change.
Removing the rollover is one option, but perhaps there is another way of doing it (flash, etc)

John
 
Thanks for that detailed report John. Sounds like you checked all bases. I think your suggestion of using a different method for the rollovers sounds like the most workable one, although I must admit that I don't understand why pre-loaded images are still accessed on the server on rollover? Maybe there is a fault in the pre-loading script?

To the best of my knowledge, pre-loaded images should remain in the cache, at least until the page is next reloaded so it would seem to me that they were not pre-loaded successfully... this is just my diagnoses based on my limited knowledge.

Thanks again John,

pete
 
This reply may be a red herring; hopefully someone with more knowledge/experience than I will chime in:

I always thought that cacheing is never done for images if the connection is done over https, so perhaps checking to see if that's part of the problem may be in order.

(No, I don't recommend running DirectAdmin insecurely; I'm just bringing it up as a possible part of the problem.)

For what it's worth, I use the enhanced theme for all domains which I control, including those used by admin. I leave browsers open (sometimes) for days at a time on multiple desktops (I use firefox on Linux), I've seen rollovers try to reload images (and fail) because I've been logged off by some kind of internal DA timer, and I've never been locked out.

I can't tell you what more I'm doing differently than you are; I just don't know.

Jeff
 
What I have done in my own software that I have written is set up a meta refresh so that when the login times out it also refreshes to the login screen. If DA used this method then there will be no chance of somebody accidentally rolling over the images.

In fact this can already be done at the skin level.
 
jlasman said:
This reply may be a red herring; hopefully someone with more knowledge/experience than I will chime in:
Jeff
Click to expand...

LOL - I think we'll be waiting a long time for that Jeff (unless of course John show's up again)!

I always thought that cacheing is never done for images if the connection is done over https, so perhaps checking to see if that's part of the problem may be in order.
Click to expand...

Good point too. Actually, I noticed in Firefox 3, the option to cache secured pages (but it may have been an installed pluggin that gave that option. Either way, I didn't choose that option. However, this incident happened to me on day two after getting my VPS and I had not yet installed https. The the images should have been stored.

I've seen rollovers try to reload images (and fail) because I've been logged off by some kind of internal DA timer, and I've never been locked out.

I can't tell you what more I'm doing differently than you are; I just don't know.
Click to expand...

Hmm... that's interesting. Maybe your threshold for number of failed logins is set higher than mine was (5)? I'm assuming of course that the option to blacklist after X failed logins was checked.

Maybe this would solve the problem. How about if the images were referenced something like this:

HTML: 
<img src="http://{serverip}/da/images/">

so that they circumvent the https and they circumvent the directory where access is denied due to a timeout?

Regards

pete
 
snowweb said:
LOL - I think we'll be waiting a long time for that Jeff (unless of course John show's up again)!
Click to expand...
Actually I don't even write my posts; I have a few million monkeys working for me and I just find the random stuff they've written that appears to answer the question, and I cut and paste it in. I'm still training monkeys to do that as well, but it's not easy :D.
Good point too. Actually, I noticed in Firefox 3, the option to cache secured pages (but it may have been an installed pluggin that gave that option. Either way, I didn't choose that option.
Click to expand...
I'm not yet using FireFox3; I will as soon as I update our linux desktops to a newer distribution (we're still on Mandriva 2008 LE), probably next month. I currently can test on only Konqueror, FireFox2, and on Opera 9.24.
However, this incident happened to me on day two after getting my VPS and I had not yet installed https. The the images should have been stored.
Click to expand...
You are correct.
Hmm... that's interesting. Maybe your threshold for number of failed logins is set higher than mine was (5)?
Click to expand...
Nope. Where possible we use DirectAdmin standards, as it helps us understand our clients' problems.
I'm assuming of course that the option to blacklist after X failed logins was checked.
Click to expand...
Yes, see above.
Maybe this would solve the problem. How about if the images were referenced something like this:

<img src="http://{serverip}/da/images/">

so that they circumvent the https and they circumvent the directory where access is denied due to a timeout?
Click to expand...
If you don't use port 2222 you're using Apache to serve pages. DirectAdmin has it's own built-in browser for the User Interface; it doesn't use Apache.

So yes, that might eliminate that problem.

However, it would cause another.

Every browser I know of (except older Microsoft browsers) reports pages of mixed secure/insecure items in some way. Not a great way to inspire consumer confidence.

If the problem is indeed the timer, then set the number higher; perhaps much higher, as most attempting an attack won't stop at 5, or 10, or even 100 tries.

And of course (especially for your admin accounts) use very secure passwords that a cracker won't guess; the DirectAdmin password generator and mine are very similar and both create secure passwords.

Jeff
 
You must log in or register to reply here.
Back
Top