What Is a VPN?

Basically, a VPN is nothing more than a secure path through a shared network or WAN that connects two computers, or two networks, so that from the point of view of each endpoint of the connection, they are on the same network. The connection is private because some means have been taken to secure the payload information of the data carried through this virtual tunnel.

A VPN can be a good solution for security issues in many scenarios:

• Employees who work from home and use the Internet to communicate with the company network
• Mobile employees who travel and can dial in to the Internet using a national ISP
• Branch offices using the Internet

Business partners, customers, or even technical support staff who need access As this list demonstrates, two basic types of VPNs are used:

• Remote access VPN—A connection between a remote computer and the Internet.
• Site-to-site VPN—A connection between two networks, which usually is done between two routers, or in some cases firewall/router combinations.

The Mobile Workforce

Many people are on the move in the business world today, and many companies are allowing some employees to work from home. A technique still used today, but which is declining, is to set up a bank of modems and give dial-in access to certain people, such as salesmen, who are always on the move. For a business that needs data connections to branch offices but can't justify the cost of leased lines, modem banks provide the necessary remote connection. You can host a bank of modems under many different operating systems, from Unix (with its efficient kernel and support for large numbers of serial devices) to Windows 2000/2003 (using the remote access service [RAS]). You even can install servers that are basically appliances that act as a front end to provide a bank of modems for dial-in services.

However, maintaining a bank of modems can be expensive because each modem needs a telephone line, which is an ongoing cost. There are several security issues to be considered. For example, what happens if someone discovers the telephone number of your dial-up access? It would then be easy to use a password dictionary attack to break into the network.

However, sometimes a simple dial-in modem is not the best solution. With Internet access available almost anywhere in the United States, Europe, Japan, and many other countries, the Internet can be a good solution to this problem. You can use a single, high-bandwidth connection (buy what you need) to allow multiple home workers, traveling salesmen, and other mobile workers to connect to your network just as if they were sitting at a desk at the office.

The only problem with this access method is the fact that the Internet is not exactly the most secure place in the world. As a matter of fact, just connecting your company's network to the Internet is a serious task that should be accompanied by careful consideration of how you will control that connection (such as using a good firewall strategy), and how you will segment portions of your network to make sure that intrusions or other security breaches can be minimized.

Note

This uses the Internet as the example of a WAN because it's the most common method used today for connecting to remote sites inexpensively. However, VPN technology can be used across any shared or corporate network. You still can have a bank of modems and let users dial up your local RAS and create a connection through your network.

In a typical LAN (local area network) setting, computers, servers, and other resources are connected using switches (or hubs in older networks that have not yet upgraded to newer hardware). Routers are used to connect LANs so that a logical addressing scheme can be used. The problem with security is that when the IP protocol is used, for example, the payload section of the IP packet carries some higher-level protocol message without any way of encrypting the data. If you can intercept the IP packet, you can easily determine which protocol is being used and get to the information very quickly.

As you can guess, VPNs are made up of two basic components: a tunnel, which is a virtual path through a WAN, and some form of encryption to render the contents of the payload (and possibly the header information of the upper-level protocol) unusable if intercepted.

Responding to Intrusions

Garfinkel and Spafford (1996) recommend two important responses. First, remain calm and don't panic. Psychological research shows that humans do not perform well under stressful conditions, unless the task is one that the human already executes exceptionally well. Professional athletes often perform well under stressful conditions because they already are very good at running, kicking, shooting, or blocking. Chances are the same cannot be said of incident response teams. Thus, it's important to remain focused on the facts and carry out the plan you've already practiced a number of times. The next recommendation is to document everything. There isn't much elaboration on this point. Just do it.

A different set of suggestions is found in Chapman and Zwicky (1995):

1st step: Evaluate the situation and decide what response is required. You do this evaluation by accurately assessing the damage. Ask what the intruder is doing now, how far did the penetration get, what information was compromised, what changes were made to the systems, were back doors left, and other questions that describe the current state of the problem.

2nd step: Disconnect or shut down resources if necessary. As a rule, you do not want to let the hacker continue to work through your systems (see the next section). Responding to an incident is much like disaster recovery. If the compromised system is your public Web server, and you do not have a second site, shutdown may not be an option. At least you should be able to reset or kill the network connection. The hacker may try another network connection later, but you will have eliminated the current threat. Think of it as triage.

3rd step: Analyze and respond to the incident. Here, the importance of teams with designated roles becomes apparent. You cannot have the same team member digging through log files or source code and also worrying about the next weaknesses the attacker will exploit. Part of the team should be responsible for analyzing the problem, and another segment of the team should be attentive to any new incoming threats. When you are ready to repair the problem, thoroughly consider your responses. The last thing you want to do is make the situation worse. Disabling the wrong sub- net addresses in your firewall could limit your ability to detect new intrusions while not affecting the hacker at all. That's why it's important to remain calm and think through your steps carefully. On most systems, you'll be working with superuser or Administrator privileges. Have someone look over your shoulder and verbally state each step before you do it to minimize errors.

4th step: Alert other people according to your response policy. You can do this in parallel with the previous steps if your team is large enough. The incident response document you prepared in advance will contain the names, phone numbers, e-mail addresses, pager numbers, and other critical information for the contacts. If you diagnose a problem in a purchased product, contact the vendor's response team as soon as possible. They already may be working on the problem but have not publicized the issue yet for fear of increasing the number of attacks. Do not leek information outside the response team and those with a need to know. Most crimes involve internal collusion, so your team should not involve other internal employees unless you are sure they were not involved.

5th step: Save the system state. Back up as much of the system as you can in real time. Take the backup to a victim machine on a detached network and restore the image. This machine is where you will do your debugging. Keep in mind any privacy issues with data that may appear on the backup. Medical records and credit card numbers should not be forwarded to vendors for debugging unless adequate controls are in place. Know your legal limits in advance.

6th step: Restore hacked systems. If you have detected that system binaries have changed, restore them from certified original product media. To be safe, you should restore the system from scratch. Note that this restoration can be tricky because a system may have many additional products installed and configured on top of it. Getting the system back into the state before compromise may not be a simple task and could introduce other security problems. If you've kept accurate change logs, and your IDS can tell you exactly what has changed, you can get by with replacing only the programs patched by the hacker. Remove any hidden files or directories added by the hacker. Watch out for symbolic links. You don't want to remove a system file that has a symlink from a file planted by a hacker.

7th step: Document what happened. Communicate the incident as necessary. Carry out a defect prevention process that will ensure that the problem does not occur again. Finally, increase monitoring if necessary. For example, if the incident went undetected for several weeks, you definitely were not monitoring the appropriate activities.

In responding to an event, you immediately will be faced with a crucial decision—how to handle the intruder. You have several options. The best advice is to disconnect or kill the network connection. If the event is an internal misuse that was flagged by an IDS, you have different legal options. Upper management will help you decide whether to allow the misuse to continue for gathering evidence (with the appropriate concern for privacy of any compromised information).

Stories of administrators contacting the intruder are plentiful. In some cases, the intruder was a friendly hacker who offered security advice and described the weaknesses ₇ exploited. Because you never know whether you have a curious hacker or a sociopath on the end of the connection, this type of contact can be risky. The intruder might not know what type of evidence could be left behind, and your open acknowledgment of detection could result in a hasty exit that also erases your entire system.

Using Output Parameters with a Stored Procedure

One of the ways that you can use a stored procedure is to have it return data through output parameters. Then after the call to the stored procedure you can display the values returned to you. For example, you might use a stored procedure to return summary information about a table. This could be done through output parameters. The technique presented in this section of the chapter shows you how to use output parameters.


USE IT A Command object contains a collection of Parameter objects. These parameters are values that the stored procedure passes back to you after the call is complete. This ASP.NET page calls a stored procedure that returns values. The values returned are the total number of records in the Employees table and the name of the employee who is paid the most.

The stored procedure has this definition:

CREATE PROCEDURE Tablelnfo
@RecordCount integer OUTPUT,
@TopSalaryName varchar(100) OUTPUT
AS
Select @RecordCount = Count(EmpID) From Employees Select @TopSalaryName = LastName + ' + FirstName
From Employees Where Salary = (Select Max(Salary) From Employees)
Totice that the two parameters are declared as output parameters. In the first query, one of the put parameters is set to the record count. In the second query the other parameter is set to the name he employee who is paid the most.

That stored procedure is called when the ASP.NET page loads:

Sub Page_Load(ByVal Sender as Object, ByVal E as EventArgs)
[n that procedure you will need a Connection object:
Dim DBConn as SQLConnection that points to the SQL Server database:
DBConn = New SQLConnection("server=localhost;" _
& "Initial Catalog=TT;"
& "User Id=sa;"
& "Password=yourpassword;")
You will need a Command object: Dim DBSP As New SQLCommand

You also will need two Parameter objects. The first has its name match the first parameter in the stored procedure and is of the same data type:

Dim parRecordCount as New _ SqlParameter("@RecordCount", SqlDbT e.Int)

The second parameter is set to the name and type of the second output parameter in the stored procedure:

Dim parTopSalaryName as New _ SqlParameter("@TopSalaryName", SqlDbType.VarChar, 100)

Both parameters are set to output parameters using the Direction property:

parRecordCount.Direction = ParameterDirection.Output parTopSalaryName.Direction = ParameterDirection.Output

Next, those parameters are added to the Parameters collection of the Command object:

DBSP.Parameters.Add(parRecordCount) DBSP.Parameters.Add(parTopSalaryName)

The CommandText property of the Command object is set to the name of the stored procedure: DBSP.CommandText = "TableInfo" and the command type is set to stored procedure: DBSP.CommandType = CommandType.StoredProcedure

The Command object will connect to the database through the Connection object:

DBSP.Connection = DBConn DBSP.Connection.Open
The stored procedure can then be executed: DBSP.ExecuteNonQuery()

After the call to the stored procedure you can use the values in the output parameters through the Value property:

lblMessage.Text = "Total Employees: "
& parRecordCount.Value _
& "

Highest Paid: "
& parTopSalaryName.Value
Visitors would then see through the Label control the total number of employees and the highest salary amount.

Updating SQL Server Data

Another type of query that you will often need to run on your ASP.NET pages that include database connectivity are Update queries. Update queries allow you to modify existing records in an SQL Server database table. This technique shows you how to run an Update query from your ASP.NET code.

The page presented with this technique allows the visitor to give all the employees in the Employees table a raise. The visitor enters the factor for the raise and every employee has their salary increased by that factor.

Defined on the ASP.NET page is this TextBox control for entering the raise amount:

<asp:textbox id="txtRaise" runat="Server"/>

Also a Button control is defined:

<asp:button id="butOK" text=" OK " onclick="SubmitBtn_Click" runat="server" />

When that Button control is clicked this code block fires:

Sub SubmitBtn_Click(Sender As Object, E As EventArgs)

Within that procedure, you will need a Connection object and a Command object:

Dim DBConn as SQLConnection Dim DBUpdate As New SQLCommand

You start by connecting to your SQL Server database:

DBConn = New SQLConnection("server=localhost;" _
& "Initial Catalog=TT;"
& "User Id=sa;" _
& "Password=yourpassword;")

Next, you place the text of the Update query into the CommandText property of the Command object:

DBUpdate.CommandText = "Update Employees Set " _
& "Salary = Salary * " & txtRaise.Text

The Command object will connect to the database through the Connection object:

DBUpdate.Connection = DBConn DBUpdate.Connection.Open

The Update query can then be executed:

DBUpdate.ExecuteNonQuery()

Adding SQL Server Data, ASP.net

When your ASP.NET application includes SQL Server database connectivity, you often will need to add records to the database through your ASP.NET pages. For example, you may track visitors as they visit your site. With each page they visit, you may want to add a hit record to your database. Or you may allow visitors to sign themselves up for a mailing list. In that case you would need to add their information to a database. This technique shows you how to add a record to an SQL Server database table.

The ASP.NET page presented with this technique allows visitors to add an employee record to the SQL Server database. Visitors enter information into the provided TextBox controls and click the Button control to add the new record to the database.

Defined on the page are TextBox controls like this one used to enter the new information through:

<asp:textbox
id="txtLastName" runat="Server"

This Button control allows visitors to submit their request:

<asp:button
id="butOK"
text=" OK "
onclick="SubmitEtn_Click" runat="server"
/>

When that button is clicked, this procedure fires:

Sub SubmitBtn_Click(Sender As Object, E As EventArgs) To add a record, you will need a Connection object:

Dim DBConn as SQLConnection

and a Command object:

Dim DBAdd As New SQLCommand

The Connection object connects to the SQL Server database:

DBConn = New SQLConnection("server=localhost;" _
& "Initial Catalog=TT;" _
& "User Id=sa;" _
& "Password=yourpassword;")

Next, you place into the CommandText property of the Command object the SQL Insert statement that adds the new record:

DBAdd.CommandText = "Insert Into Employees (" _
& "LastName, FirstName, BirthDate, Salary, " _
& "EmailAddress) values (" _
& "'" & Replace(txtLastName.Text, "'", """) _
& "', "
* "'" Replace(txtFirstName.Text, "'", """)
&
* "'" Replace(txtBirthDate.Text, "'", """)
&
Replace- (txtSalary.Text, "'", """) & ", " _
& "'" & Replace(txtEmailAddress.Text, "'", """) _
& “.).

The Command object will connect to the database through the Connection object: DBAdd.Connection = DBConn

That connection is opened:

DBAdd.Connection.Open

and the record is added to the database:

DBAdd.ExecuteNonQuery()