Tag Info

New answers tagged

0

FileVault (and OS X in general) does not check /etc/passwd, so a script using it as a trigger will not work. FileVault uses DirectoryServices, so any interception of what is being entered has to be through Apple's OpenDirectory implementation (see documentation on DirectoryService). How to do that is beyond me, but reading up on ...


2

This is, at least in part, governed by the ServerTokens directive, so you could set ServerTokens Prod which will reveal only that the Server is an unspecified version of Apache, but even the manual itself suggests this is not a security measure.


1

Other answers have addressed the how, but I'll consider the whether. Depending on what kind of database your users are connecting to, you might already have a suitable mechanism that's already used by those client programs, in which case be sure to use them (I'm thinking of ~/.mysqlrc or ~/.pgpass). If you're giving several users the ability to access the ...


0

#!/bin/bash unset username unset password unset dbname echo -n "username:" read username echo -n "dbname:" read dbname prompt="password:" while IFS= read -p "$prompt" -r -s -n 1 char do if [[ $char == $'\0' ]] then break fi ...


8

First, as several people have already said, keeping the credentials separate from the script is essential. (In addition to increased security, it also means that you can re-use the same script for several systems with different credentials.) Second, you should consider not only the security of the credentials, but also the impact if/when those credentials ...


1

Your idea of hiding the password in an inaccessible place might be OK depending on the circumstances. If the information is separate, that means simple editing of the file, e.g. during a code review with a colleague is not going to show it. But realise anyone with access to your account can easily find such a file. I have used a subdirectory of ~/.ssh for ...


-2

I don't believe you should ever store the password. I can't think of a single good reason for that. Rather, you should store a salted hash of that password - some string which is produced reliably by some function when the original password is passed as input, but never the password.


5

First of all, if there is any way at all you can change things to avoid having to store a password inside or alongside a script in the first place, you should make every effort to do that. Jenny D's answer contains a lot of good advice to that effect. Otherwise, your idea of placing the password in a separate file with restricted permissions is pretty much ...


1

See man xferlog for the details but in short: /var/www/.../success.gif is the filename b stands for: a binary transfer _ stands for: no special action (like compression or tar) was taken d means that the file is deleted r stands for: access-mode real - a local authenticated user username stands for the authenticated username ftp stands for the ...


2

It's not the kernel that's preventing bad memory accesses, it's the CPU. The role of the kernel is only to configure the CPU correctly. More precisely, the hardware component that prevents bad memory accesses is the MMU. When a program accesses a memory address, the address is decoded by the CPU based on the content of the MMU. The MMU establishes a ...


2

Using sudo: #!/bin/sh ip -s -s neigh flush all ufw enable sudo -Hu username sh -c '"/home/back/Downloads/tor-browser_en-US/Browser/start-tor-browser" --detach || ([ ! -x "/home/back/Downloads/tor-browser_en-US/Browser/start-tor-browser" ] && "$(dirname "$*")"/Browser/start-tor-browser --detach)' dummy %k -H: Sets the $HOME environment variable ...


1

There are two ways to go about this. 1) Run the script as a non-root user and use sudo to raise privileges to the root user (prefix the commands to be ran as root with sudo). or 2) Run the script as root user and use su to run the tor command as non-root user. su allows you to stipulate what user to run the command as and the -c option to specify what ...


5

When on Linux you can use the inotify mechanism in combination with incron. Setup incron by installing the package and edit the config: /etc/incron.conf system_table_dir=/etc/incron.d user_table_dir=/var/spool/incron allowed_users=/etc/incron.allow denied_users=/etc/incron.deny lockfile_dir=/var/run logfile_name=incrond editor=vi Then configure a watch in ...


0

seems like this is a known bug as reported here: https://bugzilla.redhat.com/show_bug.cgi?id=1204307


0

You could use process accounting too. Look for service psacct on Fedora and enable it. Then you can see what user did/is doing by running things like: sa (list of all commands) lastcomm bash (who ran bash) lastcomm vpathak (what was run by vpathak) This along with some shell history should give you a nice outline. For better understanding of ...


0

On most systems, including CentOS you have to install as the root user, to have the rights to write the programs and files to the right locations. That doesn't mean that the programs once installed run as root. Most won't and some, like Apache will run as a special user. But in order to start these programs and obtain restricted resources (like port 80 and ...


3

"Installing as root user" isn't a bad thing necessarily, especially if they installed using package managers. For e.g., installing mysql on CentOS via yum, will create a mysql user and the mysql process then is usually run as that user. For starts, see this: http://serverfault.com/questions/212269/tips-for-securing-a-lamp-server . If you have specific ...


0

Other answers are using iptables -I in their examples, which often isn't what you should use. iptables will execute the first rule which matches, so the order of rules is very important. -I is the "insert" command, and should be used with an index parameter to specify where in the list a given rule belongs. -A is the "append" command, which will add the ...


2

You can translate MikroTik firewall rules to Linux iptables rules pretty easily. The only real difference is that iptables marking isn't quite as pretty, it likes 32 bit flags instead of nice long names, but "1" suffices most of the time. According to the iptables man pages: add chain=prerouting : -t mangle -A PREROUTING (Appends a new rule to the end of ...


1

From the manpage of the syscall chflags(2): SF_IMMUTABLE The file may not be changed. SF_NOUNLINK The file may not be renamed or deleted. [...] UF_IMMUTABLE The file may not be changed. UF_NOUNLINK The file may not be renamed or deleted. The flags prefixing with SF_ may only be set or unset by the super-user. The others prefixing with UF_ may ...


0

Which version of mailx are you using? heirloom-mailx 12.5 on Ubuntu 14.04 prompts me for the password every time if there's no smtp-auth-password setting in ~/.mailrc. This feature was added in 12.0 in March 2006 according to ChangeLog.


-1

CA is an authority. No more, no less. This is not absolutely linked to server. CA is - to a certain extent - the very big boss. CA (is above)> server(s) > client(s). In addition, if your clients can connect 2 servers, no exclusions and so on, use a only one CA. That's perfectly normal.


0

PID randomization was never available in the mainstream Linux kernel. Appart from individual initiatives, for several years it was mainly available through grsecurity kernel patch, however it was removed in the late 2006: grsecurity 2.1.10 was released today for Linux 2.4.34 and 2.6.19.2. Changes in this release include: Removal of randomized ...


1

Am I doing the right thing by using the external IP of my router? or should I use the internal ip of my machine, or the range of internal ip addresses? TL;DR: if your server is "across the Internet" from your own machine, you use the router's address in your iptables rules. Longer answer: The firewall rules work from the perspective of the device ...


2

So what your rule is saying is: Append the INPUT chain For packets that use TCP and are destined for port 22 That come from this source address We will accept them. There are two ways you can do this, and your question seems a little vague (to me at least), so I'll answer all three scenarios: Scenario 1 You want anyone from a given public IP address ...


2

With very few exceptions, if somebody has your hardware in their hands, they can duplicate everything, simply by accessing and copying the whole storage. There's no extra encryption that would help. If you encrypt the disk, the disk encryption key has to be readable somewhere. Disk encryption is useless in your scenario. There is hardware that can't be ...


0

When generating keys, you can set the expiration date for those keys. Assuming it's possible for legitimate users to update the client keys on their devices, you could set the keys to expire after a relatively short time. That would limit the time of potential exposure if a device is stolen.


12

Is it a good practice to run a daemon under a non-root user account? Yes, and this is common. For instance, Apache start as root and then forks new process as www-data (by default). As said before, if your program is hacked (ex: code injection), the attacker will not gain a root access, but will be limited to the privileges you gave to this specific ...


5

If you have a program that needs to be able to do function X (e.g., manipulate the clock), and you can give it the privilege/power to do function X and nothing else, that is better than giving it the whole can of alphabet soup.  This is known as the principle of least privilege.  Consider, what if your program has a bug — either an ordinary programming error ...


12

Shall I use another way to do so that would be considered "Good Practice"? Unless you have strong, irrefutable reasons otherwise, you should just use the NTP package that comes with your GNU/Linux distribution. The standard NTP daemon has taken years to mature and come with sophisticated features such as slowing or speeding up your system's clock ...


1

I don't know about "best" practises, but if you feel more comfortable with more restricted sudo than comes out of the box, you should IMO do the following: make a normal user "install" user that requires explicit login to, with a clearly different prompt and which, via /etc/sudoers is allowed to run your installer program(s) (apt-get, yum, etc.) with root ...



Top 50 recent answers are included