Zadius Sky
The Living Force
Jefferson said:
Same here.
server Issues / Can't access SOTT
- Thread starter salinafaerie
- Start date
Same here.
OH MY GOD I'm going to puke.
Server people responded:
Last night, they told me they disabled IPMI, and that someone had changed the IPMI password. They have finally acknowledged that yes, there is this iKVM screen, but now they want to blame it on DNS, which is idiotic, because if you simply go to the IP of the SOTT server in your browser, you get the same iKVM screen. Since CloudFlare does NOT handle this, it MUST be a problem on their end.
So, I now pointed this out to them.
This means they didn't even read my first support request, which was all about WHY this iKVM screen was there.
Server people responded:
Last night, they told me they disabled IPMI, and that someone had changed the IPMI password. They have finally acknowledged that yes, there is this iKVM screen, but now they want to blame it on DNS, which is idiotic, because if you simply go to the IP of the SOTT server in your browser, you get the same iKVM screen. Since CloudFlare does NOT handle this, it MUST be a problem on their end.
So, I now pointed this out to them.
This means they didn't even read my first support request, which was all about WHY this iKVM screen was there.
Yeah, I haven't been able to load sott all day. Sounds like the hosting support team is quite incompetent? Overworked, underpaid, and unqualified?
And I DO agree that not having access to SOTT is causing heavy withdrawal symptoms.
And I DO agree that not having access to SOTT is causing heavy withdrawal symptoms.
trendsetter37
The Living Force
Does your host use an ISP that has to also go through the ISPs DNS? Or is that totally not the issue?
I have seen that one can alter client or server DNS or if both of those are inaccessible one could change records in a ISP DNS if they had the means to do so. Which would render both parties (domain registrar and webserver) powerless in resolving the communication issue.
The only way to test that theory is to move the site to a totally new host or someone's personal webserver and use a temporary domain name pointing to the new webserver address.
But I guess all that would only tell us something we already know which is that something smells fishy? Wait have we tried using a totally new domain name pointing to the correct or new hosting location and then redirecting sotts domain through the new domain which would have a clean connection? That way if something doesn't work we could get feedback from the registrar as well?
If this is totally off the mark let me know as my expertise comes only from watching a couple of YouTube videos.
I have seen that one can alter client or server DNS or if both of those are inaccessible one could change records in a ISP DNS if they had the means to do so. Which would render both parties (domain registrar and webserver) powerless in resolving the communication issue.
The only way to test that theory is to move the site to a totally new host or someone's personal webserver and use a temporary domain name pointing to the new webserver address.
But I guess all that would only tell us something we already know which is that something smells fishy? Wait have we tried using a totally new domain name pointing to the correct or new hosting location and then redirecting sotts domain through the new domain which would have a clean connection? That way if something doesn't work we could get feedback from the registrar as well?
If this is totally off the mark let me know as my expertise comes only from watching a couple of YouTube videos.
Psalehesost
The Living Force
Mr. Scott said:This means they didn't even read my first support request, which was all about WHY this iKVM screen was there.
Maybe it's time to look for a new host, so as to avoid more of the kind in the future? If you already know of a good alternative, and have a fresh backup on hand, then maybe getting SOTT up and running on a different host could even be quicker than waiting for this to be resolved.
IncenDiary
Jedi
Great...... - http://digital-era.net/vulnerabilities-in-ipmi-protocol-have-long-shelf-life/
IPMI runs regardless of the underlying operating system and operates on UDP port 623 through a server’s network port or its own Ethernet port. It runs continuously [...] unless the plug is literally pulled.
The worst vulnerability is the RAKP authentication remote password hash retrieval bug. The authentication process here mandates that the server send a salted SHA1 or MD5 hash of the password to the client before authenticating it. An attacker can steal this hash, and brute-force attack it offline.
“Unfortunately this means that even if you’re on the ball and up-to-date with your patching, have all known security problems fixed, and everything is working as planned, if an attacker can guess a valid account name they may get its password hash and crack your password without you knowing it,”
Something else I remember reading is that it doesnt matter what characters you use in a password ( @ , % , etc) but rather the LENGTH of the password used. So, for example, MYLEFTLEGISLONGERTHANMYRIGHTLEG is a waaaaay better password than M#L1![\^&$*='" ....
IPMI runs regardless of the underlying operating system and operates on UDP port 623 through a server’s network port or its own Ethernet port. It runs continuously [...] unless the plug is literally pulled.
The worst vulnerability is the RAKP authentication remote password hash retrieval bug. The authentication process here mandates that the server send a salted SHA1 or MD5 hash of the password to the client before authenticating it. An attacker can steal this hash, and brute-force attack it offline.
“Unfortunately this means that even if you’re on the ball and up-to-date with your patching, have all known security problems fixed, and everything is working as planned, if an attacker can guess a valid account name they may get its password hash and crack your password without you knowing it,”
Something else I remember reading is that it doesnt matter what characters you use in a password ( @ , % , etc) but rather the LENGTH of the password used. So, for example, MYLEFTLEGISLONGERTHANMYRIGHTLEG is a waaaaay better password than M#L1
Ellipse said:
The only port I can get to work is for SSH, but when the iKVM screen is showing, the normal SSH port doesn't work, and the default port of 22 is open (it's not normally). When I try to log in, it's very obvious that I'm not logging in to the SOTT server, but something else.
That's using SOTT's IP address, not the domain name.
It's possible there is some malware on the server that kicks in and redirects everything seamlessly, and changes all ports and everything a few minutes after boot, but this seems less likely than a routing issue.
Thomas Alan
The Living Force
I'm still getting the ASUS login screen as well. Interesting, this morning my Internet provider Time Warner cable was down for a few hours as well. So I had no Internet at all. Odd "coincidence".
Thanks for you work, Scottie. No one covers the news like SOTT!
Mac
Thanks for you work, Scottie. No one covers the news like SOTT!
Mac
IncenDiary
Jedi
But now what about the contents of the site? Is that backed up? Cause if your luck is anything like mine they're gonna go "oops sorry are you SURE you had content on your server?" kinda thing ...
