Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
As topic says, this project is similar to chkrootkit etc. but does things pretty much with different method and more efficiently. Because project is new and needs more testers i desised announce it here also (i hope im not braking any rule on forum).
Tool is completely free and licensed under GNU GPL. Pretty detailed information can be found from project homepage and download of course.
I published this project also on http://freshmeat.net/projects/nixsecscan/ (for those who dont know, excellent place get nearly any Linux etc. free software and you can publish your own projects there too)
Im working with it daily since it`s my main freelance project atm. I hope it will be useful.
i hope im not braking any rule on forum
It's a draw between Linux Security (as in reaching your audience) and News (where announcements should go) and I think it should be OK here.
Couple of questions though. Just interested OK, nothing else:
What reasons did you have to choose Zsh as shell over Bourne or Bourne Again?
What's the deal with Chkrootkit, Rootkit Hunter (CVS, not 1.2.9) and OSSEC that you choose to start another similar project instead of joining an existing project?
but does things pretty much with different method and more efficiently.
With what rootkits did you test your application?
Can you show us how much qualitatively "better" your app is at the detection of rootkits and hidden processes?
Why did you choose to release it with acompanying binaries but w/o means for us to verify their integrity?
>What reasons did you have to choose Zsh as shell over Bourne or >Bourne Again?
I have done various projects before and been always using Zsh. Mainly it`s just that i have used to use it. But according to my experience Zsh works better for example when you have to play with digits and with decimal points etc.
Also declaring variables/arrays works smoother. For some reason any larger script starts having problems with Bash sooner or later, but this problem always disappears with Zsh.
>What's the deal with Chkrootkit, Rootkit Hunter (CVS, not 1.2.9) >and OSSEC that you choose to start another similar project instead >of joining an existing project?
Main reason is that i have serious trouble "audit" another guy code.
I donīt mean that code is terrible and this is why but each one script and program with their own style ...
>but does things pretty much with different method and more >efficiently.
No offence but for example in chkrootkit, if you have system with a lot of short time processes (for example very active httpd) etc.
It will give you a lot of fakes about hidden pids even its using C program for that. There is not that problem in NiX.
If im honest, only an idiot will backdoor hacked shell with rootkit ... there is many way much lighter and smarter ways to do it.
As mentioned in NiX FAQīs...looking things from default locations
works only against "script kiddos who just desided setup first foudn public rk to the server". What then when its modified but never released as public?
>With what rootkits did you test your application?
>Can you show us how much qualitatively "better" your app is at the detection of rootkits and hidden processes?
So far few modified versions from different public rkīs what others cannot see.
Therefore itīs not any cheap copy from existing ones.
>Why did you choose to release it with acompanying binaries but >w/o means for us to verify their integrity?
Those binaries are from clean Debian 4.0 installation. Binaries what are from bin-utils etc. packages. Only way to solve this issue is include source packages for all needed binaries and make my script compile them statically for each shell...I donīt want to make my script modify anyone running system because of security checks...
You should also ask from other developers why they are providing precompiled binary installations for Mysql server etc. without mean for us to verify those bins integrity...
If you are too paranoid, then you can statically compile yourself into temp directory those bins and then run my program or not use it at all. Completely up to you.
If im honest, only an idiot will backdoor hacked shell with rootkit ... there is many way much lighter and smarter ways to do it.
And NiX checks for those methods, right?
As mentioned in NiX FAQīs...looking things from default locations works only against "script kiddos who just desided setup first foudn public rk to the server". What then when its modified but never released as public?
And NiX covers those too?
>With what rootkits did you test your application?
>Can you show us how much qualitatively "better" your app is at the detection of rootkits and hidden processes?
So far few modified versions from different public rkīs what others cannot see.
Hmm. Would be good PR to throw in some details here. I mean all the others list what they can detect.
Only way to solve this issue is include source packages for all needed binaries and make my script compile them statically for each shell...I donīt want to make my script modify anyone running system because of security checks...
There's other ways like directing people to run it off of a Live CDR (doesn't go well for colo boxen) or use "trusted" static binaries (there's a few Incident Response / Security sites on the 'net that carry those). I'd also like to point out that if the "victim" machine is subverted in a way syscalls get rerouted, any process listings on a live system can't be trusted regardless the method used (except for doing a post-mortem, booting from a Live CD).
You should also ask from other developers why they are providing precompiled binary installations for Mysql server etc. without mean for us to verify those bins integrity...
Simple. If a packages (scripting and) contents can't be trusted I won't install and run it. Period.
If you are too paranoid, then you can statically compile yourself into temp directory those bins and then run my program
Auditing stuff means you don't assume things but question everything. There's nothing like "too paranoid" for that matter. Not that I would accuse you of anything, but for instance the fact your app doesn't use CLI switches and tries to "phone home" (update) w/o telling or way to disable it (other than local fw) is nice if you're into "dumbing it down" for newbie users, but not everyone's cup of tea.
Is not it more better to community that they have more scanners to chose from instead of counting blindly for few only
Sure, if it adds novel or better methods of detecting rootkits and malware others haven't thought of, then this is a good thing. Thanks for your answers, hope you get the attention to get the community involvement thing going. BTW, please view my remarks as constructive criticism, I'm too busy to try and tear your playhouse down.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.