Hot answers tagged security
8
This is a broad ranging question and can probably only be answered with the same sorts of brushstrokes. Ultimately, it comes down to what you, the user, wish to protect.
Fundamentally, you should not post anything that would allow someone else to find it easier to compromise your system, or any of the other connected tools or accounts you use. For this ...
6
Even though password brute force attempts may not be successful on your system, using fail2ban has other benefits than simply blocking the attack:
Keeps your auth log from filling up too much, saving disk space and making analysis easier.
Reduces unnecessary CPU cycles and bandwidth servicing bruteforce attempts.
fail2ban is a great tool for more than ...
4
You can replace any binaries you want to approve usage of with a wrapper that will alert the operator, store the action requested and delay it until it is approved. Just remove the execute and read permissions from the programs in question (for the users in question) and place a wrapper with the same name somewhere in the path of those users. (The removal of ...
3
What you're looking for is typically called Kiosk Mode.
Kiosk from scratch
There is a good tutorial over on alandmore's blog titled: Creating a kiosk with Linux and X11: 2011 edition.
View this is only a start.
LiveCD
Additionally I'd consider using a LiveCD for this type of situation since this will limit any permanent damage one can inflict if they ...
3
127.0.0.1 is not the "outside world", it is looking around inside the house.
Check your firewall configuration (iptables in Linux today), most of them shouldn't be accessible from the ouside.
Don't run services you don't need. Uninstall all not required software.
Change passwords to be stronger. Check your usage of the system, don't go chasing any ...
3
This was surprisingly lacking in documentation. I found this file, module-signing.txt, which is part of the RHEL6 Kernel Documentation. In this document it shows how to generate signing keys, assuming you want to sign all your modules as part of a kernel build:
cat >genkey <<EOF
%pubring kernel.pub
%secring kernel.sec
Key-Type: DSA
Key-Length: 512
...
2
Just complement the other answers that show you what types of things to anonymize in logs I thought I'd provide a list of tools that can be used to help facilitate anonymizing the logs.
TCPDUMP/pcap
The list is primarily tools for dealing with tcpdump/pcap logs. NOTE: The full list of tools and libraries is here.
AnonTool
Netflow (v5 and v9) traces in ...
2
Adding to the other two (great) answers, it's also good to realize that the process of factor separation, so important for good testing/troubleshooting, is somehow related to the act of removing the sensitive info.
In other words, whenever possible, always try to replicate your problem in a separate environment. Apart from the advantage of ruling out ...
2
The basic rule should be to expose only necessary information.
So here the basic security rules apply:
Only as much access/information as needed
Anything else should be forbidden/not readable
As you can see from many questions asked here - comments will ask for further information, if needed. But it is up to you to obfiscate personal information about ...
2
When you login as root, check system logs ( /var/adm/messages, who, last, dmesg, etc) to see if you see any errors relating to SSH configuration.
Check your /etc/pam.conf file. Are you using multiple authentication schemes? That login prompt changing suggests that there may be multiple auth entries for SSH in PAM.
Use -v with ssh to see some verbose ...
2
There is no reason to have a seperate user definition file. System users and real users are not technically seperated but organizationally: by the range from which their UIDs are taken. have a look at the file /etc/login.defs. My openSUSE has these entries:
SYSTEM_UID_MIN 100
SYSTEM_UID_MAX 499
UID_MIN 1000
UID_MAX ...
2
If you really mean "forget the password" it probably already did within microseconds of you entering it.
Persistence of authentication through the login session is maintained in Ubuntu-ish systems by ssh-agent and gnome-keyring-daemon. By their nature of operation (non-invertable hashing) it may be fundamentally impossible to selectively remove one ...
2
I don't believe this information is kept anywhere. They only place you could get some of this type of information would be from the sudo command logs, assuming you're using sudo and that your sudo setup gives out permissions such that you're logging on individual commands such as passwd.
I've used this command before to show what accounts are locked,i.e. ...
2
Unfortunately I have to answer the question myself now. "Unfortunately" because the answer is "No, it is not possible".
I took a look at how PAP is working, and came to the conclusion that it is logically impossible to store the password as a hash value.
With PAP, the username and password are sent directly to the authentification side. Therefore, the ...
2
The arguments to a builtin will never show up in any ps output, because the builtin is not a separate program with its own command line. All modern shells (except some highly stripped-down configurations of BusyBox), including all bash versions, have echo built in.
Note that if you're calling bash -c "echo $password", then the password will show up for ...
2
for benchamrking purposes you should disable syn_cookies:
echo 0 > /proc/sys/net/ipv4/tcp_syncookies
But re-enable them if you're done!
If the server can't take the load you have to optimize your webapp, tune your config, use some kind of caching or use more than one server fronted by a loadbalancer.
I can't tell more detals because it highly depends ...
2
If this is going to accessible via the network, yes. In order for apache to access the public_html it's going to need some level of access to root's home directory (which could be catastrophic if they somehow found a way, via software vulnerability or unsafe configuration, to add something to root's .bash_profile or something).
Run as little as humanly ...
2
Exploits by their very nature are trying to not be detected. So most exploits are not coming into the system through normal means, at least not initially. They'll typically use something like a buffer overflow to gain access to the system.
buffer overflow
This style of attack looks for portions of an application that are looking to take input from a user. ...
1
You should set DIR_MODE in /etc/adduser.conf and use the adduser command as recommended in the man page for useradd on your system:
adduser testuser
If you do not want to make changes to the original /etc/adduser.conf (or need different setups) you can make changes in a copy and use adduser --conf <yourconf>
1
There is no basic mechanism to authorize commands because this is mostly pointless. The core unix permission mechanism is about protecting access to data. If you can read the data, you can do anything you want with it. For example, it's impossible to “allow reading but prevent copying” (copying is just reading in one place and writing in another place), so ...
1
One quick way to do it (if you dont care to take an IV + key and send it through RC4) is:
i=1
while [ $i -le 4 ]
do
dd if=/dev/random bs=1 count=16 2>/dev/null | xxd -ps
i=$(( i+1 ))
done
This will generate four 128-bit wep keys. Adjust count for different strengths
1
[EDIT]: I misunderstud the question, I rewrite a more appropriate ansver here
I do not know Tiger security, but I agree that the user nobody is mean to have NO homedir, NO right over any subdir at all and is mean to really to have NO shell at all (and to do never properly do a 'login').
But the actual settings (in /etc/passwd) is different for differents ...
1
Your display manager (lightdm, openbox, etc.) is a child of init which is owned by root. Init isn't set-uid because it's a very special process and is just started with uid of 0. The command ps -eaH gives a structured view of parentage, the relevant bits are:
r 1 ? 00:00:00 init
r 1521 ? 00:00:00 lightdm
r 1531 tty7 00:00:12 Xorg
...
1
You can set those set those to run only with sudo and create a asksudo command that send this to the root user(s)
This might be a good start (only works when for root when it is logged in):
PS: I didn't test it, it might contain errors
function asksudo {
# for users
write root "asksudo from $(whoami):"
write root "\"$(whoami)\" \"$(PWD)\" && ...
1
Daemon users and flesh-and-blood users are listed in the same files. The “file like /etc/passwd for daemons” is /etc/passwd.
There is no formal definition of human vs system users. The kernel doesn't care (other than granting a lot of privileges to the user with UID 0). Most administration commands don't care either. Some typical differences are:
A human ...
1
If you really want to split user and system accounts (reading some of the comments on other posts, it looks like you are curious about this), you could leave all system users in the files (i.e. /etc/passwd) database and put people users in a second database (kinda like if you were doing ldap).
For this, you can use the Berkeley DB NSS module (available on ...
1
This sounds like your password may have been locked. While you're logged in as root, try passwd -u <useraccount>. Or, passwd -d <useraccount> to delete the password for the user. Here is the man page for passwd.
1
What you're asking for is not a simple suspend-to-RAM, which leaves the RAM powered on and shuts down everything else. Since you'd be wiping cleartext process data from RAM, you need to marshall it all to the suspension image. So you have to invoke the hibernation (i.e. suspend-to-disk) code. The realistic way to do that would be to create an encrypted ...
1
It would be best to design your automation such that it's fired off from crontab on the server itself.
Another possibility is to create a setUID wrapper (which can just be something like a C program that calls execv("/path/to/script",argc,argv); or the like) for the root-required commands, and only allow your automation users to run it via group ...
Only top voted, non community-wiki answers of a minimum length are eligible
