All Things Microsoft > Microsoft Software

How to make your Windows machine more stable and secure

<< < (5/36) > >>

muzzy:
I run rkhunter, chkrootkit, snort and tripwire twice daily. Probably overkill, but, when it comes to computer security, there is no such thing as overkill.

Your machine is probably rooted and you aren't smart enough to know it.

Obviously I cannot be 100% sure my windows is clean, but neither can you. I run VICE, RootkitRevealer, and some of my own stuff every now and then. I've never found anything.

The best thing you can do is format your hard drive, install Linux and learn how to use it properly. Once you learn about Linux, your eyes will be opened to exactly how horrible Windows is and you will be glad you got rid of all M$ products.

I know linux, and it's a horrible mess. Just because the source is available doesn't make it any better technically, it's just a matter of freedom. Yeah, I value freedom and that's good stuff about linux, and I hope all of the computing industry will head to move free direction. Some of the things I dislike about proprietary software is that I'm not supposed to fix them, and I'm not supposed to ask the authors about their design and implementation decisions. If I do, they'll likely threaten to sue. This however isn't just a Microsoft issue, it's got to do with the whole industry.

muzzy:
Now you've left the realm of user-land and entered geek territory. Most users aren't going to be able to do that.

I thought reading sourcecode was geek territory already. Also, your use of the term "user-land" is slightly confusing since it typically means something different than what you imply.

Linux isn't more secure by design, linux is totally braindead when it comes to design. No ACLs by default, everything's a one big hack, it's a wonder the OS works at all.
Doth the pot sayeth unto the kettle: "Thou art black"? Sounds like a Linux-ignorant statement to me. Furthermore, didn't you already concede that maintaining backwards compatability was a source of problems for Win-*? Doesn't doing that make Win-* just as much a "hack"?  :p

The backwards compatibility solutions in windows are indeed a hack, however the whole linux kernel is one big hack. I've had a plenty of lovely experiences regarding it. Few years ago at work, I had to investigate how to let processes keep more files open. Turned out, the constant that defined it in the kernel was redefined in userland as a different value, but only if you included the headers in a specific order. No explanation whatsoever for this was provided anywhere. They've fixed that since then, but all sorts of various kludges exist all over the place.

What comes to security design, there's very little of that anywhere. The overall design is the old *nix design, of filesystem defining the access right, with suid bits set for applications that need greater access. Capabilities came at some point but I'm not aware of them still being used. Regarding the suid, it'd be more secure to have one central database of what's suid and what's not, so nobody's going to create a suidroot shell under some obscure directory and hide it there. And don't you tell me that there are security solutions to detect these, when you were pointing out the existance of security industry being implication of insecure design in Windows :)

Tell me, why are high level applications written in a low level languages?
For speed. I have a couple of projects up at SourceForge: FurCoder and FurCoderCXX. The one and only difference between them is that the former was coded in Ruby, while the latter is a C++ app. Both do exactly the same thing; both use the FOX GUI toolkit for graphics. However, FurCoderCXX is a helluvalot more responsive. There is no waiting for the GUI to update, as this happens with no noticeable lag. The Ruby app takes a couple of seconds to update.

Not being exactly a Ruby programmer, I can't take guesses at what might be going on, but "couple of seconds" sounds like it's not just Ruby's fault. Highlevel languages can be just as fast as C++, for example Ocaml has been claimed to generate code that rivals Intel's C++ compiler.

So what? The W3C sets standards for HTML. We all know how reliable MS has already proved to be when it comes to making Inter-nut Expl-Horror compliant to standards.  :rolleyes:  Perhaps they will do better with .NET and the ECMA, but I'm certainly not going to bet on that.  :p

HTML standards leave much for interpretation, while the CLR doesn't do that. The "problem" you will be seeing is same that happened with java, Microsoft will implement their proprietary packages and will encourage people to develop against them. This means that these applications will not run on other systems until someone reimplements the said packages.

How to fight this? Make sure someone else provides plenty of useful packages for .NET, ofcourse. There's gtk# already as a replacement to Windows.Forms, and hopefully others will follow.

Regarding your comment about application providers, I agree that the idea of them is somewhat flawed, but not as horrible as you'd think. Can you imagine buying for a linux shell, where someone else takes care of the software upgrades and patching and stuff? Yeah? Why is the same thing with windows any different? Obviously there's a slight difference in balance here, but if application service providers and application developers are isolated from each other, it could just work.

Kintaro:
What comes to security design, there's very little of that anywhere. The overall design is the old *nix design, of filesystem defining the access right, with suid bits set for applications that need greater access. Capabilities came at some point but I'm not aware of them still being used. Regarding the suid, it'd be more secure to have one central database of what's suid and what's not, so nobody's going to create a suidroot shell under some obscure directory and hide it there. And don't you tell me that there are security solutions to detect these, when you were pointing out the existance of security industry being implication of insecure design in Windows

PAM.

Good distros all use it.

muzzy:
Oh my, I'm replying to a lot of people now, am I not? Well well, here I go again...

For an untrusted application to run in a users homedirectory, the user first has to let it be chmod +x in the first place.

Ohyeah. Since linux apps are so hard to install, there won't be an issue of running untrusted applications. Or if they're ran purposedly, they're being trusted huh? Nice way to get out of the real issue :)

If you could trojan a user into installing a keylogger as an xpi or something, it would infect a few people. However if anything like that happens, and similar things have happened in the past, there are many geeks on standby that are going to view the code out of interest, and will see it.

Will these geeks also go clean up everyone's systems? Didn't think so. When something like that happens in windows, there are various anti-virus companies and a lot of geeks as well to check it out. That doesn't make the problem go away, it's just another step in the security process, you still need to recover from the infection. How do you get the infected people to fix their systems? The problem is same that exists with windows. It's only a bigger problem in windows because windows is more popular.

That system is not perfect, and your right: no system is. Nonetheless I have had more problems that "just arise" on Windows then any other operating system. When my laptop was running Windows the network stack would fuck up and stop letting anything work with TCP, UDP, or anything important. Restarting the adapter would fix this, however often it would stop responding, the stupid little taskbar icon, the window for "repair", or even if I tried doing it by just disabling and renableing the adapter. Other bizarre crashes and other things kept happening.

Hardware or driver issue. I cannot see how this is different from using linux and running a proprietary driver. Due to how modern operating systems are designed, drivers have a little bit too much freedom to operate. I have a kind of "dream OS", which would involve a Xen-like approach of separating the guest OS and host OS, with drivers being in the simple host OS layer. And here, the drivers would run under some sort of JIT VM, bytecode, so they couldn't crash the damn system. Well, one can dream. Perhaps in future, once the .NET implementations get stronger, this kind of approach will become viable as well.

As for the comeing Longhorn and .NET objects behind it: This is a new model to use, and will probably create problems. Microsoft will probably end up using a load of legacy code to save time on the release (Microsoft always do).

I cannot see any problem with using legacy code here. Once the stuff works, portions can be rewritten to be "more pure" if desired. However since the .NET will create a completely new machine abstraction level, anything that goes underneath it is not an issue. It's just the machine implementation, and it can be changed anytime without affecting stuff above it.

The other things with new models is it will attract new security flaws, and ideas in the darker areas of computing.

I don't quite understand what you mean with this, are you saying that a beast you know is better than one you don't? Definitely there will be issues that need to be resolved, but with the VM being a single point of failure for many security related issues, you won't have to go running around patching all applications if a common security issue is found. It only has to be patched once, in the VM.

As for TCPA, it is the stupidest thing ever: It will allow users less control over there system. How the hell is that security? It is not security, its the biggest security hole I have ever heard of. What if someone does a man in the middle attack of the TCPA providers? Your fucked, and everyone else using it is as well.

You are making some wild assumptions here, and I think it's because of the TCPA FUD that's been going around. You know, pretty much everything TCPA does can ALREADY be done with software. You don't think so? See Xen and what it does: http://www.cl.cam.ac.uk/Research/SRG/netos/xen/ ... this same approach could be used to implement a lot of the TCPA functionality. However, a hardware support on some level is needed to make things straightforward. What's I've read about TCPA, it seems to be damn good stuff, and I can't wait to get to play with it.

Also I will point out that Microsoft Windows still has stupid methods of permissions, that are its biggest problems. Executables are executable via a silly file extension, which makes things MUCH easier for a hacker. Not only that but it hides in unsuspecting file extensions like .SCR for example.

And if you unzip or tar x some file under linux, the executable metadata doesn't get propagated to the filesystem? Damn, it does. There you go. Ofcourse, the windows issue is that the metadata isn't for the OS, it's for the GUI. All files are potentially executables and you can CreateProcess() against even a .txt file.
However, the lack of metadata isn't the issue here. The issue is overloading of doubleclicking. In some cases, it runs the associated program. In some cases, it runs the file itself as a program. This isn't necessarily bad, but it requires user to know the difference, and in some cases, it gets relatively tough. Another example of the same issue is how command prompt overloads file execution. If you type a filename in cmd.exe, it first tries to CreateProcess() and then it tries to check for file associations and stuff. The problem is, CreateProcess() can start an executable no matter the filename. Try this: rename the extension of some exe to "txt", and try to run it in the command prompt. You'll see that it still runs it, since the extension resolution only happens afterwards.

So, the problem is overloading of different operations. This is definitely bad security, as seen elsewhere where it has happened. Another example of it would be Outlook's midi-executable hole that was found (and fixed) long ago. Attach an executable, and claim it has a .mid mime-type, then require it be played as a background sound. The implementation used some overloaded mechanism to process the file, that was able to do more than was required, and definitely more than was expected. Result: the damn file ran when mail was read.

I agree that this is bad design, however there's no going back in win32-land, since ShellExecute() and similar things are depended on by everyone. Getting to .NET is the ultimate solution to fix the mess, since that lets us drop the win32 crap behind.

Microsoft does not have anything that really compares to what runs on Linux, or what is being shipped with most good distros. Windows' shipped firewall is very backwards in most respects. With iptables you can put a lot more into the rules, you can restrict individual users, individual groups, and all kinds of stuff. Then there are things like snort which provide even better security because it actually looks at the data and works with that.

Obviously you're only comparing the things that you want to. The windows native kernel is superior to that of linux, except in some specific things. Unfortunately, these specific things are quite significant, but the windows kernel still compares pretty damn well to linux. Yeah, I'd like better networking mechanisms, too, that's one thing where linux wins. If you want a router that performs complex traffic shaping (weighted round robin, for example), there aren't really any alternatives than using linux/iptables/tc and friends. This might be the only reason I'll ever get a linux system running at home, but for now I haven't had such a strong need for a traffic shaper.

What comes to snort, I've found it gives way too many false positives to be useful at all. It'd take a year to configure it to only show sane things.

Then there is SELinux, which also comes with Fedora Core 3 and probably other distros. SELinux is a lot more versatile then even an ACL setup.

There have been some funny kernel patches for linux around for quite a while now, but I hadn't seen any real distro use any of it. I hadn't heard that FC3 ships with it by default, and that definitely makes things interesting. With such patches, you can actually have a linux system that I'll admit is more secure than Windows. However, for now, I'll wait to see these things actually get more widely used.

muzzy:
PAM

PAM definitely solves some problems, but only relating to user authentication. Why are there still so many suidroot apps on the system, and why are SSH vulnerabilities still remote root holes? :)

Navigation

[0] Message Index

[#] Next page

[*] Previous page