how do you stop intruders

Hi I change my password last night on the vps, and I'm still getting hacked. change my sshd port to. Plus what is pts.

The screenshot is what I'm talking about. I haven't logged in to this linode for a few days. It wasn't me.
 

Attachments

  • Screenshot_20230312_210025.png
    Screenshot_20230312_210025.png
    184.5 KB · Views: 163
they succeeded I guess do you know how to disable pts.
How should I do this.
Make key and upload it and change my passwords. or
change my password and then upload my key?

I was working on a friends computer today and had to switch his passed three time and delete his user account on a laptop with freebsd. I suppose the were using the camera. So I put black tape on camera and found
.Xauthorit-c
.Xauthority-l
in his account. had to delete his folder by hand. Something else to but I forgot what that was
 
Once you enter root via lish I would lock user paul. Then scrape necessary files and delete account.
Scan files if possible. Isolate until scanned.
Create new user account.
 
I would save to logs too so you can chase this down. Starting with ssh logs.
Get the attacker IP try and hit back with massive coordinated packet flood.
Send in the alert-5 fighter planes.
 
Any files from /home/paul/ that you need before nuking. I would encapsulate them in a tar file.

You might wanna nuke the whole thing if you can't find the attack vector.
 
Absolutely step one:

Log in to Linode control panel. Go to Lish console. Login to VM and disable sshd.
service disable sshd
 
Last reply before sleep.

Step two. Determine method of entry. Look at ssh logs. How did this hacker get pauls password?
Was this brute force with bunches of guesses or was this coordinated attack on your credentials.
(ie... your password is common across the web and hacked)

It is helpful to know what this user hacker did while logged in so look for recent file changes on the system.
Also look at the user paul .history file to see commands the hacker ran.

I run security/tripwire on my linode webserver now along with my firewall. It really makes me feel secure.
 
I would even lockdown my linode account password with a message to Linode customer support and security team.
Offer them logs with IP's used. Determine yourself if another Linode account was used with an IP search.
Hacker may try and assume your account now that he knows VM details.

I would also want the IP changed for your VM just to throw the hacker off just in case it is automated hacking tools.
 
Hi I change my password last night on the vps, and I'm still getting hacked.
So you say you already changed your password, but after that the attackers were still able to access the system using your account? Then you have to assume that the attackers have root access (as they can see your new password), which means you have to assume they have copies of all the data on this machine. You should also assume that they have completely penetrated this installation.

they succeeded I guess do you know how to disable pts.
You don't know what /dev/pts/... is? I'm not sure you should be administering a FreeBSD system that is being attacked in that case.

PTS are virtual terminals that get created when people log in via (for example) ssh. You don't disable PTS, you disable ssh.

Make key and upload it and change my passwords. or
change my password and then upload my key?
None of the above. I would do two things: (a) make copies of any data on this system that you want to keep. (b) Nuke it, and install a new system.

had to delete his folder by hand. Something else to but I forgot what that was
So you also suspect that hackers have become root on this system, and then all you do is delete a folder by hand? And then you forget what you did?

Sorry, once a system has been penetrated, you completely get rid of it. At this point, nothing on the system is trustworthy. On your friend's laptop, you should reformat the disk, and reinstall from scratch too.

I used to think changing ports made ssh all better until I got to linode. Welcome to defensive computing.
Linode has a reputation for attracting a lot of bad hackers, and other criminal elemants. That's because they are an inexpensive and only minimally supervised hosting provider. My advice would be: After nuking this system, set up a new one somewhere else.

Get the attacker IP try and hit back with massive coordinated packet flood.
Fun, but waste of time. Your attacks will be ignored. Simply accept as a fact of life that hackers exist, more in some places than in others. Punishing them after the fact is pointless.

I never heard of locking account how to and what "necessary files"?
If you don't know how to manage accounts on a BSD system, you should not be administering one that is under attack. I would start by reading a good book about Unix in general, and FreeBSD in particular.
 
I would do two things: (a) make copies of any data on this system that you want to keep. (b) Nuke it, and install a new system.
That's probably the best piece of advice you are going to get. I would add:
  • once your data are copied to a safe place, have a very good look at it to see if there's anything unexpected there; and
  • next time, do not use passwords for ssh access, at all, disable them, use strong ssh keys only.
Google "Secure Password Generator" to find a way to make a good password or ssh key (I use a length of 64). Then figure out how to place it in a "safe", and retrieve it from the "safe". There a many options. I use sysutils/password-store.

On your new, clean system, set up and test access by ssh, using strong keys, then, when you know it's working, add the following to /etc/sshd_config to disable passwords for ssh logins:
Code:
PasswordAuthentication no
ChallengeResponseAuthentication no
Then restart the ssh service (service sshd restart).

If you have to use a password for console access, make it a strong one, and keep it in the password safe as well.

Once that's all working, check the logs to make sure you have not been hacked again, and rebuild your system.

Then your adventures will start all over, because you just fixed port 22 for ssh, and any other port you expose on the Internet will get attacked...
 
I think the image you provided has some great clues.

It shows the VM Booted up on Tuesday Mar 8th at 16:01:38

At 16:02:14 You had a login attempt that failed.

#1) Did you reboot or start the VM at this time?

#2) The failed login attempt offers a interesting clue.
############cpe.net.cable.rogers.net

A very long IP with a suffix that is identifiable.
You are from Canada and Rogers is a Canadian Carrier.

So is this you on Mar 8th at 16:02:14 with a failed login attempt?
The time seems somewhat tight for a human with the lag.

I worry that perhaps your home router or wifi router could be hacked.
This could be a local vector not some hacker picking on Linode users.

Interesting too that it took 3 days for the hacking to really start.
I would expect to see more on the command line for errors if hacking in that period.

So look at /var/log/messages to see what user rebooted the VM machine on Mar 8th.
Especially if it wasn't you with a failed login attempt..

I would treat all your wireless connections at home as possibly tainted.(Unless the reboot and failed login was you)
 
Hi I change my password last night on the vps, and I'm still getting hacked. change my sshd port to. Plus what is pts.

The screenshot is what I'm talking about. I haven't logged in to this linode for a few days. It wasn't me.
As others already stated: make ssh key auth only.
Also, install a VPN and make it only accessible on the VPN interface.
 
I think the image you provided has some great clues.

It shows the VM Booted up on Tuesday Mar 8th at 16:01:38

At 16:02:14 You had a login attempt that failed.

#1) Did you reboot or start the VM at this time?

#2) The failed login attempt offers a interesting clue.
############cpe.net.cable.rogers.net

A very long IP with a suffix that is identifiable.
You are from Canada and Rogers is a Canadian Carrier.

So is this you on Mar 8th at 16:02:14 with a failed login attempt?
The time seems somewhat tight for a human with the lag.

I worry that perhaps your home router or wifi router could be hacked.
This could be a local vector not some hacker picking on Linode users.

Interesting too that it took 3 days for the hacking to really start.
I would expect to see more on the command line for errors if hacking in that period.

So look at /var/log/messages to see what user rebooted the VM machine on Mar 8th.
Especially if it wasn't you with a failed login attempt..

I would treat all your wireless connections at home as possibly tainted.(Unless the reboot and failed login was you)
Not sure if I used it at that time. The .history log was short and not like my other linode. The commands were building a jail and that's what I'm doing for my NJ linode. I could of messed up witch linode I was using. they have different passwords. So I"m going to use keys anyway's.

I'm suspicious about the short .history log.
 
In addition to running a secure system, and ssh server (proper configuration) its also advisable to enable one of the three host-based firewalls that FreeBSD offers (I recommend pf). If you always reach the VPS from the same location (e.g. your home) you can simply include a block drop rule for all other inbound SSH traffic.

Your current server should be considered hosed and unreliable and should be re-imaged (perhaps after saving copies of any logs) before trying to use it again (securely).

In the future you may use /usr/bin/sockstat -46l to list active listening sockets which will also include an entry for each remotely (or locally) connected IP address.
 
Probably automated tools.
Maybe he doesn't have sudo installed. Its not in base right?
user paul can't install packages.

These are su attempts from paul

The last line is the most concerning. It appears he got root.
 
Well the attack vector is right there in the image.
They stuffed the input with invalid characters and got something.
I feel something is amiss with the timeline.

Mar 10 01:56:35 su paul to root

But then the actual attack.
Mar 11 02:25:15 sshd error: Fssh_kex_exachange_identification: banner line contains invalid characters

This is why its worth investigating these. This could be a genuine input validation ssh bug.

My Linode lighttpd log is full of huge input attempts at the url.
It is really crazy the stuff they try and stuff into a input.
 
The last line is the most concerning. It appears he got root.
And at that point, all reasoning about what Paul's password or ssh keys or flying purple elephants are, and whether he's using su, sudo, doas, etc. becomes irrelevant: If the person becoming root was an intruder, we have to assume that they changed all that. This is why debugging this installation is no longer useful, unless one wants to do forensics.

I think the important part now is for the OP to learn how to install a new system, at a location of his choosing, and make it secure enough. I think that requires the OP to learn more about how the system works, and how to configure it.
 
Back
Top