Click to See Complete Forum and Search --> : Securing Linux
linuxcomando
March 29th, 2002, 01:19 AM
I thought id share with yah guys how to help secure an ext2 filesystem like slackware or redhat.
First off after you have your server setup just the way you want do a :
chattr -R +i /
This will set your whole root file system imutable. Not even root can for the creation or modification of a file unless they do a chattr +i FILENAME. Whats really cool is that if you do a ls -l it will still show all of your original file atributes so if you do a chmod a+rwx / then make the file system is imutable . It will show all the files are writtable but you can't do crap unless you set it unmutable.
Whats really crazy is you can rm the chattr command and only allow a certain directory to install that commando to. So unless they know that directory which is writtable and not unmutable they won't be able to install the chattr command so in theroy they wont be able to change any files.
so the command
rm -fR / won't work
have fun and happy hacking
str34m3r
March 29th, 2002, 03:12 AM
What a novel idea... While I've long been familiar with the chattr command, I never really gave much thought to setting the entire filesystem immutable.
Is this really even possible? I was under the impression that there were always files that the system had open for reading and writing so that it could perform it's normal tasks. Does linux ignore your command to chattr files that it needs to keep open? That doesn't sound like the linux I know. Linux generally obeys your every command even though you're about to fry your entire filesystem with a stray space in the arguments for 'rm'.
Have you done this on your own system? How well does it work? Wouldn't that affect the boot sequence? Please let me know a little more about your experiences with this.
If it works, it sounds like a great idea for a firewall or something like that that doesn't change often.
linuxcomando
March 30th, 2002, 09:50 PM
From what ive seen and tested on my own system nothing seems to be writtable.But im mostly using it on my slackware firewall and it works great. and if i need to change something put chattr on a floppy and load it into that directory that you didn't set imutable. As of yet none of my "hacking boxes have not been hacked" by any of my friends or associates.
Admin32
March 30th, 2002, 10:50 PM
Just dropped in to say it was a very interesting idea :)
Chris P.
www.firewall.cx
silentstalker
April 2nd, 2002, 03:08 AM
And let me say something about *nix here ok guys? When putting your sites up on yer *nix boxes, please please please, dont allow anonymous FTP access or unauthorized telnet proxy usage ok?
This is because, when I hack, I first connect to the site anonymously via FTP. Usually theres a good deal of info I can acquire from the site and its box by just looking and the freaking directory listings.
And I say the Telnet proxy because this. I am connecting to a site. Example.
Microsoft Telnet32.exe
:: o (command to connect to host)
<to> xxxx.xxx.x.xx.
connecting....
Access denied to use the Telnet Proxy.
:: o (command to connect to host)
<to> xxxx.xxx.x.xx. 25
connecting...
...
press any key to continue...
Welcome to Whateversite.com 4.0 Mail
::vrfy guest
vrfying guest complete, 501: <guest@whateversite.com>
You see how much information I gained just by a little anonymous access? Hint hint to all sys admins.
cwk9
April 2nd, 2002, 03:13 AM
Great idea linuxcomando i'll have to try that some time.
linuxcomando
April 2nd, 2002, 07:06 PM
Um Silent why don't you be silent ? What does this have to do with a read only file system? I could give you root password on a
locked unix box and it would still be difficult to screw it up. It can be done but itll take time. So why don't you go back to your windows box and hack away.
silentstalker
April 3rd, 2002, 04:28 AM
Listen man, Im giving a little advice on system security, when you go under this thread your supposed to find that, doesnt matter whatever the first post said.
Now, as for the being silent part and telling me to go back to my windows box, you can kiss my ass. If I want to say something about security, are you going to stop me? Thats the problem in this world. People like you telling those giving advice to shut up, and no one gets the information they should have gotten.
This is AO right? Maybe I've got the site wrong, but aren't we supposed to help sys admins and preach about security? Dont answer that. Although I havent been posting as long, I've been here for quite a while, observing, reading, I know what this site has to offer, and I know that my knowledge could be useful. And if someone like you wants to block me from talking, it doesn't intimidate me, nor change my mind about saying what I want to say. I don't know if you know the United State's First Ammendment. Maybe you don't. It's freedom of speach.
avdven
April 3rd, 2002, 04:33 AM
Disregarding the flames that are undoubtedly about to start between SilentStalker and LinuxCommando, if you wanna do a quick / dirty securing job, check out the NSA's Secure Linux which you can integrate into your current Linux. I know a lot of people distrust the government when it comes to security, but trust me, sometimes they really do know what they're talking about.
I would post a link to the site, but the server seems to be down right now. Once it's back up, simply go to http://www.nsa.gov and click on the Secure Linux link on the home page and you can read about it and download it.
AJ
avdven
April 3rd, 2002, 04:49 AM
Here's an update to my last post. The site's back up and here's the lnk:
http://www.nsa.gov/selinux/index.html
chsh
April 3rd, 2002, 06:10 AM
Presumably you would have to leave /tmp world writeable, which means anyone could mount or write a file into /tmp, and still get access that way. While the immutable attribute might be a good tactic, it is 90% uneffective if they are able to write to the drive at all. And for that matter, why not simply serve everything off of CD...
A really secure distro would be CD-based, and the stuff you actually needed to change would be mounted read only and remounted only when you actually needed to change something. Then again, a secure system would be something you'd want to start building yourself, that way you know exactly what packages you've installed.
Still, if it might slow an intruder down, it's a good idea. :)
chsh
April 3rd, 2002, 06:23 AM
Originally posted here (http://www.AntiOnline.com/showthread.php?threadid=#post) by silentstalker
And let me say something about *nix here ok guys? When putting your sites up on yer *nix boxes, please please please, dont allow anonymous FTP access or unauthorized telnet proxy usage ok?
This is because, when I hack, I first connect to the site anonymously via FTP. Usually theres a good deal of info I can acquire from the site and its box by just looking and the freaking directory listings.
What exactly does this have to do with what was written. Sure, as some general advice to lock down the box, this is an ok idea, but it's irrelevant to this thread.
smirc
April 3rd, 2002, 06:43 AM
A really secure distro would be CD-based, and the stuff you actually needed to change would be mounted read only and remounted only when you actually needed to change something.
It's secure in the sense that it will stop people from making changes to your data. But they can still access the data if they break in. It's a very interesting idea though. Any ideas how would you implement this practically chsh?
secretagent
April 3rd, 2002, 02:27 PM
Originally posted here (http://www.AntiOnline.com/showthread.php?threadid=#post) by chsh
Presumably you would have to leave /tmp world writeable, which means anyone could mount or write a file into /tmp, and still get access that way. While the immutable attribute might be a good tactic, it is 90% uneffective if they are able to write to the drive at all. And for that matter, why not simply serve everything off of CD...
A really secure distro would be CD-based, and the stuff you actually needed to change would be mounted read only and remounted only when you actually needed to change something. Then again, a secure system would be something you'd want to start building yourself, that way you know exactly what packages you've installed.
Still, if it might slow an intruder down, it's a good idea. :)
Originally posted here (http://www.AntiOnline.com/showthread.php?threadid=#post) by smirc
It's secure in the sense that it will stop people from making changes to your data. But they can still access the data if they break in. It's a very interesting idea though. Any ideas how would you implement this practically chsh?
i have heard about floppy and cd-based distributions, mainly suitable for routers/firewalls/gateways that operate this way. boot is off the cd or floppy, any config changes can be saved to a floppy. i can't think of any off the top of my head though.
regards,
mark.
linuxcomando
April 3rd, 2002, 10:25 PM
Silent i apologize for being an ass. You are right were all here to learn about system security.
chsh actually from what i have seen the tmp doesn't have to be writable but even if it was and every thing elese was locked down they would have to load the chattr comm and into the tmp file and then run from there.Its possible but first you would have to know it was the chattr command that did it in the first place. Or even a better idea would be have an ids set up so that everytime someone cd to /tmp it set of a million allerts.
As with the cdrom it works quite well ive tried that. My only issue would be system changes. But Hell burn a new cd. I want to try it on a dvd next.
Ouroboros
April 3rd, 2002, 10:38 PM
Is that really practical, though? You'd have to have a hell of a fast CDRW(or two) and RamBus to keep down the lag, wouldn't you? It's an intriguing idea, and I don't use Linux yet, but it could be feasible, given the right circumstances...
Good thread and great ideas here...
Ouroboros
silentstalker
April 6th, 2002, 01:07 AM
Apology excepted Linuxcommando, this is the kind of quality of people that I expected to find in AO.. curtious. Well, see you all around.
chsh
April 8th, 2002, 04:48 PM
Originally posted here (http://www.AntiOnline.com/showthread.php?threadid=#post) by smirc
It's secure in the sense that it will stop people from making changes to your data. But they can still access the data if they break in. It's a very interesting idea though. Any ideas how would you implement this practically chsh?
Yes, but break-ins become more difficult because the attacker can't upload any trojaned binaries.
It's also probably a good idea in this way to keep /etc/shadow, /etc/passwd, and any other such config files on a floppy with the write protect flipped. That way, if you need to change a password, you just flip the tab to write enabled, make your changes & etc., and then flip it back, no problems at all.
As for how you'd do this, certain directories that have to be writable would be /tmp, but you could specify a size on these, and just use ramdisks for them. It'd take some doing, but overall, the system is much more secure than chattr +i'ing the whole file system (I think so anyways).
Root can chattr -i it unless you have certain kernel patches otherwise. With a ro filesystem, they'd have to upload their hacked binaries to /tmp, which would have limited space, and only be writeable by certain users.
chsh
April 8th, 2002, 04:52 PM
Originally posted here (http://www.AntiOnline.com/showthread.php?threadid=#post) by Ouroboros
Is that really practical, though? You'd have to have a hell of a fast CDRW(or two) and RamBus to keep down the lag, wouldn't you? It's an intriguing idea, and I don't use Linux yet, but it could be feasible, given the right circumstances...
Good thread and great ideas here...
Ouroboros
No, it wouldn't matter. Keep in mind that this setup is only useful for the system files and utilities (ps, etc).. Your config files would be on a floppy (write protected) and for dynamic content-serving webservers, you would be using a drive only for your content (probably the database, and anything else that absolutely must change). Theoretically, unless you NEED to put information into the database, you would have your DB locked down to RO so that you could only do selects as well (without select into).
BTW, entirely CD-Based distributions aren't horrendously slow to use, as the kernel and command line, even X loads into memory. There is only a slight lag time between read on the disc and execution of the application.
Personally, I'm all for not using read-only media, as I feel that neither solution is particularly good. It's better to secure your box, not run suspicious apps as root, and just generally check your logs (setting up tripwire might be a good idea).
Vorlin
April 8th, 2002, 06:17 PM
There's a few problems when making an entire filesystem from / up un-writeable. Nothing can be written by anything and that means swap can't be accessed, /tmp can't be used (there went oracle, which uses tmp heavily), if you're running DHCP, the leases file can't be updated which means the dhcpd will dump and nobody's being served IPs which means your network just went **** up.
It's a good idea and these are only a few things that could go wrong off the top of my head, but I wouldn't make my entire box unwriteable.
--Edit--
More things I just thought of: wtmp/btmp/utmp (dependent on flavor) can't be written when login successfully authenticates/denies someone access. FTP logs can't be updated, syslogs can't be written (I don't know if syslog dies on linux, it does on HP).
If someone smart knows the box is chattr'd then all they have to do is flood the box with regular requests/etc and before too long, the box is dead in the water.
linuxcomando
April 8th, 2002, 06:29 PM
Well another idea you could do is set quotas on all the partions you need like /tmp etc....
to say 100 mb. But you could put everything in a chrooted enviorment. and as long as you don't include a compiler you should be relativly safe. Chroot enviorments can be broken but sometimes it can be a punk. You may even be able to modify the sytem flags by using rdev. If you know any other ways to set the file system unwritable let me know.
Vorlin
April 8th, 2002, 06:31 PM
That's a good point but another thing to realize is, this wouldn't be feasible in a business environment. Most businesses don't care too much about security because they don't know what can be done and therefore, it's always pretty open. Example...the oracle guys come to me and say "We need X number of megs in filesystem Y and we need it to be 0777.". I can preach permissions and whatnot but that gets us nowhere and it ends up being done.
*sigh*
Vorlin
April 8th, 2002, 06:36 PM
Something else you could do, along with quotas, is just use the automounter to mount the /home directory and make everything else (except /tmp) non-writeable by regular users. This provides a one-stop shop to secure and NIS+ is pretty good about security now.
Ratman2
April 8th, 2002, 06:51 PM
Another hint: RUN ONLY THE DAEMONS YOU NEED. my FreeBSD 4.3 box only runs SSH and FTP. Anonyous FTP is NOT allowed :)
linuxcomando
April 8th, 2002, 06:59 PM
hey ratman2 what sucks is ssh is still hackable ;) depending on version.
i never thought about using automounter. Ill prob try that today.
silentstalker
April 10th, 2002, 02:20 AM
Linux linux.. the penguin still glimmering in my eyes... ;)
smirc
April 10th, 2002, 07:00 AM
That's a good point but another thing to realize is, this wouldn't be feasible in a business environment. Most businesses don't care too much about security because they don't know what can be done and therefore, it's always pretty open.
Isn't it funny how security implementations suddenly become much more "feasible" when a business has a major break in and it is publicised ;).
linuxcomando
April 10th, 2002, 07:39 PM
Another really cool idea is to create a LKM that will "hide" all the files you want. Or make it so you have everything in a chroot enviorment.
silentstalker
April 11th, 2002, 12:56 AM
Just now that I'm getting on and off the subject, I feel I need to add something about Security.
Nothing too technical, just some advice:
1) Create a hacker log that executes when connected to the system. The right person will know its a fake. Call it .log or .hacklog or us hackers will know its fake.
2) Change your IP if you have dynamic, so we can't access you as fast.
3) Remember we are hackers, so when messing with us, don't underestimate.
Just some little advice for those starting out on their Linux boxes ;)