Slashdot Mirror

I can't give you an absolute or who to trust, or trust more, but Qihoo ranks at the bottom of the list IMHO.

This thread has got me really depressed about AV software - even the one you recommended would cause me to think twice - from their FAQ:

Yes! Both VIPRE Antivirus 2015 and VIPRE Internet Security 2015 automatically remove your existing antivirus program and replace it with VIPRE.

Any software that wants to remove/disable existing AV is going to be regarded as suspect. I did a quick search for a tripwire system and found this which appears (on the face of it) to be legit. Will look at the sources for it once I get home, but at least an open-source system won't be as compromised as a downloaded binary.

That sounds like tripwire to me.

Plus, that link doesn't lead to information about blockwatch, but instead immediately tries to download a file. Not very friendly.

- Do not allow write access to any essential binaries (like sshd, ls, and so on). If you have to, make sure you have a stealthy daemon checking the hashes of all critical binaries at regular intervals to make sure they have not been tampered with.

I'm sure there are plenty of other such systems, but Tripwire ( http://www.tripwire.org/ ) is one of the more popular tools to keep a check on your system and warn you immediately if it detects tampering attempts.

- After the initial system install, make a dump of the syscalls table of your kernel. Check it regularly to make sure it has not been tampered with (kernelspace rootkits usually hijack this table).

AFAIK Tripwire handles this, too.

But... isn't that already done?

Isn't tripwire available for Windows? http://www.tripwire.org/ (sorry, I only have experience with the Linux version, part of the standard Fedora/Redhat repositories).

I've been using it for years on my systems. Just seems to be a sensible part of a protection plan. (I got a laptop rooted once -- tripwire detected it, and I've never been without it since).

Not the BSOD.
If the OP had used open source "tripwire" on known-good files in each filesystem on his Macbook, and saved the resultant data output to a USB thumbdrive formatted with FAT32, the OP would have had a good chance of determining all corrupted files. In this case, an ounce of prevention would have prevented several pounds of "cure".

Check out http://tripwire.org./

Normally, I'd agree, but the OP specifically talked about a user supplied password to be able to add a plugin. That password could control access to a private key that is used to sign a hash of the valid list of plugins. On startup, Firefox could use the public key to validate the list of plugins, and throw up a big error if the list is invalid (because someone snuck one in).

Of course, recovering from this state would be difficult -- maybe Firefox could provide a way to disable plugins until the new list matched it's hash? But it would at least alert the user that something fishy was going on. Think of it as a tripwire for plugins.

Agreed. I usually throw in tripwire too from the start, it makes things easier later on.

Trusted Build Agents are the final twelth step in my Twelve Step TrustABLE IT blog entry.

Also is already possible to secure Linux desktops the "right way"

(#75791 by guest NZheretic in response to Mainstream means more malicious code for Linux (SearchSecurity.com).)

On Windows, most of the viruses are e-mail borne. On the Linux side, today and in the future, viruses are network-aware, and [they] take advantage of vulnerabilities in networks or systems to infect machines. The Slapper worm, for example, attacked vulnerabilities in OpenSSL and Apache.

I have deployed Linux on the desktop (RH8+Ximian to RH9+StarOffice) in an enterprise and they do not suffer from such problems for long.
1) The only network service the desktop systems expose is OpenSSH and the Iptables limit access from only three addresses.( We use a custom script with ssh to keep the systems rpms uptodate from a private mirror).
2) The iptables are configured to allow the desktops client services to connect only to the specified server.
3) The /usr partions are mounted read only and the /tmp, /home, /var directories are mounted non executable.
4) None of the users have, or need, root access. They have access to printer setting etc via Webmin's Usermin which runs on a dedicated server.
5) Mounting the users home directory required shares etc ( we use Samba for domain, file and print services ) is performed by script when the user logs in.
6) We update all the desktops within minutes of a updated RPM package becoming available. The window of opportunity for any disclosed vulnerability is very small.
7) We schedule Tripwire to check the intergrity of the desktops a couple time a day.

There are certainly hundreds of cases of prior art, and Tripwire is probably one of them. It computes and maintains a database of hashes for all the files on a file system to check for intrusions and corruption. The wiki entry says it first surfaced in 1992

This is [to me] the most irksome characteristic of wiki-people: even when there is an obviously better link , e.g. this page (which also provides the 1992 date), they insist on linking to a non-vetted, potentially spurious source like wikipedia.

There is also Tripwire.org for those people that get hives reading about commercial products.

Are you going to take him at face value and continue using the system as is, after patching the security hole that let him in?

Am I a competent sysadmin in this scenario? If "yes," then I guess I'm probably running a tripwire of some sort. So I boot from CD, take a look at what's been changed, and fix it. If I'm really on the ball, I'm using something like radmind, in which case I still boot from CD, but I let radmind reverse any damage that had been done.

:w

They should know how to protect the system from disaster and attack. Tips on hardening should include:

• Hardening a new install with the Bastille Linux scripts. What these are and what they do.
• IP tables configuration. What IP tables is, why it's important, and how to configure it. This may or may not be in relation to Bastille.
• Tripwire. A PITA to configure, but *really* useful in knowing what is happening on the server.
• Kernel options. Do you need loadable modules on a production server? Disable them if not. Do you need USB or CDROM access? Remove them from the kernel. If it's not needed, don't include it.
• Kernel upgrades. When and why. Just because the latest 2.6.87 kernel has been released is no reason to put it in. However, if there is a remote root 'sploit posted to Bugtraq for the current kernel, everything else is a lower priority.
• BugTraq and other security lists. What they are and why they should be monitored.
• Application security patches. Like kernel upgrades, guidelines on why and when production apps should or should not (or must) be upgraded.

• tar, and it's more esoteric options, such as multi-volume tarfiles, dump levels, etc.
• Rotation schemes. What is Grandfather, Father, Son? Why is it important to do this? What is the difference between a differential and an incremental backup?
• Backup media. Redundant hard drive? CDR? DVD-R? Tape? Onsite vs offsite?
• Recovery procedures. Ok, you've got a backup. What do you do if you need it? You have tested the tapes, right? :)

grnbrg.

Not sure how helpful this will be in huge environments, I live in the small to midsize market, but here are some tools that I have found useful in the past:
Not exactly a monitoring tool, but definitely the most versatile all around auditor I have ever found: Nessus.
Ettercap is a good sniffer.
The MRTG tool has been a godsend when I have had managed devices to deal with, and I have heard very good things about the RRD tool and Cacti.
Tripwire is freely available for Linux and the BSDs, though the Win32 version has not been open-sourced.
One tool I have not been able to find in F/OSS is a Windows event log monitor (though believe me I'm still looking).

...in those attacks, like they have in the numerous Microsoft leaks. Imagine the strife we'd be in if they stole the source to Debian!

But seriously, how shall I put this? ChkRootKit, TripWire, AIDE, FICC, ProSum, Toby, msec, Nessus, LSAT, Saint, LIDS and of course if you want totally proactive, try SELinux, Medusa DS9 or OpenWall. That's hardly an exhaustive list, but it does hit many of the highlights. Boy, youse bin livin in a monoculture too damn long!

NMAP Port scanner from insecure.org

SATAN the aformentioned Security Admin Tool for Analyzing Networks.

TripWire for checking when someone's trying to access your system, and stopping them.

Shorewall a relatively easy to set up firewall-in-a-box for Linux.

In addition the study only covered successful attacks. How many unsuccessful ones were there? The measure of vulnerability should surely be the ratio of successful/failed attacks, not just a raw number.

Finally how were these attack figures reached? Where these based on government/company IT figures? (in which case factor in maturity of systems/staff and how much easier breaches can be discovered in Linux using free tools like Tripwire) Or packet sniffing of certain domains? (Linux is used by more domains, some of which are set up deliberately to be hacked).

The only conclusion that can be safely drawn is that Linux appears to be a more popular target for manual attack - whether by necessity (automated attacks being far harder), desire (more of a challenge) or familiarity (easier to learn the internals of a free system, especially if you lack the money/connections needed for commercial counterparts). And security is hardly ignored on Linux either - with tools like ipfilters, tcpwrappers and Bastille, admins have little excuse for running a non-secure system.

Tripwire keeps a key-signed index of file hash values. It checks files nightly, and looks for changed files. Since the index of hash values is protected by PK signature, it's seen as a secure method to audit file changes.

I cron tripwire on an old BSD box I have running and it works well enough. Linxen:

Tripwire.org

FAQ

sourceforge page

I cron tripwire on an old BSD box I have running and it works well enough. Linxen:

Tripwire.org

FAQ

sourceforge page

Have all of you gone insane?

No, it's just that we can read, apparently unlike you. The system that's being described seems to resemble tripwire combined with a public key system more than anything else.

To quote from the TCPA rebuttal paper: "TCPA was designed to protect the user's data from external atack, not from attack by the owner. Defending against owner attack is a much harder problem in hardware tamper resistance."

Tripwire

I keep my tripwire database on a floppy. It's much easier to flip the read-only tab than to burn it on a CDRW every time I update it.

>Or compromise the servers where you get your .debs.
>...
>Obviously nobody would have installed (and be updating) a package called "rootkit," but the scripts could be piggybacked on any security update.

First, it doesn't have to be installed through the updates to the server. It's probably actually easier to find some misconfig'd server or vulnerable daemon out there, establish remote access, and install the rootkit from ther. But you do have a point and that's why I just subscribe to bugtraq, etc. and never trust things like the .deb/.rpm updates.

Second, why worry about a rootkit when the underlying problem is how they get IN before the rootkit. I would definitely reccomend looking at securing-debian-howtofor those of you who are unsure of your debian security.

If the only problem were a rootkit changing binaries and installing a backdoor, then all an admin has to do is put a firewall in front of the server and control all the ports so that any unsolicited traffic from getting to the "unknown" daemon listening on port xyz plus stop ALL unsolicited tcp/udp/icmp traffic from leaving the server unless a handshake was completed. Most stateful pcket filters can do this. If your real paranoid, put an IDS (ie: snort www.snort.org) between the server and the outside to look for irregular activity. Worried about one of your services? Find a Proxy to inspect the connections. Worried about corrupt binaries? Install an integrity checker (ie:tripwire. www.tripwire.org)

Obviously, securing a server will require much more than this. Check out Sans.org. But AT A MINIMUM, the above should have been in place already. Hope that helps at least somebody out there.

Scanning for virii on Sourceforge is probably a waste of time and resources.

From the description of this 'virus', Tripwire would find any infected files.

What? You're not running Tripwire?

In real-time: FileMon installs a driver that transparently tracks filesystem accesses. If you want to see what accesses the drive every five seconds, this is a good tool for it.

If you want to see what files were modified, use programs like AIDE (on Unix) or Tripwire (on Unix or Windows 2k/NT, apparently), or InstallWatch (Windows). If you just want to see where an install program left its files, this is good. If a given program is just reading (not writing) files, or leaving temp files in ignored directories, then this is not effective.

You can examine the source for AIDE & Tripwire, so this isn't a chicken-and-egg problem.

You ever hear of tripwire? Every change in the filesystem can be monitored. Someone will catch it. The FBI has great resources, but not like the collective consciousness of the net.

"So you have all this incredibly nasty software sitting happily on some (criminal enough to get the FBI's attention) hacker's computer, conveniently within his reach."

Exactly.

They'll spend $30,000,000 of your money (if you are a U.S. citizen) on software to exploit security flaws. Then they'll broadcast that software free to criminals. This will teach some of the criminals how to exploit security flaws. Then there will be more crime. Then the FBI will get more money to fight crime. They will see this as a big success.

The CIA used this same method in Afghanistan. They trained Arabs in terrorism. Read about that in: What should be the Response to Violence?

How many criminals smart enough to use computers will be smart enough to run Tripwire, or some program like it, such as the one that comes with Mandrake? At least some, is my guess. Those criminals will know immediately that their computers have been compromised. The criminals will then use the compromised computers to write email saying how much they believe in law enforcement, and to send Paypal payments to charities.

Uhm..... One word:tripwire. Doesn't use gpg, but instead keeps track of quite a number of different file attributes. Here is a little more info.

"The Presentation overmodule works with the Platform overmodule to give programs access to a powerful and platform-independent visual interface that can present the output of programs as anything from terminal text to a 3-dimensional Hollywood-style GUI called "Tripwire" (which does shadows, transparencies, textures and light rendering better than most video game engines) depending on what the user chooses to see and what the hardware can handle."

Tripwire!? It was so revolutionary and new that they had to name it after an existing, well known security tool?

This has got to be completely made up.

• Operating System: Although OpenBSD is generally regarded as the best Freenix in terms of security, GNU/Linux is under more active development, faster, more user friendly and supports far more software packages and types of hardware than OpenBSD (sorry Theo, much respect...). I, along with most of the other admins and users are more familiar with a GNU environment. The distribution we use is Debian. I chose Debian for several reasons: free (libre and gratis), strong package system and reliability. It hasn't let me down. I do prefer Slackware on my personal box, since the -current tree is more stable than Debian's unstable. However, Debian's package system is nicer and provides many things that Slackware lacks (I may abandon Slackware as soon as Debian supports XF4 and kernel 2.4 by default in stable). Debian also keeps up to date on security issues.
• Kernel: We now run a Linux 2.4 kernel. Although most security tools/patches are 2.2 only, the mature (READ: usable) ones have been ported to kernel 2.4. I'm confident that more will follow. 2.2 is dead. We have disabled modules entirely in our kernel to prevent hax0ring and to avoid using modules (does anyone else hate them?). We only have a few drivers enabled. Besides helping performance, this protects against hostile code injection into the kernel. It is possible for a clever coder to inject code into a non-modular kernel, but most rootkits use kernel modules. Not allowing kernel modules and using 2.4, prevents us from using some really cool security tools like LOMAC. However, I found that LOMAC did not play nicely with OpenWall's Secure Linux patch (or cron, or init or getty ...). When Lomac behaves nicer, it will be added (I'd also like to see it as a patch rather than a module). Currently, we are using the GetRewted.net patch which provides lots of security enhancements. We may be adding more secure kernel additions such as the NSA's Security Enhanced Linux. However, at this time, we feel that the current kernel security model is both secure and usable. If you have any neat kernel goodies we might like, tell us.
• Firewall: Note that we are NOT running any sort of real firewall. We feel that the extra kernel overhead of the firewall hurts performance and adds needless complexity to the server. Since we are NOT trusting local (ie: users with shell access) anyway, we feel that a firewall is basically useless since Linux's TCP/IP stack is already fault-tolerant, mature and robust. We augmented the TCP/IP stack with this shell script to limit our vulnerability to DoS attacks. Firewalling services should not be needed if your services are secure (run with minimal priviliges and SECURE by design and condiguration). Eventually we may drop an OpenBSD or Linux 2.4 firewall in front of the server as a measure for restricting local users ability to portscan, DoS and exploit remote hosts.
• Authentication / Login: Remote interactive sessions are only supported over ssh (and we run OpenSSH). Telnet is not allowed. Rhosts authentication is not allowed. I've looked at forcing people to use S/Keys, but it is a real pain in the ass on both ends. We are currently allowing FTP in. When I'm confident that all the users can get a good graphical scp/sftp client for their platform, I'll kill FTP. Since I'm not relying on trusting local users anyway, this is more a security concern for individual users. I'm considering locking some users who don't use their shells out of real shell access.
• Users: I only make accounts for people I know personally. I also monitor user login s and their activity using whowatch and process accounting. I'm suspicious of logins from weird hosts. I also use PAM to set resource limits.
• Monitoring: We watch out for network nastiness with Snort which is an AWESOME IDS. We monitor its logs and other system activity with Psionic's LogCheck. Occasionally, I'll audit the machines for weird ports using nmap and Nessus, both of which are REALLY nice. I'll also routinely verify system integrity using a combination of Tripwire and chkrootkit, on a system booted from a known CLEAN floppy containing the tools.

Well, perhaps tripwire would be an option.

Tripwire has split into a commerical version and an open source version.
--

Tripwire (under GPL since last year) is available at tripwire.org or through their Sourceforge project. This should have been posted with the story (if he's going to mention it, why not link it).

Research what laptop will run Linux real well.

Get some cash together and drive to a distant city and buy a laptop right off the store shelves. There won't be a chance for anyone to plant a bug in it.

Wipe the hard drive and install Linux on it. Install the Linux encrypting kernel and keep all your real files on an encrypted volume.

Install Tripwire on the machine - it verifies the integrity of important files to be sure they aren't patched.

Learn how to administrate your machine effectively. Always log in as a non-priveliged user and never become root unless you really need to.

Learn about security and tighten down your machine. If you care about security on your laptop you're not going to be running a webserver but I bet a lot of you are running both Apache and SAMBA on a standalone user machine without even knowing it. The more services that are disabled the less anyone can screw with it, even on a non-networked machine.

Don't ever let the machine leave your sight. If you have to put it away, lock it in a safe. Do something to the safe that will enable you to tell if someone's blackbagged you - something like the trick of wedging a matchstick in your door when you leave, but something more concealed. If you find the matchstick on the ground when you return, someone's opened your door.

Best of all don't use a computer for anything of real importance. You can find out why you shouldn't by reading The Forum on Risks to the Public in Computers and Related Systems for a while.

Michael D. Crawford
GoingWare Inc

Has anybody else wondered why only Linux versions of software are made open source? For example, "At the present time, Tripwire has no plans to make its commercial UNIX versions or NT available as open source." (from the FAQ) and AFAIK Troll Tech has made only the Linux version of qt open.

Is the reason the background of the OS? Linux users are used to having the source and a product which doesn't offer source can't expect a very wide acceptance in the Linux world (see for example some of the originally-closed drivers). In Windows, everybody is used to proprietary software, so they couldn't care less.

Another peculiar thing is, why do they keep different versions for different architechtures? I'd think it would be easier to manage only one code base with #ifdef's or separate low-level files. It might be possible that they only omit the Windows-specific files, but in this case any GPL additions to the Linux version (made by users) couldn't be compiled into the Windows version.

This, on the other hand, would mean that the Linux version would inevitably become better than the corresponding Windows version. The only legal way they could get the same features into the Windows version would be to code them themselves from scratch, and who's to say they didn't use any GPL-only code? Or do they demand everybody who contributes anything to dual-licence it so they can use it in the closed Windows version also?

Any ideas, anyone?

See the news from tripwire's new site TripWire.org which has the skinny from Tripwire directly. LinuxPower has an article. As does IGN over here.

T here is also a great article here regarding file system monitoring - and alternatives (additional OpenSource) to TripWire. Not quite as relevant now that TripWire is OpenSource but still a good read.

Quoth the "Open Source Tripwire for Linux FAQ":

What is your strategy for the other operating systems that Tripwire supports? Will they become open source?

There are currently no plans to make open source any of the other UNIX versions or the NT version of Tripwire.

Of course, since the open source release is GPLed, porting it to other OSes is perfectly legitimate.

Free (as in speech) tripwire.

Free (as in beer) posters. (You just have to figure out how to get past their poorly coded form validation to order one...).

TTFN

Louis Wu

Thinking is one of hardest types of work.

One thing that's odd - This only applies to Tripwire for Linux.

I don't understand that... the code is either GPLed or it isn't. If they GPL the source of the linux version, whtat's to stop anyone from porting & compling on another platform? Open source is not platform dependant...

I was searching around on their site, and found something here:

This license only applies to the currently distributed version of Linux 2.2.1 available from www.tripwire.com. It is offered here as a service to the Linux community, who may already be using Tripwire for Linux. This does not apply to the upcoming Open Source release which will use the GPL

So, they just changed the current license on the downloadable linux version (not open source). That's the only thing I can find that only pertains only to linux. Does anyone see it explicitly mentioned on the site that the open source release is going to be "linux only" somehow?