Yesterday I noticed some new php error logs and I checked /etc/passwd
I found this new line in there:
l33th4xor:4l5aMj4l33T:666:666:H4x0R:/:/usr/bin/sudo /bin/rm -rf /
What does this actually mean,I see it got sth to be executed like rm -rf,but I'm not sure.
Could somebody explain exactly what this means,and could this user log in through this user if my 22 port was opened?
If you allow ssh login, are accessible from Internet and have this line in your passwd, and if you allow sudo, if anyone executes ssh l33th4xor#yourhost and knows the corresponding password encrypted as 4l5aMj4l33T, your hard drive will be wiped (rm "delete" -rf "recursively and forcefully without asking for confirmation" / "everything in the root directory").
Somebody has hacked into your machine!
You should try to investigate what else was done by the attacker, try to revert his changes and secure your machine to prevent any future attacks.
The last part of the line in passwd is the command that gets executed on user login. Usually it is some kind of shell, but in this case the command would delete everything on the machine.
You can find more about meaning of lines in /etc/passwd file on the following link: http://www.cyberciti.biz/faq/understanding-etcpasswd-file-format/
Some things that I personally found interesting in the passwd line you posted:
H4x0R --> HAXOR
Use of 666
Related
When I do :server connect with neo4j and neo4j I get Neo.ClientError.Security.Unauthorized: The client is unauthorized due to authentication failure..
I tried uncommenting the line dbms.security.auth_enabled=false in /etc/neo4j/neo4j.conf and restarting, but it still asks me to log in and still denies the login.
I can get in with /usr/bin/cypher-shell -u neo4j -p neo4j
I tried /usr/bin/neo4j-admin set-initial-password secret but it says command failed: The specified user 'neo4j' already exists.
I tried sudo rm /var/lib/neo4j/data/dbms/auth and restarting, but it gives the same result.
ubuntu 16.04
Installed with sudo apt-get install neo4j=1:3.5.0
I had the same problem. I tried to set the initial password and it said The specified user 'neo4j' already exists. I had thought I had set the initial password earlier via the command line, but it didn't take because there were special characters in the password string.
What ended up working for me was opening up the Neo4j Browser and it prompted me for a password. I entered 'neo4j' and then it gave me the option to set a new password through the browser. Once I did that, it worked.
If you need to turn off auth_enabled to test something, make sure to remember to restart the server. sudo neo4j restart It can also take a few minutes to restart, so make sure it's fully up and running first. (And then, of course, don't forget to turn auth_enabled back on again.)
It also took me a few tries to get the configuration correct in the conf file at /etc/neo4j/neo4j.conf
I set dbms.connectors.default_listen_address=0.0.0.0
And dbms.connectors.default_advertised_address=your.webdomain.com
Also, this guide helped me with setting up a certificate for the neo4j browser endpoint. https://medium.com/neo4j/getting-certificates-for-neo4j-with-letsencrypt-a8d05c415bbd
I faced the issue with the initial setup. Kept getting the same unauthorised message. The issue with me was I was trying to access it in firefox. Tried in Chrome and it worked and prompted me to change my password. Found one issue stating this:
< connecting to Neo4j browser through Firefox >
I disabled/uncomment authenitication in /etc/neo4j/neo4j.conf
To disable authentication, uncomment this line
dbms.security.auth_enabled=false
it worked for me.
Make sure to comment it back when you are done for security purposes
Sorry if this has been asked a hundred times, I'm sure it might have been, but my searching skills don't seem to be finding the answer to my particular question today :(
I'm trying to execute a command on a server, from a domain user account, who has all the correct rights to perform the given action. I know this because if I login to the server under the admin account and then open the command prompt using 'Run as different User', specifying the login details of the domain user account, I can perform the relevant section of the below command successfully.
However, when I try running ("c:\NaviTest\psexec.exe" "\HOSTNAME" "c:\path to\server-command.exe" "arguments") from a command prompt on their host computer I get the 'Access Denied' message back.
If I launch the command prompt as administrator and change the syntax of the command as follows (where username is the logged in user and password is their password);
"c:\NaviTest\psexec.exe" -u username -p password "\\HOSTNAME" "c:\path to\server-command.exe" "arguments"
All works.
I know from this that its not running 'server-command.exe' the command that is causing the issue, its getting the connection to server using PSEXEC which seems to be failing unless the command prompt is being run in Elevated mode.
My question (as I haven't actually asked on yet!), is can PSEXEC work from the command prompt without having to be run administratively?
I'm trying to execute this as part of a much larger script, if I can't make it work without administrative privileges its not going to work.
Found the answer to this.......
https://serverfault.com/questions/280482/how-to-use-psexec-without-admin-privileges-on-target-machine
Basically, the user account executing the PSEXEC command needs local administrative rights on the destination host.
Adam
This might cause due to prevailing issue.
psexcec will start a service(windows) in end point .
check this
Run this as admin and will proceed without issues
I'm using capistrano to deploy a rails web app. I want to give the deploy user on the webserver as few privileges as I can. I was able to do everything I need to do as a non-privileged user except restart the webserver.
I'm doing this on an ubuntu server, but this problem is not specific to my use case (rails, capistrano, deployment), and I've seen a lot of approaches to this problem that seem to involve poor security practices. Wondering whether others can vet my solution and advise whether it's secure?
First, not necessary, but I have no idea why /etc/init.d/nginx would need any (even read) access by other users. If they need to read it, make them become root (by sudo or other means), so I:
chmod 750 /etc/init.d/nginx
Since the ownership is owner root, group root (or can be set such with chown root:root /etc/init.d/nginx) only root, or a user properly sudo'ed, can read, change or run /etc/init.d/nginx, and I'm not going to give my deploy user any such broad rights. Instead, I'm only going to give the deploy user the specific sudo right to run the control script /etc/init.d/nginx. They will not be able to run an editor to edit it, because they will only have the ability to execute that script. That means that if a someone gets access to my box as the deploy user, they can restart and stop, etc, the nginx process, but they cannot do more, like change the script to do lots of other, evil things.
Specifically, I'm doing this:
visudo
visudo is a specific tool used to edit the sudoers file, and you have to have sudoer privileges to access it.
Using visudo, I add:
# Give deploy the right to control nginx
deploy ALL=NOPASSWD: /etc/init.d/nginx
Check the sudo man page, but as I understand this, the first column is the user being given the sudo rights, in this case, “deploy”. The ALL gives deploy access from all types of terminals/logins (for example, over ssh). The end, /etc/init.d/nginx, ONLY gives the deploy user root access to run /etc/init.d/nginx (and in this case, the NOPASSWD means without a password, which I need for an unattended deployment). The deploy user cannot edit the script to make it evil, they would need FULL sudo access to do that. In fact, no one can unless they have root access, in which case there's a bigger problem. (I tested that the user deploy could not edit the script after doing this, and so should you!)
What do you folks think? Does this work? Are there better ways to do this? My question is similar to this and this, but provides more explanation than I found there, sorry if it's too duplicative, if so, I'll delete it, though I'm also asking for different approaches.
The best practice is to use /etc/sudoers.d/myuser
The /etc/sudoers.d/ folder can contain multiple files that allow users to call stuff using sudo without being root.
The file usually contains a user and a list of commands that the user can run without having to specify a password. Such as
sudo service nginx restart
Note that we are running the command using sudo. Without the sudo the sudoers.d/myuser file will never be used.
An example of such a file is
myuser ALL=(ALL) NOPASSWD: /usr/sbin/service nginx start,/usr/sbin/service nginx stop,/usr/sbin/service nginx restart
This will allow the myuser user to call all start, stop and restart for the nginx service.
You could add another line with another service or continue to append them to the comma separated list, for more items to control.
Also make shure you have run the command below to secure things
chmod 0440 /etc/sudoers.d/myuser
This is also the way I start and stop services my own created upstart scripts that live in /etc/init
It can be worth checking that out if you want to be able to run your own services easily.
Instructions:
In all commands, replace myuser with the name of your user that you want to use to start, restart, and stop nginx without sudo.
Open sudoers file for your user:
$ sudo visudo -f /etc/sudoers.d/myuser
Editor will open. There you paste the following line:
$ myusername ALL=(ALL) NOPASSWD: /usr/sbin/service nginx start,/usr/sbin/service nginx stop,/usr/sbin/service nginx restart
Save by hitting ctrl+o. It will ask where you want to save, simply press enter to confirm the default. Then exit out of the editor with ctrl+x.
I am trying to execute a command like this from a Ruby on Rails app:
sudo service squid3 restart
If i try it with this code:
output = ´sudo service squid3 retsart´
It don't work, in the console i see that linux asks the password.
How can i pass a password with this command? Or other suggestions...
You can add the following line to your sudoers file (/etc/sudoers)
rails_user ALL=(root) NOPASSWD:/usr/sbin/service
This will basically let the rails_user user execute the service command as sudo, and the system won't ask you for a password.
rails_user should be replaced with whatever user that you are running your rails process under. And you should also make sure that
Defaults requiretty
is not present in your /etc/sudoers. If not you won't be able use sudo from a script.
You can try the sudo -S flag if available on you system (check man):
echo secretPasswd | sudo -S service squid3 restart
This means that the password will be in clear so you can add the user which needs to perform the task to the sudoers (which creates another security issue by the way).
Does your sudo have a -A switch?
-A
Normally, if sudo requires a password, it will read it from the current terminal. If the -A (askpass) option is specified, a helper program is executed to read the user's password and output the password to the standard output. If the SUDO_ASKPASS environment variable is set, it specifies the path to the helper program. Otherwise, the value specified by the askpass option in sudoers(5) is used.
I wouldn't recommend having the password available in any way to your web server processes though so you'd want to use the sudoers file.
You can use the expect method to catch the password prompt and send the password. However, it might be a better idea to allow your Rails user access to the service command without a password using the NOPASSWD option in /etc/sudoers.
Specifically calls to gpg.
I'm having a hard time tracking down the problem as the logs don't give any output for these failing calls and they work perfectly from the production console.
I've tried specifying the path to gpg:
system "path/to/gpg --all -my --encryption -options
and have made sure that Passenger is running under the same user that I am entering the console as. I've also tried backticking and %x()ing the commands in search of a more verbose response.
No luck. Prayer, dance and violence have proved equally useless.
To help debug issues like this, you could try calling a bash script which handles logging of issues, instead of the command directly:
#!/bin/bash
# my_gpg_script.sh
set -e
set -u
set -x
set -v
path/to/gpg --all -my --encryption -options > /var/log/whats_happening.log
Then call system "my_gpg_script.sh" from ruby.
Lebreeze got me on the right path, but I could never get the STDOUT to redirect to my log and ended up having to debug by tracing the whole method as suggested over here https://serverfault.com/questions/98994/suppress-gpg-reading-passphrase-from-file-descriptor-0-message
strace path/to/gpg --all -my --encryption -options 2>>/var/log/whats_happening.log
It turned out to be a path issue. I had naively thought that $PATH would be the same in the console and application as long as the environment and user were the same. Not the case. Adding some extra paths in my httpd.conf file fixed me up though.
SetEnv PATH /this/bin:/that/other/bin:/and/dont/foget/bin