LinuxQuestions.org
View the Most Wanted LQ Wiki articles.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices

Reply
 
Search this Thread
Old 08-06-2009, 05:22 AM   #1
Networking
LQ Newbie
 
Registered: Aug 2009
Posts: 8

Rep: Reputation: 0
Unhappy hardening \ securing \ auditing a linux server account


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!!
 
Old 08-06-2009, 09:18 AM   #2
onebuck
Moderator
 
Registered: Jan 2005
Location: Midwest USA, Central Illinois
Distribution: Slackware®
Posts: 11,281
Blog Entries: 3

Rep: Reputation: 1446Reputation: 1446Reputation: 1446Reputation: 1446Reputation: 1446Reputation: 1446Reputation: 1446Reputation: 1446Reputation: 1446Reputation: 1446
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.
 
Old 08-06-2009, 09:27 AM   #3
r0b0
Member
 
Registered: Aug 2004
Location: Europe
Posts: 602

Rep: Reputation: 49
Hi and welcome to LQ!

Quote:
how can I stop them from bouncing to other servers within the bladeframe or from penetrating the rest of the network?
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:

Code:
iptables -A OUTPUT -p tcp --dport 22 -d 192.168.1.200 -m owner --uid-owner extern -j ALLOW
iptables -A OUTPUT -m owner --uid-owner extern -j LOG
iptables -A OUTPUT -m owner --uid-owner extern -j DROP
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
 
Old 08-06-2009, 10:40 AM   #4
Networking
LQ Newbie
 
Registered: Aug 2009
Posts: 8

Original Poster
Rep: Reputation: 0
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
 
Old 08-06-2009, 01:15 PM   #5
onebuck
Moderator
 
Registered: Jan 2005
Location: Midwest USA, Central Illinois
Distribution: Slackware®
Posts: 11,281
Blog Entries: 3

Rep: Reputation: 1446Reputation: 1446Reputation: 1446Reputation: 1446Reputation: 1446Reputation: 1446Reputation: 1446Reputation: 1446Reputation: 1446Reputation: 1446
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.
 
Old 08-06-2009, 02:14 PM   #6
lukav
Member
 
Registered: Sep 2008
Distribution: Slackware & Ubuntu
Posts: 39

Rep: Reputation: 15
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

Last edited by lukav; 08-06-2009 at 02:36 PM.
 
Old 08-06-2009, 04:07 PM   #7
unSpawn
Moderator
 
Registered: May 2001
Posts: 27,457
Blog Entries: 54

Rep: Reputation: 2897Reputation: 2897Reputation: 2897Reputation: 2897Reputation: 2897Reputation: 2897Reputation: 2897Reputation: 2897Reputation: 2897Reputation: 2897Reputation: 2897
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.
 
Old 08-07-2009, 04:22 AM   #8
Networking
LQ Newbie
 
Registered: Aug 2009
Posts: 8

Original Poster
Rep: Reputation: 0
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.

Last edited by Networking; 08-07-2009 at 04:32 AM.
 
Old 08-07-2009, 05:53 AM   #9
unSpawn
Moderator
 
Registered: May 2001
Posts: 27,457
Blog Entries: 54

Rep: Reputation: 2897Reputation: 2897Reputation: 2897Reputation: 2897Reputation: 2897Reputation: 2897Reputation: 2897Reputation: 2897Reputation: 2897Reputation: 2897Reputation: 2897
Quote:
Originally Posted by Networking View Post
contractual technicalities are all being dealt with at a much higher level
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.


Quote:
Originally Posted by Networking View Post
I am interested in the concept of the virtualised copy of the environment.
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.


Quote:
Originally Posted by Networking View Post
the 3rd party will not have a root account. they will have a typical user account.
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
Quote:
Originally Posted by Networking View Post
Is there any way I can audit what they do and keep a historical logg.
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:
Quote:
Originally Posted by Networking View Post
I am thrown in at the deap end here and really dont know much about servers.
) 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
Quote:
Originally Posted by Networking View Post
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.
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.
 
Old 08-07-2009, 08:55 AM   #10
Networking
LQ Newbie
 
Registered: Aug 2009
Posts: 8

Original Poster
Rep: Reputation: 0
Aye, i dig what you are saying, and apreciate your help....
 
Old 08-07-2009, 09:33 AM   #11
unSpawn
Moderator
 
Registered: May 2001
Posts: 27,457
Blog Entries: 54

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

Last edited by unSpawn; 08-07-2009 at 09:36 AM.
 
Old 09-22-2009, 08:54 AM   #12
Networking
LQ Newbie
 
Registered: Aug 2009
Posts: 8

Original Poster
Rep: Reputation: 0
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?
 
Old 09-22-2009, 09:04 AM   #13
rsciw
Member
 
Registered: Jan 2009
Location: Essex (UK)
Distribution: Home: Debian/Ubuntu, Work: Ubuntu
Posts: 206

Rep: Reputation: 44
"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.
 
Old 09-22-2009, 09:16 AM   #14
Networking
LQ Newbie
 
Registered: Aug 2009
Posts: 8

Original Poster
Rep: Reputation: 0
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?
 
Old 09-22-2009, 09:34 AM   #15
rsciw
Member
 
Registered: Jan 2009
Location: Essex (UK)
Distribution: Home: Debian/Ubuntu, Work: Ubuntu
Posts: 206

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


Reply

Tags
security


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Securing / Hardening RHEL4 for Web Hosting?? phpinfo Linux - Security 7 02-12-2009 08:08 AM
securing guest account mattydee Slackware 11 02-04-2008 10:36 AM
LXer: Securing and Hardening Linux Production Systems LXer Syndicated Linux News 0 01-21-2006 01:16 AM
Linux Server Auditing mshajan Linux - Software 1 05-05-2005 01:37 PM


All times are GMT -5. The time now is 12:59 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration