Best IT Blog

Sample Production Server Cut-over Checklist

Posted in O S (375) by Guest on the January 11th, 2011

Sample server details to consider:

  • Administrator / Root Administration in place
  • User Security is in place
  • File system NAS / DAS storage setup
  • File Shares Setup connections
  • Printer Server Setup connections
  • Syncronize Time System Server Setup, OS Build, connections
  • F5 Cache server setup for new server
  • Server Certificate Server loaded with copy of current production
  • Install dependent secondary server applications
  • Install dependent primary server applications
  • Validate all required server basic data is complete in staging
  • Snapshot backup of server
  • Cleanup server tmp / work files for cut-over
  • Document server setup
  • Document server transition details for operations
Comments Off on Sample Production Server Cut-over Checklist

Role Based Access Controls – SUDO suggestions

Posted in Information Rights Management (100) by Guest on the January 10th, 2011

Sudo: A Unix command enabling accounting for root actions

Sudo (superuser do) intends to replace su; it allows certain users (or groups of users) to run some (or all) commands as root while logging all commands and arguments.

Create appropriate Web, Application and Service dedicated Groups to sandbox priveleges. Create such groups as:

OS_Monitoring (syslogs)
OS_Monitoring (NOC, SOC, GNOC)
SUDO_GRP (sudo_all)


Development / QA environments:

SUDO_GRP (sudo_all)

Comments Off on Role Based Access Controls – SUDO suggestions

eHealth – Corelating Interface Indexes to Interface Names

Posted in Networking (340) by Guest on the January 9th, 2011

Alarms may be generated in Spectrum by either Spectrum itself or eHealth that reference interfaces that seem to have no tie to the device itself. This is because eHealth might refer to the interface using the MIB Index instead of the name.  The MIB indexes can be quickly correlated with interface name using Spectrum one click.  Follow the following steps to view the MIB index next to the interface name.

Select the actual device in Spectrum.  The easiest way to do this when responding to an alarm is to simply double click on the actual alarms,

This will bring you to the device next click on the Interfaces tab in the “Component Detail”. Be sure to select the appropriate device before in step 1.

Right click on the column names in the “Interfaces” tab to bring up the “Table Preferences.”  Select “Index” as shown below:

1.       Name
2.       Condition
3.       Status
4.       Type
5.       Description
6.       Index
7.       Board.Port
8.       Mac Address
9.       IP Address
10.    Port Speed
11.    Duplex Status
12.    Trunk Membership
13.    Device Connected
14.    Port Connected
15.    Network Link Type
16.    % Utilization
17.    IP Alias
18.    IP Name

The “Index” column is now shown.  It can be moved closer to the description for better viewing if desired.

Comments Off on eHealth – Corelating Interface Indexes to Interface Names

Sample Network Management Project requirements

Posted in Networking (340) by Guest on the January 8th, 2011

First Tier Network Management Solution support

Support Datacenters, Main sites / Disaster Recovery Sites:

Graphically configuring and monitoring all equipment
Firewalls, Routers, Switches, Modems, Servers, SAN’s, NAS’s, PC’s Network Printers, UPS… etc,

Issue periodical reports:

Daily, weekly, monthly…
Device, configurations & connectivity


Network Fault Management:

Network connectivity between branches needs:

Spectrum Network Fault Management:

Best-in-class technology, platform-independent
Comply with regulatory and governance requirements
Automate troubleshooting through a full suite of tools
Minimize risk  and Mean-Time-To-Repair


Identify network assets
Build an inductive topology map
Understand relationships and inter-dependencies

Root Cause and Impact Analysis:

Root Cause Analysis
Correlate  symptoms or events
Pinpoint the degraded or failed network component
Indicate where the true problem is
Impact Analysis

What services and branches are impacted

Alarm Notification:

Configure thresholds and monitor key performance indicators: 
CPU, Memory, Storage, Interfaces…
Automate notification to email
Launch scripts for corrective actions
Alarm filtering and differentiation by colors
Redundancy between management servers
If primary server fails, the secondary automatically takes over

Manage device configurations and monitor changes:

Configuration capture
Configuration edit 
Configuration load and restore
Configuration comparison and validation
Automated scheduling

Report Manager:

Comprehensive reporting on availability, response time, assets, alarms, and service quality metrics

Comments Off on Sample Network Management Project requirements

Web Server Security – Suggestions

Posted in Application by Guest on the January 7th, 2011

Common Web Vulnerabilities

  • Buffer Overflow Attacks
  • Denial of Service
  • Attacks on vulnerable scripts
  • URL Manipulation
  • Sniffing / Spoofing Credentials
  • Client Parameter Manipulation
  • Brute Force Attacks
  • Web Server Fingerprinting 
  • Web Defacements

Take web servers seriously, server security is essential for web security, recommendations:

Harden servers from attack

• Use a hardening guide like CIS or MS
• Use Windows Security Templates
• Audit Users, Groups and Permissions
• Enable DEP to prevent buffer overflows

• Follow Best Practiceso SSL Certificate
o Patching, Host Based Firewall & Anti-Virus
o Password Policy and Lockout

PHP, Java ServletEngine, Mod_PERL, etc

• Secure configuration
o PHP Suhos in& Hardening Patch
o PHP Security Consortium -Security Guide
o Perl security Guide
• Include framework in patch cycle

Client & Browser Security

• What’s a Browser? Word, RSS, OS, etc
• These are all vulnerable to web attacks
• Educate users about HTTPS
• Audit ActiveX controls
o Don’t Allow installation of unsigned ActiveX
o Don’t Prompt user to install unsigned ActiveX
• Patch Helper Applications Secunia
o Java

Session Security & Authentication

• Anything passed to client is readable
o Hidden fields and cookies aren’t hidden
o Use Webscarabor other proxy to analyze
• Encrypt info in cookies and hidden fields
o Apply a timestamp to sensitive variables
o Use strong sessionIDs>16 chars

Javascriptand XSS are Serious Threats

• Javascriptis compatible across major browsers
o It’s a powerful language
o Exploits will probably become more insidious
• XSS Vulnerabilities are plentiful

In scripts, only allow valid data; if that breaks, filter out bad stuff.

o White list then blacklist

Comments Off on Web Server Security – Suggestions

Network categories of System Monitoring

Posted in Compliances (1300),Networking (340) by Guest on the January 5th, 2011

Monitoring System Configuration Changes This category includes monitoring for changes in hardware and software configurations that can be caused by an operating system upgrade, patches applied to the system, changes to kernel parameters, or the installation of a new software application.

The root cause of system problems can often be traced back to an inappropriate hardware or software configuration change. Therefore, it is important to keep accurate records of these changes, because the problem that a change causes may remain latent for a long period before it surfaces. Adding or removing hardware devices typically requires the system to be restarted, so configuration changes can be tracked indirectly (in other words, remote monitoring tools would notice system status changes).

However, software configuration changes, or the installation of a new application, are not tracked in this way, so reporting tools are needed. Also, more systems are becoming capable of adding hardware components online, so hardware configuration tracking is becoming increasingly more important. 

Monitoring System Faults. After ensuring that the configuration is correct, the first thing to monitor is the overall condition of the system.

  • Is the system up?
  • Can you talk to it, ping it, run a command?

If not, a fault may have occurred. Detecting system problems ranges from determining whether the system is up to determining whether it is behaving properly. If the system either isn’t up or is up but not behaving properly, then you must determine which system component or application is having a problem. 

Monitoring System Resource Utilization. For an application to run correctly, it may need certain system resources such as the amount of CPU or I/O bandwidth an application is entitled to use during a time interval. Other examples include the number of open files or sockets, message segments, and system semaphores that an application has. Usually an application (and operating system) has fixed limits for each of these resources, so monitoring their use is important. If they are exhausted, the system may no longer function properly. Another aspect of resource utilization is studying the amount of resources that an application has used. You may not want a given workload to use more than a certain amount of CPU time or fixed amount of disk space. Some resource management tools, such as quota, can help with this. 

Monitoring System Performance. Monitoring the performance of system resources can help to indicate problems with the operation of the system. Bottlenecks in one area usually impact system performance in another area. CPU, memory, and disk I/O bandwidth are the important resources to watch for performance bottlenecks.  establish baselines you should monitor system during typical usage periods. Understanding what is “normal” helps to identify when system resources are scares during  a particular periods (for example “rush hours”). Resource management tools are available that can help you to allocate system resources among applications and users. 

Monitoring System Security. System’s availability can be impacted through unauthorized use. Performance and resource controls are not useful if the system is used for the wrong purposes.  The value of security tools is often overstated but in small doses they can be useful not harmful. for example it is easy to monitor for world writable files and wrong permissions on home directories and key system directories. There no reason not to implement that. In many cases static (configuration settings) security monitoring can be adapted from hardening package such as Titan. 

Monitoring system logs. This is an integral area that overlaps with each and every area described above but still deserve to be treated as a separate. System logs provide a wealth of information about the health of the system, most of which is usually never used as it is buried in the noise and because regular syslog daemon outlived its usefulness. Usually log monitoring is done along with the integration of log stream on the special log server.  Few people understand the flow of messages to central log server represents a decent distributed monitoring system and that instead reinventing the wheel it is possible to enhance it by writing probes which write messages to syslog.


Comments Off on Network categories of System Monitoring
Next Page »