Tag Info

Hot answers tagged

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


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


9

Olivier D is almost correct, but you must set POSIXLY_CORRECT=1 before running unset. POSIX has a notion of Special Built-ins, and bash supports this. unset is one such builtin. Search for SPECIAL_BUILTIN in builtins/*.c in the bash source for a list, it includes set, unset, export, eval and source. $ unset() { echo muahaha-unset; } $ unset unset ...


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


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


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


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


3

I realize if someone controls your environment you're probably screwed anyway Yes, that. If you run a script in an unknown environment, all manner of things can go wrong, starting with LD_PRELOAD causing the shell process to execute arbitrary code before it even reads your script. Attempting to protect against a hostile environment from inside the ...


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


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


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


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


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


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


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 could use unset -f to remove the functions builtin, command and type.


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.


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


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


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


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

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


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


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



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