Tag Info

Hot answers tagged

6

If it were setgid root then the agent would run as group root, which likely has broader permissions than the user it started as. That could be a security risk; at the least, running something as root unnecessarily is a red flag (even the group) and requires extra attentiveness. Setting the group ownership to nobody, which is a group that shouldn't have any ...


4

You can authorize as many public keys as you like on the server side. Furthermore, you can restrict a key to a specific command on the server side. So generate an SSH key pair on the client, and don't put a password on the private key. Append the public key to the list of authorized keys, and add a command restriction. ssh-keygen -t rsa -f ...


4

Putting host names in hosts.allow or hosts.deny means the server must do a reverse DNS resolution to get the domain name for the IP address. This will affect login times if your name resolution system is slow or if some intermediary name server is slow to respond. It is faster to put the IP addresses ur subnets into the file instead, as is explained by man ...


4

ping is setuid because it, while fairly "safe", requires the ability to open raw sockets. Consequently it needs the CAP_NET_RAW capability, or to be root. nethogs is different for a few reasons: notably, it not only requires privileged access to the networking stack, but it shows information about other users. On a multi-user system you may not want just ...


4

Don't reinvent the wheel, let rsyslog do everything for you. It has the ability to send emails when patterns are matched in syslog messages before they ever hit a file. Set your email address and SMTP server in the following and put it in your /etc/rsyslog.conf or drop it in /etc/rsyslog.d/ and restart rsyslog $ModLoad ommail $ActionMailSMTPServer ...


3

It's not really possible. You simply can not prevent someone powering on/off a computer, or indeed them doing whatever they want with it once they have hands on access. I've done something similar, for a server. It uses full disk encryption and produces its key based on hardware data such as CPU type, Mac Address, amount of memory installed, etc. If someone ...


3

This question looks very confused, but I think the confusion is part of the question, so I'll try to provide enough background to clarify things. HTTP and SSH are different protocols. HTTP is spoken by HTTP clients (called web browsers) and HTTP servers (called web servers). SSH is spoken by SSH clients and SSH servers. The HTTP protocol has a notion of ...


3

You can bind-mount directories into your chroot root with: mount -o bind /x/y /chroot/x/y (see man mount, section "The bind mounts"). Any access to /chroot/x/y from now on acts exactly like an access to /x/y: same file listings, same contents, same inodes. Note, however, that this puts the entire directory in as-is: a process inside the chroot that can ...


3

I would recommend creating a private/public key pair on the client machine, and copying the public key to the remote machine. You can generate such a keypair with ssh-keygen and copy it to the remote machine using ssh-copy-id. The logs are probably readable by all user accounts on the server (at least they are on my machine). You should therefore not use ...


2

The point of making ssh-agent setgid is to increase security by making the process impossible to debug, so that even a process running as the same user can't dump keys from memory. ssh-agent should not in fact have additional privileges. In case there is a vulnerability in ssh-agent, if it is setgid to some group, this confers the user the privileges of ...


2

Changing the cipher suite was the final solution. ssl_protocols TLSv1.2; ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256; The problem was that Firefox 30 doesn't supports the mentioned cipher yet.


2

sudo From the relevant man page: The real and effective uid and gid are set to match those of the target user as specified in the passwd file. Also, in the description for the -P (preserve group vector) option to sudo: The real and effective group IDs, however, are still set to match the target user. Basically, whatever commands that are run ...


2

First, you should not rely on user's .profile because they can change it. If it's really your server, you could: test for entries in auth.log, utmp or so periodically (or triggered by inotify) write a wrapper for /bin/login, that does your things and then executes the real /bin/login. (I am not quite sure if e.g. ssh executes /bin/login, but I expect so.) ...


2

Depending on your SSH configuration (usually defined in /etc/ssh/sshd_config) root access may be disabled in a number of ways: No root access at all (PermitRootLogin=No or DenyUsers root) root is allowed access, but only via key-pair authentication (PermitRootLogin=without-password or PasswordAuthentication=no) root access is allowed, but only specific ...


2

LXC is a little bit better because it can run containers as unpriveleged users. This is not possible (AFAICT) with systemd-nspawn. If you want to know why docker, lxc, and systemd-nspawn are inherently not a solid security mechanism, read this: https://opensource.com/business/14/7/docker-security-selinux. Basically, containers still have access to the kernel ...


2

You can do this via PAM configuration. For example, if you use XScreenSaver, you'd edit /etc/pam.d/xscreensaver and change the @include common-auth line. Rather than repeat all the details, I'll point you to my answer to Set sudo password differently from login one. The procedure is almost exactly the same, except that you'll be editing the PAM config for ...


2

Line 1: Mounts Types: NetworkFileSystem, SambaFileSystems, and CommonInternetFileSystems on All Shared Paths to the Users Home Directory, Along with: Mount All Devices as a loop, Along with Unmounting, all Saved in the Array MOUNTING. Line 2: Prints the kernel dump from the last successful boot, saved in the Array SYSTEMDIAG. Line 3: If the User is logged ...


2

Use sudo. (But power off should not be prevented or people will pull the plug instead.) Some config files can be tightened to the point where they cannot be viewed; however others (critically DNS configuration) do not work if not world-readable. For each file you have to read the manual to find out. If full disk encryption + TPM-provided boot password ...


1

Does root have SFTP access? Can you sftp root@remote? If so, you should be able to download the /etc/sshd/sshd_config from the remote to your local machine, fix it, and push the corrected version back.


1

Use fail2ban which uses the firewall to disable access to ssh (and optionally, other services) after a certain number of failed attempts. By default, it blocks for 30 minutes after 3 failed attempts, but is configurable using (I believe) the maxretry value.


1

It is extremely improbable that this represents a security breach. A badly-implemented malware would use a dot file for a modicum of stealth. A better-implemented malware would hide itself by patching the kernel so that no file would ever appear. The mundane explanation is that you accidentally pasted a line containing the character > followed by this ...


1

You've edited the file /etc/passwd with a Windows editor, or with an editor configured to produce Windows files. Don't do that. Windows uses the two-character sequence CR-LF to represent a line break, whereas Linux and other unix systems use just LF and see that CR as an ordinary character that happens to be last on its line. Generally speaking, use a Linux ...


1

Try the following when logged in: su root Then you login as root. When this works, you can edit the passwd file.


1

Does it accept the password from the console? you might have upgraded your system and your sshd_config might have been replaced. By default root access through ssh is disabled. By the way, the password is not stored in /etc/passwd, it is stored in /etc/shadow. The only thing affected would be your login shell which is what is the last field of /etc/passwd ...


1

I would suggest creating a script that runs as root. Have it run hourly, writing the output of 'faillog -a' to a text file everyone has access to. Then have your MOTD grep that file for the current user. This would avoid having to make any unnecessary permissions changes or granting someone sudo access that doesn't need it.


1

Basically yes, it's is the default iptable file for a clean installation, but i recommend to use a more up-2-date rules, and add some logging to your rules. See this template for example: https://gist.github.com/jirutka/3742890


1

What am I missing? /dev/kvm is world readable (and writable) as you can see from it's permissions: user::rw- group::rw- other::rw- There is no reason why you shouldn't be able to read it. Are you referring to something else?


1

So this can be done when using HTTP by looking for specific headers from the client such as: HTTP_CLIENT_IP HTTP_X_FORWARDED_FOR HTTP_FORWARDED_FOR HTTP_FORWARDED But AFAIK, similar headers and techniques don't exist for SSH. There are proxy blacklists that may be useful, but that's in no way a secure solution.


1

Based on the blog post by @Siosm I created a tool with which you can write a simple config with patterns, and then you get notified about everything not matching these patterns: journalwatch. You can find more in the Archlinux Forum Thread. It seems there's also a patch and a hack available in the logwatch tracker by now.


1

mount -o bind should do it for full directories. mount -o bind /bin /chroot/bin chroot /chroot Would end up with a copy of your systems /bin inside the chroot. To have your copy of bash supersede /chroot/bin/bash handle it the same way we do today, put it in /chroot/usr/local/bin and set PATH accordingly.



Only top voted, non community-wiki answers of a minimum length are eligible