OK, thank you all for reading my first linux thread. I am a netowrk designer and openly admit to knowing next to nothing about servers and linux platforms etc. Any buzz words I may use here are other peoples and I dont necessarily know what they mean!!
Background.
I have to design remote access for a 3rd party company to come into our network to support an applciation on a linux server. The VPN access part is not an issue to me however, the server will be built wihtin a pblade within a bladeframe environment.

Problem.
when the 3rd party access the server to do all their good stuff on it, how can I stop them from bouncing to other servers within the bladeframe or from penetrating the rest of the network? Can I "harden" down their account to say that they can opnly do "this - this and this" or can a user account be defined as granular as that.
The access the 3rd require is as follows

- Command line (e.g. Telnet, ssh)

- File transfer (e.g. FTP, sftp)

- SQL*Net (Port 1521)GUI end user interface.

The BladeFrame isnt directly behind a firewall or in a DMZ environment adn to do this would be mean a serious amount of changes to the existing infrastructure.

As I have said the remote access part isnt a concern for me, it is how can I stop the 3rd party from misbehaving when they get in.
Is there any way I can audit what they do and keep a historical logg.
I apologise if this is silly questions but I am thrown in at the deap end here and really dont know much about servers.
I believe that the version of linux is Red Hat Linux v5.2

Many thanks for your time and hopefully help!!

Hi,

Welcome to LQ!

I would suggest that you request that your post be moved to the 'security' forum. You would get more exposure to appropriate people.

System hardening especially a server can be very dependent on the use of the server. Sure, the first thing would be to restrict services. Then configure the 'blade' to be as tight as possible. I would look at making sure that 'chkrootkit' is used along with 'tripwire'. Those alone won't prevent an intruder but they do provide a means of locking a gate.

Setting up access should not be that big of a deal. Boy, not to have some form of security on the 'farm' is just asking for problems. Since you are wanting to grant access to one portion of the farm then you had better setup a means to prevent uncontrolled access. Why telnet? I can see securing 'ssh' but you are opening a big can of worms with 'telnet'.

As long as you make sure that everything remains independent with the 'farm' as it should be then you may get away with what you are attempting.

Hi and welcome to LQ!

You can set firewall rules for this user account using iptables and ipt_owner
module. For example if the user id is extern and you only want him to access IP address 192.168.1.200 using ssh, the rule would be:

You might need to tweak these rules and/or combine them with existing iptables rules on your host but you get the idea.

HTH,
Robert

Thanks chaps for your response. I should clarify that the access will be secure into the network through an IPSEC tunnel so form a security perspecive we are ok, but I am trying to understand how we can limit the commands or what the 3rd party support company can do. Based on what Robert has said, I will research more into iptables and see where that takes me. I may be able to suggest something along those lines. Thanks

Hi,

Basically permissions will take care of what you allow the user to access. Your original post seemed to imply that you were wanting to secure the system. I would still look at how you permit the user to access the system.

A slightly more secure option to permissions is to put them into a chroot jail. This would limit their access to files on the server. This along with additional firewall settings should get you the security level you are looking for. Do a search for chroot ssh to learn more.

http://www.google.com/search?q=chroot+ssh

I think, from an overview POV, you should distinguish different layers:
[contract]
If you have a long term support contract with this party in their contract they have limited what support they provide: ergo every other activity can be seen as unwanted (or, depending, even a breach of contract). (In that respect it would even be better if this was a single shot negotiated contract since then you could simply state any activities that are not directly related to the tasks at hand, be it recce or data copying, is strictly prohibited.) Remember the company you design this for pays for this support so they have rights and nowhere it says that you can't have a friendly chat telling them to stick to well-defined tasks without the need to hint at the risk of losing business (or another spanish inquisition, finding horse heads in beds, concrete shoes, tar 'n feather suits, the works ;-p).

[policy]
Nothing is lost yet because the company you design this for may have a network policy prohibiting any users from deploying certain activities. Even if they haven't it isn't too late to whip one up simply stating activities for 3rd party X are limited to Y an Z. Regardless of what applies it is important though to let the contractor know their access will be actively monitored, clarification will be asked for and any trespassing will be subject to (insert judicial slash financial --force or repercussions that may apply).

[local measures]
Without contract or network policy as solid foundation you have left nothing but machine-specific measures. Here we hit the Twilight Zone as some things aren't defined like machine policies (what is the security level of the machine or network? are you allowed to change machine configuration? can you install software or request it to be installed?), required access level (unprivileged account? root?), type of application (even a generic description can reveal enough). It is especially important to know if root account access rights are required because that changes aspects quite a bit, requires much more work.

With that in mind I'd rather wait for your response before going into details. BTW, have you ever thought about providing them with a virtualized copy of the environment? That way placement makes for easier isolation and, depending on what diagnostics/work needs to be done, could allow for just copying over changes.

Thanks for all the new replies. the contractual technicalities are all being delt with at a much higher level than I.
I will do some research into the chroot, and IPtables. This may be enough to get me going. At the end of the day, someone else will have to make the final decision and configruation to the server.
I am interested in the conept of the virtualised copy of the environment. Regards
One other thing, the 3rd party will not have a root account. they will have a typical user account.

From a business point of view any existing hierarchy should not keep you from being as complete as possible in your recommendations, including informing management on the issue and asking to be informed about it. I'm not trying to teach you your job but maybe try to see it as the whole organization working together to reach a common goal.


Since this holds no question I take it you will do your own research. If you have any questions about what virtualization can do for you I suggest you open a new thread and maybe point to this thread for background information.


Great. In that case discretionary access control (DAC) will allow them to read filesystem contents but not change them (provided they are not allowed to su/sudo) and iptables as suggested by r0b0 will help confine their presence (do enable logging rules though). So to satisfy your requirement I would recommend using a syslogging shell wrapper called "rootsh".


You may expect from your fellow LQ members that they provide you with information but I have to emphasise that you should not let your lack of knowledge (as you wote:
) keep you from questioning possible solutions or look for alternatives. For instance a chroot may look nice but it will require you to populate the fake root with all the applications, dependencies and configuration this 3rd party needs. Depending on what they need you might find it conflicts with your requirement or require more work than is to be anticipated at first glance. I'm not trying to throw up roadblocks, just pointing out that you should be careful to use the first provided solution as the only solution, if you dig what I'm saying.

Aye, i dig what you are saying, and apreciate your help....

You're welcome. Posting back your final recommendations would be the kind of feedback that would be appreciated even more!

Ok, heres what has happened since I opended this thread.
We have installed a 2nd virtual server in the bladeframe with SPLAT / firewall software. This was also Linux redhat 3.
Then routed all trafic to the applicaiton server through the firewall/server. (the network addresses will be translated etc) and this was accepted by the relevant security and governing bodies. The firewall rules are defined to tie down the server and access etc. all was ok until now.
Now, when this was being implemented the support team have ran into a problem. They were defining 4 virtual ethernets on the virtual firewall server, and it appears that there is a limitation with Red Hat that it will only allow 3 virtual ethernets. This is what they told me but I dont know. Can anyone confirm if there is a limitation to 3 virtual ethernets in Red Hat or suggest anything else? Would a fresher version of Red Hat resolve this problem?

"also Linux redhat 3"?
i.e. that old version?
Or is it Red Hat Enterprise Linux 3?
However even that one is way way old, and you should look into the current version,
Red Hat 5.4
or alternatively if you're not buying support
CentOS 5.3 (soon 5.4)
which is basically Red Hat without their logos.

sorry it is red hat enterprise linux 3. Would a more up to date version solve the issue and allow more than 3 Virtual ethernet interfaces?

That I don't know to be honest, just noticed in general that it's a very old version, hence posted that