• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

smoothwall sending millions of packes to 203.7.*.*:22

Red Squirrel

Red Squirrel

No Lifer
This is really messed up. At random, my LAN totally took a dive. It started with just the internet, so I figured it was maybe my p2p VM that started actually downloading stuff, but it was not that. Everything was just queing as usual (I have rediculous bad luck with p2p) so I just turned it off anyway. Still nothing. Resetted modem, switch, and router. Nothing.

So I decide to check my router's connections, and there are thousands and thousands of active connections to 203.7.*.*:22 from my smoothwall's outside interface. I shut down all VMs behind the smooothwall to rule out that its the VMs acting up. Still doing it. I do tcpdump and it just completly spams to those IPs. It's a minimum Linux distro built for a firewall so I really can't see how it would of been hijacked. That firewall is also behind a physical router, only port 22 is forwarded to it. (ironic...)

Not sure what else this was doing, but it was enough to take down my entire LAN, let alone just slow down the internet... Anyone ever hear of this happening?
 
If you had port 22 open, I bet someone just guessed your password and logged into the router via ssh. From there they would have free access to your network 🙂

How strong was your password? Did it include numbers, letters and symbols?
 
Your firewall/OS has been compromised. Time to reformat/reinstall.l

-edit-
It looks like your box is hunting for open SSH sessions. Most likely gathering information about them and sending them somewhere. If it's scanning the entire 203.7 range then that means it's a bot or a worm.
 
Just curious, why not run ssh on a nonstandard port? Granted it's probably not common for someone to crack/guess your password, but at least it's some extra security.
 
I actually had that before best to set it back... But first I need to figure out how they got in, AND who it was so I can get the police involved. Any known openssh exploits right now that enable to bypass authentication? That firewall has been up for no longer then 24 hours so doubt it was a brute force. The password is very long and complex and has never been used in non encrypted situations.

I turned it off for now...
 
Originally posted by: BZeto
Just curious, why not run ssh on a nonstandard port? Granted it's probably not common for someone to crack/guess your password, but at least it's some extra security.
Click to expand...
It's way easier to find ssh running on a non-standard port then it is to crack a good password remotely. Public key auth ftw.
 
yeah thats another thing I'll setup.

Anyway is there a way to figure out what commands where typed and stuff? Like a history? Though it looks like they deleted any evidence.... theres not even a single file in /root and /var/log/secure is pretty much empty.
 
Originally posted by: RedSquirrel
I actually had that before best to set it back... But first I need to figure out how they got in, AND who it was so I can get the police involved. Any known openssh exploits right now that enable to bypass authentication? That firewall has been up for no longer then 24 hours so doubt it was a brute force. The password is very long and complex and has never been used in non encrypted situations.

I turned it off for now...
Click to expand...
They're probably in asia somewhere so there'd be little use of getting the police involved. Even if you found where they were sending the results back to, that could be a hacked machine belonging to somebody else too. Besides which, they've barely done you any harm.

Do you have any services besides ssh exposed to the internet on this machine?
 
I actually figured out more what happened.

My setup is this:

|> indicates nat | is out > is in

NET====[1]=|>====[2]=|>===SSHGATEWAY

router 1 has port 22 forwarded to router 2 and router 2 has it forwarded to ssh gateway. When on SSHGATEWAY theres not much you can do. You can go out on only a few ports, though 22 is one of them. So my internal network was fairly safe unless they got into my LAN server's SSH though so far it does not appear they did. This looks like an automated attack.

I still don't get how they managed to crack that password though. They were also trying all sorts of users, "asia" being one lol, so yeah this comes from china (actually, japan, but all same thing to me 😛)

IP 211.9.37.62


So that said, is there a way to lock out IP ranges if it fails to authenticate about NN tries? Like I'd want to have it block for maybe 24 hours, or maybe even permanently.



Funny since I was going to image those VMs for quick restore in the event of data loss or what not but never did.... I should have.... I can't seem to find anything on there but not taking chances. I just discovered they actually never got on as root, it was a regular user that I was using for testing and never reset the password. Was public/public. DOH. So my guess is all those queries were being done from within the ssh session, and nothing actually got installed. But I'm not taking any chances.
 
This is why public key auth is good 🙂 You disable password auth, never put a key in the test user's authorized_keys and just su from other accounts. Of course, not keeping a bogus account with a simple password on an internet facing machine is more important 😉

You can look at MaxAuthTries and MaxStartups in sshd_config which is not extremely powerful but is a start for brute force blocking. There are numerous other solutions out there, none really pretty, but some will probably do quite well. They generally either revolve around using a firewall to limit connection rates or analyzing log files for repeated failed authentication attempts and banning the associated ips.

Personally, I just let them bash themselves against my server. The only reason to implement brute force prevention is to keep the logs clean 🙂
 
Hmmm so ssh has no way built in? since I was also thinking just have a program check the logs, but figured sshd would have its own feature. I'll defiantly move it to a non standard port, then implement some kind of lockout and think about also using pub key auth + password. (so need the key AND a password)

This could have been a hell lot worse, at least this is a non production machine. And the fact that it was a silly test account means they did not know the root password so could not do as much damage. Also a good reason to not allow root logons. Though they can just try to su anyway but then its 2 passwords to try and guess.
 
Originally posted by: RedSquirrel

They were also trying all sorts of users, "asia" being one lol, so yeah this comes from china (actually, japan, but all same thing to me 😛)
Click to expand...

What log file did you check to see that? I'd like to take at look at mine.
 
/var/log/secure

Though think this differs from system to system.

Sadly I lost everything in an unrelated HDD failure, as I was wanting to investigate this further just for educational purposes. Oh well, this forces me to reformat everything. and not be tempted to think its safe to put those systems back online. 😛
 
That is.... scary. Thats something you'd see in Windows and IE, but never expected that in Linux. From looks of that its Debian specific but thats still super bad. Means it affects Ubuntu which is a major distro, and even used for servers. So for example this is a huge risk for shared hosting environments that provide ssh access to their users.
 
Originally posted by: RedSquirrel
That is.... scary. Thats something you'd see in Windows and IE, but never expected that in Linux. From looks of that its Debian specific but thats still super bad. Means it affects Ubuntu which is a major distro, and even used for servers. So for example this is a huge risk for shared hosting environments that provide ssh access to their users.
Click to expand...

Many of us remember "the worm".

Just because it's unix doesn't mean it doesn't have bugs. All software and operating systems have bugs.
 
True just did not figure Linux got to point of having privilege escalation like MS is known for. This is a very serious exploit. And its been a while linux is around and they only found this now.

And I read "There is a security hole in all versions of linux-2.6 distributed by Debian," wrong then. So guess they just mean all 2.6 period.
 
And I read "There is a security hole in all versions of linux-2.6 distributed by Debian," wrong then. So guess they just mean all 2.6 period.
Click to expand...

That's because it was the Debian bug report, other distributions likely have similar wording in their reports.
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top