Tag Info

New answers tagged

0

Known vulnerabilities are not the biggest indication about how secure a system is. Due to the open source nature of the Linux Kernel, most vulnerabilities are actually discovered when developers or testers are reviewing the source code. Also, most patches are released quite fast in my experience, whilst most Windows updates are released on Patch Tuesday. ...


0

Just recently I came over the issue with my Company's apt repository. The problem was that if we use standard http transport anybody else can get package easily. As Company is packaging its own proprietary software and does not want to share it with everybody, http transport becomes a problem. Not a tragedy but a problem. There is couple of ways how to ...


0

If the user does not have root access (or any way to gain it, such as exploiting an insecure setuid program), escaping a chroot jail should be impossible. With root access, escaping a chroot jail is trivial. In fact, the chroot(2) manpage even gives instructions: This call does not change the current working directory, so that after the call '.' can ...


0

No it cannot, it would give them an error. That's the whole point of chroot. They'll be only locked up in a location without being able to go out that location. But if you want tias.


1

There seems to be a custom installer created for Debian by someone else which will do everything for you automatically? https://github.com/rickard2/grsecurity-Debian-Installer Else isn't it just a case of doing things the old way? Namely, patching things from source? You seem to be asking for instructions on how to patch your kernel for which there are ...


0

The "Remember me" option just creates a session cookie which the service (Facebook for instance) will be happy to accept "forever". Nowadays almost all services work by generating a session cookie which the client (your browser) will transmit over and over again during the session. So, the "remember me" option actually "only" tells the service/server to keep ...


1

It's not an issue. Cron is a system processes that runs things at times. (every hour etc.) It's running stuff as root. That is normal.


0

The versions of icedTea included in Ubuntu 14.04 have a new control panel that includes the possibility to configure policies that really work. Now you can allow the execution of unowned code. If you are concerned about security, allow that permissions only from the particular CodeBase of you application I have tried doing the same in Ubuntu 12.04.x ...


1

First, note that compression has nothing to do with encryption. There are tools that do both, but the two parts of functionality are independent. Cryptography is about information processing. It can be described as mathematical transformations. Mathematics doesn't depend on the date. If I can decrypt something today, I could already decrypt it yesterday, ...


1

Root can sort of be logged in with an insecure password yes. With sudo su, is this a security issue? You have to decide that on your own (you can forbid sudo from using the su command to bypass that), similarly it depends on how you are using sudo, if you are giving your user account full access to any desired command through sudo, then of course, anyone who ...


2

You use DenyHOSTS. From the blurp on their webpage: enyHosts is a script intended to be run by Linux system administrators to help thwart SSH server attacks (also known as dictionary based attacks and brute force attacks). If you've ever looked at your ssh log (/var/log/secure on Redhat, /var/log/auth.log on Mandrake, etc...) you may be alarmed to ...


1

You are basically asking two separate questions. How to set permissions on your local system to mirror the production one? You need to know the server configuration - in this case it includes configuration of the http daemon (httpd aka Apache in this case) - usually found in /etc/httpd or /etc/apache). You also need to know with what credentials daemon ...


3

This is a computer science question. Can this be done at all? It it possible? The naive answer: Alice gives bob locked file and key, but first makes bob promises that he will not unlock it until it is time. Alice gives locked file to Bob, and key to Clare. Alice instructs Clare to give key to Bob at pre-defined time. For the case of writing special ...


0

You can reduce the risk of a persistent exploit by making sure that the service is not able to create an executable file anywhere. For that, make sure that all the filesystems that the service can access meet at least one of the following conditions: mounted read-only mounted with the noexec option contains no directory that is writable by the service ...


0

You can use an ACL to deny all users write and execute permissions and then explicitly allow only the service account user to only have the full rwx. http://linux.die.net/man/1/setfacl


0

As i can see there is no write permission to group & others, So they cant create any file/directory here. you just need to make sure that if you remove write permission from root, what will happen?


4

When a directory has "x' (or searchable) permission, it is possible that specific files under a directory having for example 111 (--x--x--x) permission can be accessed if their name is known AND the permission of the destination file allows it. Directories with 'r' permission allow programs such as ls to basically open the directory as a file and read it ...


1

It sounds like you want real (non-root) user accounts with ssh keys and full NOPASSWD access via sudo (which is available by default in most Linux distros these days and is also trivial to install manually). You can have blank passwords for each user account (which won't work remotely), then the user either runs sudo -s or the user's ~/.bash_profile merely ...


2

Another example to @cff answer, if you intend to ban any successive "tries" on your SSH server: sudo iptables -A INPUT -p tcp -m tcp --dport ssh -m state --state NEW -m recent --update --seconds 600 --hitcount 4 --name DEFAULT --mask 255.255.255.255 --rsource -j DROP sudo iptables -A INPUT -p tcp -m tcp --dport ssh -m state --state NEW -m recent --set ...


3

Do you really need your server on the internet? If you really want to have it on the internet then make sure it is secure before you put it there. Changing the port is just security through obscurity. If your attacker is more sophisticated than just running scripts it won't help. A few things already mentioned that I recommend also: I agree with ...


8

Yes, be worried. You may never get burnt, but you should be following IT best practice. Better safe than sorry. I'm a network admin at a hospital. It is always a bad idea to connect a box directly to the internet. What you're seeing is all the thousands of automated scanners that scan for vulnerability on the internet. I see these and all sorts of things ...


2

It's possible, but it's very difficult. If you really want to rebuild everything from source, you'll end up running into dependency loops which you will have to break. But if you want to persevere, instead of using apt-get build-dep you should look inside each source package's debian/control, and rebuild all the packages listed in Build-Depends and ...


5

You could configure the internal firewall of the kernel by iptables. So that only a few machines could ssh to your server and let other IP packages drop. See man iptables for more information. For example, if 192.168.1.67 is the host you ssh from, then on the server type: sudo iptables -A INPUT -p tcp --dport ssh -s 192.168.1.67 -j ACCEPT sudo iptables -A ...


13

It is fairly normal to have login tryouts enough to make a flooding log. Changing SSH ports is more of a 'security by obscurity' type of solution, but it helps with the flood. I stress it's not very elegant, there are de-facto ports for services for a reason. As it should be on by default, but ensure you cannot SSH into your server as root. It's the ...


8

I would suggest you to do a few things: Change the port ssh is listening at (to something far above 1024) and make sure you use no version 1 of the protocol: /etc/ssh/sshd_config # What ports, IPs and protocols we listen for Port 50022 # Use these options to restrict which interfaces/protocols sshd will bind to #ListenAddress :: #ListenAddress 0.0.0.0 ...


52

Welcome to the wonderful world of the Internet... Have you: put your server behind a hardware firewall? activated the software firewall? (just in case the HW firewall glitches) hardened your server? installed rkhunter before putting it online? activated automatic daily security updates? changed the default port of ssh? ... But the real answer is: Yes, ...


0

Put your keys in the environment as environment variables. The way sites like Amazon aws and heroku recommend that you store sensitive information like keys and passwords are in environment variables. Put the password in a text file that is readable only by you Assuming this is a Mac or linux system: touch foo.sh Place the export in the file nano ...


3

The Chromium sandbox is a separate program, chrome-sandbox (even for Chromium rather than Chrome). You'll see it running with ps aux | grep chrome-sandbox and you can see its relationship to the other Chromium processes with pstree | less -pchromium As mentioned by Cestarian the sandbox is enabled by default and can be disabled with --no-sandbox (but ...


0

You need to remove the # from the #SecAction in the snippet you quoted for rule 900015. There's a line just above this telling you to do this if using DoS rules.


0

After long time, I am able to find the answer. Problem: ==> The hrsupport not able to cd to home/someone/public_html, which is having nobody as a group Solution: ==> I added the hrsupport user to the group nobody Problem Solved.


1

step 1 : remove faulty key ssh-keygen -R 192.168.1.1 step 2 : add new key ssh-keyscan 192.168.1.1 >> ~/.ssh/known_hosts or depending on your situation > ~/.ssh/known_hosts ssh-keyscan 192.168.1.1 192.168.1.2 ... >> ~/.ssh/known_hosts


2

Heed @0xC0000022L's warning! If you know the host key has changed, you can remove that specific entry from the known_hosts file: ssh-keygen -R xxx.xxx.xxx.xxx This is much better than overwriting the full hosts file (which can be done with just > /root/.ssh/known_hosts). If you don't want to use ssh command-line options, I believe the only other way ...


0

The main point to understand about GPG checking for packages is that the GPG signature is embedded within the package, and the GPG keys are stored in the rpmdb. There is no secure API to ask "What key is package X signed with" you can only ask "Is package X signed with a key in the rpmdb" and "Does key Y exist in the rpmdb". Also note that this means that a ...


1

openssh client uses user given name to authenticate a server against the known_hosts file. the name can be letters or ip address. In the former case, it's matched against Host entry in ssh_config and if the Host entry has HostName set it's used to check against known_hosts file. If the matched Host entry has no HostName set, the user supplied letters on the ...


0

You can bypass HELO restrictions for authenticated users by inserting permit_sasl_authenticated before rejecting rules in the smtpd_helo_restrictions list: smtpd_helo_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_non_fqdn_helo_hostname, reject_invalid_helo_hostname, permit


0

If you search for the firewall-config package than you can maintain you hostbased firewall with a graphical interface. It will come with firewalld to maintain it. This as Firestarter is obsolete for years now and Debian drops it with the coming release as one of the latest distributions.



Top 50 recent answers are included