Archive for July, 2004

Securing Apache

Friday, July 16th, 2004

Securing Apache (Posted 16 Jul 2004 by Ray)


Most security violations are the result of bad configuration. You should configure your server to run with the minimum level of authorization required for clients to work effectively. For example, if you need to provide access only to certain hosts, configure Apache to listen to requests from only those hosts by editing your httpd.conf file. The rest of this article refers to changes you can make in httpd.conf.

[via Librenix.com | Linux Sysadmin Central]

NUnitAsp First Impressions: I Like It

Friday, July 16th, 2004

NUnitAsp First Impressions: I Like It

I’ve been playing around with NUnitAsp for about 15 minutes now, and I already like it a lot. It gives the ability to make requests to an ASP.NET web page, and then easily verify that the contents of various server controls have rendered correctly. And it plugs into NUnit, so you get that same red/yellow/green display. I even managed to make it populate a login form with my credentials, click the submit button, and verify that it redirected me to the right page. Took about three minutes to write.


In addition to being useful for doing TDD of web apps, this is definitely something that should make writing build verification tests easier. Build verification tests (BVTs) are distinctly different from unit tests, in that they are intended to work against the system as a whole, rather than against a small piece of code. So as one of its last steps, the build script can copy the newly compiled web content to the file system, create a virtual directory, then use nunit-console to run tests that hit various pages, making sure everything works okay as deployed.


[via CraigBlog]

WebDeploy Rocks

Friday, July 16th, 2004

WebDeploy Rocks

I think I blogged about this tool before, but it is worth another post.


WebDeploy


It’s only goal is to take VS web projects and strip out all of the files you do not need for deployment. It’s a super simple tool to use and does a great job.


Great work Matt! Watch here for more news.


[via ScottWater]

Windows Server 2003 Performance Monitor, System Monitor, Or Whatever They Call It Nowadays: Part 2

Friday, July 16th, 2004

Windows Server 2003 Performance Monitor, System Monitor, Or Whatever They Call It Nowadays: Part 2 The actual mechanics of flipping the Performance Monitor switch has changed a bit since Windows NT, but not significantly from Windows 2000. The major components consist of the System Monitor, Performance Logs, and Alerts. The System Monitor simply displays realtime information that is being monitored. Counters can be added by right-clicking on the counter pane in the lower right-hand corner of the window. The System Monitor portion of Performance Monitor is your primary realtime troubleshooting tool.Performance Logs and Alerts is the primary tool by which you can create baselines, document activity, and also track objects and counters over a period of time. The purpose behind creating baselines and tracking data over a period of time is to perform what’s known as trend analysis, which is basically the concept of gathering enough information to be able to point out specific patterns in the data that point to real actions that are going on elsewhere on the system. An example might be if you found that processor queue lengths increased every day around 8am, then you might conclude that the logon traffic generated over the network might be taxing the CPU. Rather than purchasing an additional CPU, you can modify server and domain configurations in such a manner as to perhaps offload some or all of the login processing to another system, and thereby relieve the stress on the CPU. Again, if the current CPU queues at 8am do not exceed the norm CPU queues at that time, you’ll need to look further and deeper for the culprit(s).The Performance Logs and Alerts section is divided into three subsections: Counter Logs, Trace Logs, and Alerts. With Windows NT, all logs were the same, and these divisions didn’t exist, which often made it easier to create a new log rather than use an older one.Counter Logs are the logging equivalent of what you see within System Monitor. Right-clicking on an empty section of the right pane will enable you to create a new log and subsequently define the logfile, its output type (text, binary, etc.), and the objects/counters that the log will maintain. Again, objects are the equivalent of major systems or hardware on the server. Counters track specific events related to a given object. Unlike Windows NT, you have the option for choosing all counters within a single object, or choosing multiple counters that belong to separate objects. The purpose, again, is to enable you to track only the information that has the impact that you are searching for.Trace Logs are something of an extension of the Event Viewer, in that they essentially track everything that the system does, but only after a specific event has occurred, such as a page fault or disk i/o. These events are tracked for a specified period of time, and each triggered trace log is stored in a separate file or in a single FIFO (first in, first out) bucket, which will reduce disk space, and trend analysis capabilities accordingly. Generating a new logfile for each event allows for both quick and enhanced viewing: simply looking at the number of logs generated over a period of time for a page fault might alert you that there are either paging or disk problems on the horizon. Looking at the trace data itself (which must be parsed for viewing) can glean additional specific information about the system at the time the fault occurred.Alerts are similar to trace logs in that they perform one or more tasks based upon a specific event occurrence, however, they offer more flexibility in the types of events that are available, and also the tasks that can be performed. Just like System Monitor and Counter Logs, Alerts are counter-based, and are generated once a set threshold has been met. Once this threshold (or event) has been met, the system has some pretty powerful capabilities. First, it can generate an event in the Event Viewer. It can also send a network message to someone (usually an administrator), or run a program (any program actually) that will page or e-mail someone with information. The true value in the Alerts option lies in the fact that once a threshold has been met, it has the ability to start a Counter Log that has already been saved and configured to handle further monitoring after the event has occurred. As an example, let’s say that page faults are running high, and an alert has been created based upon your pre-existing knowledge of what the norm is, and what you would perceive to be ‘high’ based upon the specific system. Page faults can be due to disk problems or memory problems. Following the road toward the process of elimination, you can set up an alert to subsequently trigger a counter log that monitors both disk and memory performance. The result is that with little or no intervention from you, you can then view the counter log and determine where the offender is, and take the appropriate actions.There are several new commands with Windows Server 2003 which allow you to administer Performance Monitor on the command line. These commands are: LOGMAN, RELOG, TRACERPT, and TYPEPERF. All of these commands involve a hefty syntax. Logman is the command equivalent of Counter Logs; Relog is used to copy logfiles into new files of different filetypes; Tracerpt is the command equivalent of Trace Logs with the additional feature of being able to create comma-delimited files for trace logs, which is a feature that is currently unavailable for the GUI-tool; Typeperf is similar to the TYPE command in that it displays performance monitor data on the screen without requiring that the log be translated (RELOG) into a human-readable format. [Diana Huggins]

[via Lockergnome’s IT Professionals]

Windows Server 2003 Performance Monitor, System Monitor, Or Whatever They Call It Nowadays: Part 1

Friday, July 16th, 2004

Windows Server 2003 Performance Monitor, System Monitor, Or Whatever They Call It Nowadays: Part 1 In the days of Windows NT, it was called Performance Monitor. When Windows 2000 came around, it still had the same executable on the RUN line: PERFMON, but Microsoft buried it within the new MMC formatting, and sometimes called it the “System Monitor”, and other times simply Performance Monitor. System Monitor is actually a realtime component of Performance Monitor, but for the sake of Sanity, we’ll call it Performance Monitor because the title of the window (mysteriously) remains “Performance”. Within Windows 2000 and Windows, Performance Monitor is best accessed from the Start Menu Run line as PERFMON. It can also be accessed through Administrative Tools, or Computer Management.Performance monitor is used to monitor how well and how efficiently the server is functioning. It’s never as easy as it sounds, and Performance Monitor doesn’t have an analysis tool that will help you decipher the performance data that it gathers. Performance Monitor is similar to a high-powered camera on a tripod. Your job is to not only point the Performance camera in the right direction, but also to set the focus correctly in order to gather the data that you need. What’s more, you need to be able to translate that data into English so that you can determine if a problem exists, and where it might be.Before you even delve into Performance Monitor, it’s a good idea to become secure in the concept of Baselining. A Baseline is simply a set of data that depicts the ‘norm’ for a particular object, event, or status. The perfect example of a baseline in the real world would be human body temperature, which is 98.6 degrees Fahrenheit. Any doctor will tell you that this is an average, or guideline, and that different people have different temperatures that are part of their norm, and each person might have deviations from that norm depending upon the time of day, the stress they’re under, and the ambient temperature of the environment they are in. That said, a person whose temperature is 99 might be cause for concern, but then again, if they just woke up, that temperature may be completely normal. This same caliber of knowledge comes in handy when dealing with Performance Monitor just as much as it does with the human being. A novice might look at CPU activity that spikes at 100% and become alarmed, until they realize that this is normal. Performance Monitor can easily send an experienced administrator down the wrong troubleshooting trail if they aren’t at least somewhat aware of what ‘normal’ behavior looks like on the system, and how that behavior changes depending upon the time of day, what the server is doing, what demands are being made upon it, and any number of other considerations. Creating a baseline is done by simply monitoring certain components, such as CPU, Memory, and Hard Disk, over a period of time when the server is known to be healthy and functioning acceptably. The baseline itself, is then stored somewhere safe, and dragged out for comparison when it becomes necessary to troubleshoot problems. In this way, it’s easy to determine where problems may lie without inadvertently heading down the wrong trail.Now here’s the deal, from an exam perspective, these guidelines are a good thing. The real world doesn’t always follow these guidelines, however. Example: you have built a server that, according to Performance Monitor guidelines, needs more RAM. The thing is that, the server functions fine as far as you can tell, and there are no perceived problems whatsoever, so there’s no reason to spend extra money in fixing a problem that doesn’t exist, is there? Of course not! While you may be able to keep this particular tidbit in your mind or documented, the true annoyance occurs when you encounter a REAL problem, and notice that, according to those same Performance Monitor guidelines, the server needs RAM. As a result, you or one of your colleagues may diagnose a RAM issue that won’t really solve the problem. In the meantime, the monetary and business cost to the company would definitely make the boss look at you funny when the problem didn’t go away with new RAM. Baseline information helps avoid this possibility and allows you to better gauge when and where your server is sick and when it’s well.Performance Monitor works by narrowing the focus onto a specific object: usually a piece of hardware or major process, and then further focusing upon a specific activity associated with that object, called a counter. Counters are the actual numbers, data, and statistics that are used to determine what’s going on with the object. If Performance Monitor existed for humans, some of the objects would include the major bodily systems (circulatory, respiratory, metabolic, nervous, etc), and the major organs (heart, lungs, intestine, liver, kidneys, etc). Furthermore, numerous counters would exist for each object, and that would indicate certain activities and status dealing with that object. Counters for the heart might be beats per minute, blood pumped per minute, oxygenated blood received from the lungs, volume of unoxygenated blood received from the body, etc. Now, while it’s not necessary that you understand these particulars of the human body, you do need to know and understand some of the real Server equivalents that can be tracked by Performance Monitor.Now, for the most part, these are the objects that you would normally generate your baselines from. LogicalDisk: Disk monitoring is divided into two sections: physical disk and logical disk. If you consider some of the information in chapter 10, you’ll understand that information about a Logical disk (volume or partition) may indeed be more important than the physical disk, because it can point to issues, corruptions, and performance issues that may be able to better allow you to isolate an offending application or piece of hardware. Memory: Memory is RAM. Memory is used in several different ways, and counters exist for this object that can tell you how efficiently your RAM is working for you. Network Interface: This particular object will give you statistics on how many network packets are being sent and received by the NIC. It will also give you statistics about bad packets and data that are being sent and received by the same NIC. Paging File: Paging is a technology that has been used for many years as an add-on or crutch for systems with insufficient RAM. This is done by literally shifting data from RAM and storing it on the hard disk. The ‘conscious’ system still references the stored RAM as if it were really located on the physical RAM, but in reality, the system’s ‘subconscious’ takes care of moving and addressing data from RAM to storage, and back. More recent versions of Windows require a paging file, even when sufficient memory exists. The purpose mainly lies in some obscure capability to increase speed and enhance productivity. As a result, the paging file and processes that surround it are thrust into the limelight of performance concerns, because an ailing paging file can lead to performance issues just as much as a healthy one can enhance performance. Physical Disk: The physical hard disk is another object that should be monitored occasionally for obvious reasons: a bad hard disk will generate errors. An overloaded hard disk will also have problems and could very well slow down the overall server productivity: especially if the paging file is being heavily used. Processor: The processor object has the ability to monitor the health and welfare of a server’s one or more CPUs. Although a CPU may seem to be an ‘either it works or it doesn’t’ item, it’s not. As with any of these other objects, counters exist that will monitor things such as how many calculations are being performed, how many errors are being generated, and even how long the line of requests is for processes waiting to for CPU attention. (Incidentally, any waiting line in Performance monitor is termed a queue.) [Diana Huggins]

[via Lockergnome’s IT Professionals]

Scripting Languages

Friday, July 16th, 2004

Scripting Languages 16 Jul 2004: “The first scripting language many administrators learn is the Unix shell. For beginners, the nice thing about the shell is that you can work interactively at a command prompt to get used to how the shell operates, what it likes, and what it tends to choke on. You can get to know the error messages and quirks of your chosen shell, all while doing useful things on a day-to-day basis. For example, even a bash shell beginner probably knows the ls, pwd, and echo commands. Early bash scripts wil

[via RootPrompt — Nothing but Unix]

Taming Kerberos

Thursday, July 15th, 2004

Taming Kerberos If you’re using Windows 2000 Server or above, chances are you’re also using Kerberos authentication. It’s time to get to know this three-pronged protocol and learn how to troubleshoot it.

[via Microsoft Certified Professional Magazine Online | Feature Articles]

Gaining Control Through Enterprise Process

Thursday, July 15th, 2004

Gaining Control Through Enterprise Process How new policies and procedures can help you gain control over processes, ranging from patch management to topology changes.

[via Microsoft Certified Professional Magazine Online | Feature Articles]

SysAdmin to SysAdmin: Approaching Perl

Thursday, July 15th, 2004

SysAdmin to SysAdmin: Approaching Perl 15 Jul 2004: “Writing an article about getting started with Perl is a bit like writing an article about getting started with neurosurgery. Sure, I could cover some basics — but it would only leave you scratching your head the first time something comes up that you’ve never seen. I’d hate to see a neurosurgeon in that position! But no matter what you do, there are always times when you just don’t know an answer. A much more horrible fate to suffer is to have no clue where to go to find the answer.

[via RootPrompt — Nothing but Unix]

News: Companies adapt to a zero day world

Tuesday, July 13th, 2004

News: Companies adapt to a zero day world Financial institutions with critical systems and cash on the line are reorganizing to deal with the closing gap between the hole and the patch.

[via SecurityFocus News]

Run Trillian from USB Drive

Monday, July 12th, 2004

Now in addition to firefox running from a USB drive I can get Trillian on it as well.

Why running as non-admin is important

Monday, July 12th, 2004

Why running as non-admin is important

Recently, Nick Wienholt posted a blog entry over on his APress blog about why he doesn’t particularly care about running as a lower-privileged account on his machine when developing software.


With all due respect, this is probably why Nick Wienholt doesn’t come up in the list of names of recognized security experts.


Nick cites two principal reasons why people run as non-admins: “avoiding risk, and writing better software that doesn’t need to run as a local admin”. In his own words, “Both arguments don’t cut it for me.”


He writes,

The risk aspect doesn’t make a lot of sense. Firewalls and virus scanners deal with the risk of viruses quite adequately for me. I understand enough about what is and isn’t risky behaviour to deal with it. I actually think the reverse proposition gives you better security - when you are engaging in risky activity such as browsing less-than-reputable websites or installing untrusted shareware, use a VMWare or Virtual PC session that you throw out when your done (kudos to Mark Brindle for this practice.) If you’re a developer, and you can’t work out what behaviour is risky, you’re a mug - try a different game, or get some training.
Under these same principles, Nick, I would expect that you also drive around town without a seat belt–after all, if you’re not a good enough driver to avoid common everyday things like street signs, light poles and other vehicles, then you should just walk to work or take the train. Clearly, there’s no possible alternative, that you could be blindsided by something you never even saw coming. Of course, in the unlikely eventuality that such a thing does happen, you’ll swear by seat belts for life, but hey, if you can’t realize that opening a web page is risky (thanks to the latest IE vulnerability), then you need to get out of the game or get some training.


He then goes on to address the other issue:

The better software aspect has some merit to it, but if you don’t fully understand what you’re doing, it can give you a false sense of security. Take event sources - you need to be a local admin to create these, but not to use them. I’ve watched developers not running as local admin, and their first reaction to “funny” behaviour is to try the same action as a local admin. In the event source creation scenario, the code will now work because the event source can be created, and when they switch back out of local admin, the code will now work. I would argue that a developer’s machine is so atypical of an average PC or server, trying to get a feel for security and configuration bugs that a user will experience in mostly a waste of time. Not always, but mostly.
Frankly, he’s right when he says, “if you don’t fully understand what you’re doing, it can give you a false sense of security”, but I thoroughly disagree with the statement, “I would argue that a developer’s machine is so atypical of an average PC or server, trying to get a feel for security and configuration bugs that a user will experience is mostly a waste of time.” Balderdash. The fact that 100% of our users out there run as admin is a terrible crime against humanity, and needs to be fixed ASAP; in turn, the only way that we’re going to see a migration of people running their computers as non-admins is if we write software that allows them to run as non-admin. It’s a vicious cycle, but clearly users aren’t going to take the first step; it’s up to us.


At the end of the day, it’s all about the Principle of Least Privilege, the same reason cited for why you never run Web servers or email servers (or any other server, for that matter) as “root” or “Administrator”. Nick’s logic should either apply to those scenarios as well, or else not hold water whatsoever. The Principle of Lease Privilege is about putting additional roadblocks in that will keep your system more secure than not, even in the event of something you never anticipated taking place. Since I’m not a gypsy with the crystal ball (or at least every time I’ve tried to be, the results have been less-than-spectacular) and able to predict the future, I prefer to run with safety’s on.


[via The Mountain of Worthless Information]

Elsewhere: Seven habits of highly secure companies

Monday, July 12th, 2004

Seven habits of highly secure companies Companies, like the humans who make them run, are creatures of habit. Some of those habits can make information systems more secure, rather than less. There’s no such thing as absolute security, of course. But the seven best practices of highly secure companies are a standard against which CEOs can measure their organizations.

[via SecurityFocus News]

10 must do tips to make your Windows PC more secure

Monday, July 12th, 2004

10 must do tips to make your Windows PC more secure

Computer Cops ran an article yesterday on ‘10 must do tips to make your Windows PC more secure ‘.


Here is the summary of that list of tips:


  1. Update your anti-virus software once a week and run a complete test.
  2. Install a firewall.
  3. Update your operating system with the latest patches every 2 weeks.
  4. Do not use Internet Explorer
  5. Be very careful where you give personal information out.
  6. Be very careful opening email attachments
  7. Ignore virus warning emails
  8. Use anti-spyware software
  9. Do not forward emails that claim something will happen if you send it to a certain number of people
  10. Backup up important files


Ok, Ok. It’s a pretty dull list. We know all this. But if you could get your grandma to actually DO THIS… it would be a start :)



[via Dana Epp’s ramblings at the Sanctuary ]

Elsewhere: Web app vulnerabilities on the rise

Friday, July 9th, 2004

Elsewhere: Web app vulnerabilities on the rise Nine out of 10 web applications remain vulnerable to attack even after developers think they have been ‘fixed’, security experts have claimed. A study by security firm I…

[via SecurityFocus News]

Rainbow Crack Not a New Street Drug

Thursday, July 8th, 2004

Rainbow Crack Not a New Street Drug You can roll your own (pardon the pun) cracks for Windows LM passwords.

[via Microsoft Certified Professional Magazine Online | Column Articles]

SecureString in NET v1.1

Thursday, July 8th, 2004

SecureString in NET v1.1

Now this was an interesting find. I just read on Robert Hurlbut’s .Net Blog an interesting post about how Hernan de Lahitte has put together a sample class that works in a similar way as SecureString for .Net 1.1.


If you recall, I blogged about SecureString in Whidbey back in May. I’m really looking forward to Whidbey because of things like this.


Looks like I don’t have to wait… at least for this feature.


[via Dana Epp’s ramblings at the Sanctuary ]

SysAdmin to SysAdmin: Approaching Perl

Wednesday, July 7th, 2004

SysAdmin to SysAdmin: Approaching Perl

[via NewsForge]

Infocus: Multi-Layer Intrusion Detection Systems

Wednesday, July 7th, 2004

Infocus: Multi-Layer Intrusion Detection Systems This article discusses mIDS, a system that brings together many layers of technology into a single monitoring and analysis engine, from integrity monitoring software such as TripWire, to system logs, IDS logs, and firewall logs.

[via SecurityFocus News]

NIST releases Electronic Authentication Guideline

Wednesday, July 7th, 2004

NIST releases Electronic Authentication Guideline

Now this was an interesting find.


NIST has released a set of recommendations in Special Publication 800-63 providing technical guidance to Federal agencies implementing electronic authentication. The recommendation covers remote authentication of users over open networks. It defines technical requirements for each of four levels of assurance in the areas of identity proofing, registration, tokens, authentication protocols and related assertions.


I really liked how they detailed it here. Worth the read.


[via Dana Epp’s ramblings at the Sanctuary ]