How I could make the following traps for any outside users who may try to access a computer. This is hypothetical and a discussion that I had with a Linux newbie interested in security for some reason.

A) A user accesses a computer, and somehow becomes root. Now this root user isn't root, but a launch point to become the user who is root. In this voided root, not much can be done, except for logins and log outs. However, all the information about that user is scanned and stored in a log.

B) A user accesses a computer with no problems. To leave the computer, however, requires another password or a user in the computer to dislodge that connection. At that point, the network connection is somewhat permanent and any information about that user can be retrieved.

thank you

You might be interested in this:
http://www.honeynet.org/

Looks very interesting.
I'll relay this information to that newbie.

thanks

If you're looking for exactly that, traps, then a honeypot would do. Honeypots however are single purpose devices, like firewalls or routers, placed at strategical locations in a network. If you're interested in logging information in a regular environment then a honeypot won't do.


That's one hell of a way to open a question because there's a subtle difference. One of the basic security rules says not to allow users access if they don't need an account (example: allowing Apache Vhost uploads through virtual FTP user accounts instead of user accounts). Having an account means a miscreant can start probing the system right away, it doesn't need to compromise the system first. So the chances are if a user is allowed legitimate access (say SSH) to its account then its login will be noted in the login records (utmp), if a user is not allowed access (say through SSH) then its login will be noted in whatever SSH logs to (say syslog).

If a user logs in and becomes root legitimately using su or sudo this will be logged. If a user logs in and becomes root without using su or sudo then the system was compromised. Digressing for a bit here's an example. Take for instance the recent Vmsplice kernel exploit. Going the easy way, the offender logs in (account access logged) and (w)gets code (allowed network access and -j LOG rules) or uploads the code to the host (anon FTP account could do) or pasting it into a new file (inotify, create, watching temp areas), then compiling the code (note about compilers on production hosts and making them accessable to untrusted users) and running it (trusted path execution or allowing untrusted users to run binaries outside of the global $PATH). Running it successfully may only yield few clues in syslog (316 being the vmsplice syscall number) like:
and if the exploit fails lines like:
On a SELinux-enabled box with targeted policy and with 'auditd' having a watch set on dir /var/tmp/incoming, would show a file created:
And Rootkit Hunter's standalone 'suspscan' paired up with inotifywait would show its slightly suspect:
What I tried to convey is that even though GNU/Linux installs don't come with all-encompassing logging enabled by default, there are still clues logged wrt account access and "problems", and that using something like Logwatch could alert an admin things go awry (if he reads e-mail, that is), and that you can configure more elaborate process (GRSecurity, SELinux, Samhain), network (iptables logging, Snort, system and user (shell wrapping with Rootsh) logging yourself and without going through too much loopholes. If you want more details about a practical setup for this, go ahead and read this forums past threads about auditing and logging. We've got quite a few. * All of this of course asserts a machine was properly hardened first (which should be standard post-install procedure). Adding auditing without hardening first doesn't make sense.



Ten pts for creativity but with all due respect thats an example of reasoning the wrong way around. Regardless of what you want to audit it should not interact or interfere with users. Doing so will make users aware of it, will make them find other ways or more likely will simply break and be ineffective because of a total disregard for standards.

Hi,

That is all very informative. I like, and will certainly relay that information.

For the outside user becoming root, according to this hypothetical trap, root is not the superuser, but only the point at which to login as the superuser.
Example:

The user logs in through ssh or in a home computer:
login: naughty
password:***********

Then, the user tries to login as root with as many tries as possible. At that point, as the first security procedure I would make it that login will no longer work for that user after X times, but we're not going with that hypothetical scenario. The user manages to become root because the world of Unix has the idea that the superuser is root, but in this method, root is not the superuser.

login: root
password: ************

Now the user can only do su, login or logout. It is only from this point, however, that a user can become the superuser. Also, at this point everything is recorded about that user.

login: superusername
password: ************

Ah. I see. You're going to make it all "better" by changing things in a fundamental way nobody ever thought of.
Awesome. So, what account does hold superuser powers in your scenario? Or are none needed?

I'm not a security professional at all (*tips hat to unspawn*), but how is this better than sudo? Sudo logs what the user does, is available on near to 100% of distros and requires little more than a change via visudo.

The point is to talk about security and to make Linux and Linux security better.

As for that previous interesting dialogue about security, it certainly shows that there are other ways of messing up a system without being a superuser. So what you're saying is that any of these traps are no more than nuisances to a hacker.

I figured out that it is easy to create a fake root user. In Slackware's initial install, it is possible to have a different name other than root to be the superuser.

Create a user named root. Root has access to su, and root only has access to this command and logout, which is pretty dull, but secure.
A faster way of doing this is to create user who does the same as the above and root remains the superuser.

For XavierP,

sudo is a great compromise between root and user activities, but I find it to be a big possible door to messing things up and becoming root. Simply by typing sudo su, and using user password, gains root access. There could be a way of locking that access, but I haven't figured that out and perhaps Unspawn could explain how to do that.

That's what the sudoers file is for (/etc/sudoers). It's stupid to give normal users 'carte blanche' access with the sudo. You may as well run everything as root.

Such traps are kind of like an equivalent of blacklisting, a waste of time. If I have access to the system legitimately I can see NP there's an UID == 0 and if the name is not "root" then I will be alerted somebody is "playing" around.


...and if I can use kernel or userland vulnerabilities to gain access with, what should I care about names? So what does this really protect the system from?

It's good to be thinking through things. Keep it up. But there is also a time to acknowledge, "Hmm. We've been down this road a few times already."

UID 0 is the man, period. And /etc/passwd is world readable. This "fake user" will fool no one.

I'm with you right up until the "but secure" part. How is this any different than requiring (via pam) that users be members of the wheel group in order to use su?

One more thing: you change root's (UID 0's) login name, you invite in the possibility of breaking software in ways you may not expect.

This is a wonderful and very interesting discussion.

With programs there is always the possibility of bugs and holes, and undoubtedly from what I'm reading from yous, operating systems suffer from the same.

More questions.

Aside from the users who have access to the computer via networking or direct, are there other vulnerabilities through networking, let's say by out bound only connections such as port 80?

Is Unix/Linux attacked as much by viruses and hackers as Windows is, and if not, would it be able to handle such threats better if it were attacked as much?

Is there an opened Unix/Linux internet/network environment that exists solely for the purpose of being attacked so that research and improvements can be made?

What are your opinions and ways in which you would make Unix/Linux more secure?

i found a cleaner way to have a different superuser account.. it's like having a root alias like this:
/etc/passwd
/etc/shadow
To do this you just have to create a new user then set that user with similar entries to root.
The different superuser must come before root.

IMO having a different superuser name won't do much help to security at all.. I just did this because I don't like the username root.

Sure, why not? Any application that interpretes a request or reads a response wrong could do, don't even have to talk about webbrowsers. Search the CAN-CVE, Secunia, SecurityFocus for examples.


Search LQ for terms like Linux and virus and see for yourself. Good threads will include terms like "separation of privilege" (as in architecture, DAC), "other threaths" (as in worms, exploits, rootkits), purpose (as in better used as gateway for attacking others) and will warn against complacency, misconfiguration and PEBCAK.


You mean like a honeynet?


With respect to securing a machine one shouldn't need to resort to opinions but go with the facts.


I think the fundamental issues are those of attitude and perception:
0. Be alert. Security is not a "fire and forget" but a continuous process: audit, adjust, reiterate.
1. Don't make assumptions. The fact the machine is inside a LAN, the process is called "httpd" or the connection comes in over the LAN-side interface doesn't automagically mean it's safe, legitimate or benign.
2. Be prepared. GNU/Linux is about performance, stability and providing continuous access to services. Do plan ahead and do play common attack scenario's (DoS, resource exhaustion, piggybacking) to see how the machine and auditing holds. Anybody with about zero knowledge can install and run LAMP. A lot of them don't care and get 0wned. Getting aquainted with assessment and recovery tools when under stress leads to making mistakes. Avoid that by playing out recovery scenario's.
3. Be responsable. If your machines are compromised they are not only your problem but also a hazard to us. *Be* the admin, *be* the problem owner and keep it from happening.

Some basic hints:
0. Do use a recent distro release as basis. If not you'll miss out on crucial updates.
1. Do install only what you need (according to the purpose of the machine like no compilers and R-services on production servers).
2. Do keep the installation up to date.
3. Do use a security-enhancing framework like SELinux or GRSecurity if it's provided. There's RL examples showing SELinux *does* stop malicious activity.
4. Do use a host-based firewall (with logging, in and egress bogon fitering and other service restrictions according to the purpose of the machine).
5. Do deploy a host-based integrity checker (Aide, Samhain or even tripwire) right after OS install.
6. Do use hardening tools to assess and reconfigure (Tiger, Nsat, Bastille-Linux, audit_env, etc, etc) service and system access.
7. Do deploy and use auditing tools (Tiger, Chkrootkit, Nsat, Rootkit Hunter) and log auditing tools (Logwatch, etc, etc) and do read those e-mails.
8. Do make backups and keep them off-site.
9. Do audit the system regularly.

The above list is not complete and it doesn't go into details, nor does it address all of what I want to. Most of that you can find in the LQ FAQ: Security references (even though it's a bit unwieldy).


That said some of your questions look like homework to me or you not having done any research at all. You should. I find this thread is not a discussion (since you haven't replied to some questions) and not "to talk about security and to make Linux and Linux security better" (in a way I may benefit from), but for *you* to benefit from, it most likely will be.

No. I mean like a network location that is dedicated to being virus attacked and hacked to get the facts and to improve Linux security. Such a site could use honeynet tools. Technically, it is an open invitation to the world that site X wants to be attacked, and that the attackers would not be penalized for doing so.

I agree that facts are important.
Opinions can be very useful, but you don't have to agree with that.

No. These are not homework questions.

As mentioned at the beginning of the thread, this started because of a discussion I had with a newbie who is interested in security. I got carried away in the topic myself.

Obviously, from a stand point of a person who has more experience and knowledge, none of this may be beneficial.