configure ls keys

eeluve

eeluve

I am somewhat not comfortable having to reboot, to apply securelevel settings. I do understand why it is done that way, but have an idea of maybe changing some ls keys to confuse the attacker. For example changing the -o key for some combination of several letters or maybe even numbers. Should I get the source code of ls and where or maybe persist some utilities for that or system tools ?
 
Security through obscurity doesn't work.

Keep in mind the attacker has access to the source and can therefor see exactly what changed.
 
Excuse me, what do you mean? If I use recompiled ls how can this so-called attacker check what exactly I have changed and the new values? Or whatever, even better question if you got time to answer - what do you personally use to protect your FreeBSD machines? Manual docs somehow don't explain enough details for me. Let's say you flag all in /bin, /usr/local/bin, set terminals to insecure, I wouldn't like to but set securelevel 1, rlogin and telnet off, PermitRoot through SSH, disable keyboard-interactive, allow only keys, change the port the sshd daemon is listening on. Something else? And I am talking only about getting root access, or if somehow gotten not being able to change something without me mentioning it instantly. Some things, such as checking MD5 of /etc, /usr/local/etc means you do expect to get your root hacked and I want not to be. DOS and other stuff protection I guess can be done much easier than in docs, just configuring firewall and kernel for your exact needs. Again correct me if I'm wrong please.
 
He'll figure it out soon enough.

Besides, you're going to break pretty much everything that depends on the 'standard' options.
 
Sorry, you probably were typing while I edited the post. If possible answer second part please. Just some recommendations out of your experience, so that I don't excess the security settings but still have enough.
 
Do NOT allow root to login through SSH directly.

As for your other questions security(7) and [thread=4108]Unofficial FreeBSD Security Checklist / Links / Resources[/thread].
 
Thanks for the second link. But if there's no keyboard interactive login type, several admins who got to log on to this server, ain't sshkey enough? And if I am correct, I would not be able to SCP/PSCP as well if I do not permit root login? Also they would need to guess the port, I do realise nmapping the range above 1024 would let them have an idea, but still?
 
You can recompile your own ls as you want, but I don't believe this will confuse an attacker. After all, if I have to attack a system I could write to a file without even checking permissions, and therefore the trick is not going to work at all.
If you have to reboot so often due to secure level I suspect you are using them in the wrong way, that is maybe you applied the secure level too early at a stage when you are configuring the system or to the wrong files.

Security is a very complex task, so a few documents cannot give you the total solution, but give you only advices on what to avoid and which are the risks, the other considerations are up to you and your experience.

Finally, have a look at shells/scponly that will allow you to do scp without having an interactive shell.
 
That's a great response, thanks. Everything you wrote makes sense, I haven't said about "rebooting so often" etc, just lets say (not my case atg the moment) you got several (probably many) webservers connected to replicating MySQL servers connected to 4-5 memcached servers and stuff like that, while usually you would at most just [cmd=]kill -s HUP[/cmd] and be happy, and security seems to be the only thing that requires actual stop/coldrestart/reboot of system or daemon. And I understand why you don't clarify what you possibly meant by "I could write to a file without even checking permissions". Didn't you mean [cmd=]echo "" > "filename"[/cmd]? Maybe you could PM me if that's possible, e-mail: eeluve@gmail.com. I would really love to know what you meant and how I might protect the system from that.
 
eeluve said:
And I understand why you don't clarify what you possibly meant by "I could write to a file without even checking permissions". Havent you meant [cmd=]echo "" > "filename"[/cmd]?
Click to expand...

I meant that if I have to overwrite a file, let'say a configuration file:
Code: 
mv myMaliciousMySQL.cnf my.cnf
I would not do an ls(1) before, I would do the overwriting and only if failing would inspect why. Therefore manipulating ls(1) does not make much sense to me. It would be much more effective to exchange security levels into the kernel and recompile the whole system knowing that sappng means, for instance, uappnd and so on. But as already pointed out, this does not improve security, only entropy....
 
eeluve said:
But if there's no keyboard interactive login type, several admins who got to log on to this server, ain't sshkey enough?
Click to expand...

This isn't exactly pertaining to the topic, but security of ssh keys is dependent on the key size. You may want to check the key size used for authentication ssh-keygen -lf {pubfile}. By default ssh-keygen now creates 2048 bit keys, but I noticed the other day some old keys I had been using were only 1024. I've seen some guides for putty keygen using that as well which is too low (ssh-keygen supports up to 4096 btw).

I wouldn't say trying to thwart attackers is a bad idea, but that you're doing it at the wrong level. It's generally accepted that once an attacker is on your system you are screwed. Time is better spent on keeping them off the system in the first place with security updates, and proactive steps that tighten security. Although intrusion detection system is often a part of that.

While security through obscurity doesn't work, I still think changing the ssh port is a good idea.
 
You can use a rootkit to hide processes / files / network connections, and the rootkit kernel module itself.
 
Ok, I clearly understood all of your points.

First of all, honestly, I only mentioned changing the SSH port helps, but in my experience only against bots who look for port 22 only, while in fact that's so easy to check that some, let's say 3434/tcp port is open, ssh -v and be happy.

The point of ls(1) [*] changing is much deeper; let's say you try to [cmd=]mv myMaliciousMySQL.cnf my.cnf [*][/cmd], get a system error because it's sappend and schg'ed [*] while the security level is 1-2, what are you gonna going to [*] do? [*] Wouldn't you first check the ls(1)? And [*] only then change securelevel and reboot?

Recompile the "xxx" key for the previous "o", recompile the new "o" key to have no effect on the system but send you an e-mail, SMS or something like that, so that you will get warned even before he tries to reboot? Maybe there's something still I got to learn (definitely [*] is, but from what you said for now I don't see) and why this ain't a good idea, please tell me if so.

And I am 100% on the same page with Morte, of course what I do want is to prevent someone getting the root, but if this fails, I might consider some additional "traps".
 
Ok, so you've modified ls(1), what if your attacker doesn't use ls(1)?

Code: 
perl -e 'opendir($dh,qq(.)); while(readdir $dh){print qq($_\n);};'
 
$ find . -maxdepth 1 -ls

I'm pretty sure that uses an internal implementation of ls(1) and doesn't call the binary /bin/ls.
 
Yeah, or someone could "Barmin patch" me with a perl script, right? Maybe set a password on launching perl from the command line/file? And generally, that was exactly the experience I was asking for, SirDice. Could you mention something else I must consider?
 
Talking about
# find . -maxdepth 1 -ls

Yes, but could you actually add keys to this?
 
No you can't give it any more options but I'm just demonstrating one more way of getting a directory listing.

As to your original question, if the attacker already has root access to your system there's nothing that will stop him. He can upload his own set of utilities that don't depend on system utilities or runtime libraries but use the system calls directly bypassing any modifications you have done to those system utilities.
 
Thank you, do agree. Hate to link this, but if possible check my last post here http://forums.freebsd.org/showthread.php?p=181913#post181913, this thread is old and maybe that's the reason people skip it (or my grammar ;), yes that's an excuse but English ain't even my first foreign language). I am eager to understand this issue. Maybe doing something wrong, maybe there is still some bug/failure with my ports on this system. I was updating from 8.1 to 9.0.
 
You must log in or register to reply here.
Back
Top