Tag Info

New answers tagged

0

Use secure delete instead. sudo apt-get install secure-delete srm -r pathname Done. Secure delete is a lot more paranoid than shred, using 38 passes instead 3. To do a fast single pass, use srm -rfll pathname fll gets you a less random random data generator, and only a single pass.


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

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

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 ...


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


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 ...


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

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 ...


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.


0

Usually when some one logs into a user system then in /var/log/messages it gets printed as: sshd[18468]: Accepted keyboard-interactive/pam for root from 134.64.66.666 port 49867 ssh2 So just grep the messages as: grep -E "Accepted keyboard-interactive/pam for" /var/log/messages


3

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 ...


0

/var/log/auth.log Keep track of attempts to your system cat /var/log/auth.log grep sshd.\*Failed this can grep failed attempts, also timestamps is available so you can tune it to your script, also maybe with tail -f /var/log/auth.log you can trace input all the time and then do some regexp.


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.) ...


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 ...


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 ...


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

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 ...


0

After reading and researching many answers, I found (imho) im3r3k's answer above to be the most thorough. I would only add to it that since shred does not remove directories I appended rm -rvf $1 to the shell script (where $1 is the /path/to/your/file passed in from the {} expansion in the find... -exec)


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 ...


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 ...


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.


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

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.


3

Short answer: You can't. Long answer: Full disk encryption won't save you when it's running. The data is available, decrypted, on your running machine. The VM provider can clone your machine at any time, especially if it's not encrypted. From the cloned machine, they can mount the system from another machine (like this) and change the root password or ...


2

/tmp It is risky, because you need to add extra code to use it safely. Obviously this gets overlooked. A recent example is given by Steve Kemp. http://blog.steve.org.uk/sometimes_reading_code_makes_you_scream_.html ./mgmt/tools/SysAPI.cc: tmp = fopen("/tmp/shadow", "w"); ./mgmt/tools/SysAPI.cc: system("/bin/mv -f /tmp/shadow /etc/shadow"); If ...


3

/tmp, /var/tmp, and /var/lock are world-writable by default. There may be symlinks, such as /usr/tmp → /var/tmp, provided for compatibility with older applications. /tmp and /var/tmp world-writable because they are meant to be used by any user for any temporary storage. /var/lock is world-writable so that any process, running as any user, can create lock ...


6

The only FHS-mandated directories that are commonly world-writable are /tmp and /var/tmp. In both cases, that's because they are intended for storing temporary files that may be made by anyone. Also common is /dev/shm, as a tmpfs (filesystem backed by RAM), for fast access to mid-sized data shared between processes, or just creating files that are ...


1

In researching this it does not appear that there's a method for blocking users from accessing the contents of the PPD file. Re: Unable to Print to Networked Konica Minolta BizHub C280 Re: How do I set the default value in a PPD. (xerox accounting) Printing to Xerox with XSA accounting from Linux So without this option your only viable option to restrict ...


1

Yes it does (could). If you create a file underneath /foo/bar/baz which is readable by others and then create a hard link to this file in an accessible path, they'll be able to read it regardless of the permissions on /foo/bar/baz.


0

If a directory is 700, then only the owner (and root) can access it. This means that any other users can not see, never mind change, any files in that directory. So yes, you probably could change all the files in that directory to 600 or 400 or 700, but why bother? Does it matter that someone could read (but not write to) root's .bashrc and .profile if ...


3

You can use strace for this: strace -f -e trace=file command args... strace traces system calls and prints a description of them to standard error as they occur. The -f option tells it to track child processes and threads as well. -e lets you modify the calls it will track: -e trace=file will log every use of open, unlink, etc, but no non-file actions. ...


1

This is not a hard and fast rule, but stuff that defaults to /opt is usually self-contained, and may require that you copy or symlink executables into an executable path, or add an internal folder to $PATH. That's simple enough to figure out if you prefer to put it somewhere else and use a $HOME/bin. Source built stuff that defaults to /usr/local, however, ...


2

The guides tell you to install in /usr/local/ or /opt etc so that others may use them. If you install in your home directory then only you will have access to them. If you're just compiling for yourself, then this is fine.


3

Obviously HTTP/HTTPS services are vulnerable. Only the later ;) What about SMTP, IMAP and POP? There are online and offline tests around for mailservers (and webservers). If you are running debian, there's a decent chance your software was compiled with a version of openSSL < 1.0.1, which is when the vulnerability starts, so if the binary was ...



Top 50 recent answers are included