Monday, September 29, 2008
1) Use a blocking (synchronous) socket. In this mode, the program will not resume execution until the socket operation has completed. Blocking sockets in 16-bit application will allow it to be re-entered at a different point, and 32-bit applications will stop responding to user actions. This can lead to complex interactions (and difficult debugging) if there are multiple active controls in use by the application.
2)Use a non-blocking (asynchronous) socket, which allows your application to respond to events. For example, when the remote system writes data to the socket, a Read event is generated for the control. Your application can respond by reading the data from the socket, and perhaps send some data back, depending on the context of the data received.
3)Use a combination of blocking and non-blocking socket operations. The ability to switch between blocking and non-blocking modes "on the fly" provides a powerful and convenient way to perform socket operations. Note that the warning regarding blocking sockets also applies here.
If you decide to use non-blocking sockets in your application, it’s important to keep in mind that you must check the return value from every read and write operation, since it is possible that you may not be able to send or receive all of the specified data. Frequently, developers encounter problems when they write a program that assumes a given number of bytes can always be written to, or read from, the socket. In many cases, the program works as expected when developed and tested on a local area network, but fails unpredictably when the program is released to a user that has a slower network connection (such as a serial dial-up connection to the Internet). By always checking the return values of these operations, you insure that your program will work correctly, regardless of the speed or configuration of the network.
Sunday, September 28, 2008
Friday, September 19, 2008
Creating a Network Test Plan
To prepare a plan to test the network. The plan defines the scope, approach, criteria, schedule, responsibilities, resources, and procedures.
Define the objectives of the test by identifying the areas of the network to be tested including:
Â· Volume Testing. Ensures that the network operates smoothly when subjected to production volumes of data over long periods of time.
Â· Stress Testing. Ensures that the network operates smoothly when subjected to the maximum load expected in production, all at one time. A good rule of thumb is to subject the network to 25 percent more data and processing than is expected during peak loads.
Â· Recovery Testing. Ensures that backup and recovery procedures are working properly.
Â· Security Testing. Verifies that the network meets the security requirements.
Â· Performance Testing. Verifies that performance criteria are met (e.g., response times).
Define Acceptance Criteria
For each test objective, define the criteria for successful completion. For example:
Â· All expected results are achieved on the initial run.
Â· All severe, and high priority faults are corrected and the associated test(s) rerun successfully.
Â· A documented plan is put in place specifying how and when outstanding low and medium priority faults will be resolved.
Identify the high-level activities and tasks together with expected start and completion dates.
Identify the individuals who will be involved in the test and their roles and responsibilities.
Identify the staff, hardware, and software requirements. Confirm that the Network Deployment Plan has accounted for these requirements and resolve any differences.
Define the procedures to be followed in preparing the test cases, preparing test scripts, preparing the test environment, conducting tests, and verifying test results.
Tips and Hints
Document any assumptions made while preparing the plan.
Plan to use automated test tools wherever possible to significantly reduce the testing effort and duration. Automated test tools can be used to generate and apply an adequate number of transactions to facilitate stress and performance testing.
Saturday, September 6, 2008
PacketFactory Network Security Projects
- dnsa [DNS auditing tool]
- egressor [router config check]
- firewalk [gateway ACL scanner]
- hummingbird [asychronous scanning engine]
- ipgeo [IP geo-targeting lookup tool]
- ISIC [IP stack integrity checker]
- libexploit [generic exploit creation (overflows/format strings) library]
- libnet [network packet assembly/injection library]
- libnids [NIDS E-box library]
- libradiate [802.11b frame assembly/injection library]
- libsf [IP stack fingerprinting library]
- nemesis [command line IP stack]
- ngrep [GNU grep for the network]
- packit [tool to monitor, manipulate, and inject customized IPv4 traffic]
- sentinel [remote promiscuous mode detection tool]
- stephanie [OpeBSD hardening tool]
- zodiac [DNS protocol analyzer]