Network Security - Standard Proxies Vs Transparent proxies

Network based security devices provide application firewalls and Virus scanning functionality using proxies. Proxies act as servers for client end points and clients for server end points. They typically terminate the connection (UDP or TCP) from clients and make connections to the original servers. In between they do processing on the data such as access control and scanning and take actions based on the processing results.

Proxies are implemented in two ways - Standard and Transparent. In case of standard proxies, both client and server end points know that there is a proxy in between. Client end points are configured with standard proxy address and server sees the connections from the proxy. That is, destination IP address of the packets from client is proxy IP address and source IP of the packets from proxy to server is proxy IP address. In case of transparent proxies, both client and server end points don't know the existence of the proxy in between. In this mode, both source and destination IPs of the packets correspond to client and server end points. At no time, proxy IP address is seen in the packets on the wire.

Advantages of standard proxies:

• Devices with standard proxies need not be in the line of traffic.
  
• Traffic that need not go through the proxies will not have any latency introduced.
  
• Any problem with security device only effects the proxy traffic and not every thing else.
• Single leg mode: Device only need to have one Ethernet port.
• Standard proxies don't require any special support in TCP/IP stack: In Linux and BSD systems, proxies are typically implemented in user space and they use standard socket library to accept connections, make connections, receive and send data. Since, the packets are destined to local IP address, there is no change required in TCP/IP stack or Linux Kernel for this support. In case of transparent proxies, support is required in Linux kernel to redirect the packets to proxy applications.
  

Advantages of transparent proxies:

• No special configuration required in client end points.
• Servers see traffic from client end points. There is no issue if there is any analysis is required on unique clients connecting to servers from logs as logs indicate original client IP address.
• Any other policy based network devices continue to work as there is no change seen in IP addresses of the packets. Example: Traffic shaping devices doing shaping based on IP addresses.
• It does not have any issues with 'Unknown Domain Resolution' DoS attack. Standard proxies typically get the domain name from the protocol fields and does domain name resolution to get the IP address of server. Attackers can DOS the standard proxy by connecting to proxy with invalid server domain names. If the proxy is implemented to create a thread for each connection, then the proxy can easily be DOSed as these threads block on DNS resolution for a long time. Note that the number of threads that can be created in any given system are limited in number. If the proxy is implemented as FSM (finite state machine) without any blocking calls, then this problem may not arise soon, but the memory can be exhausted due to state maintenance. Transparent proxies don't have this problem as it does not do any domain name resolutions.
  

As indicated above, transparent proxies require special support in Linux/BSD kernels to intercept the packets at the IP layer and redirect them to the proxies. This can be implemented as kernel module. I try to give some brief description on the operations of this module.

• Operation:
• Intercept all packets at the IP layer. In case of Linux, it can be done using 'netfilter' hooks.
• If the packet is first packet of the session, it creates a memory block to store the state information (let us call this as session block). Then it checks whether this packet requires to be redirected to local proxy. If so, it notes down the client IP address (source IP address) and server IP address (destination IP address) in the session block and changes the destination IP of the packets to local IP address. Thereby, rest of the TCP/IP stack sends the packets to the proxy. Note : There are no other changes required in TCP/IP stack.
  
• For further packets, it uses the session state information to redirect the packets.
  
• When proxy makes connection to the server, it uses local IP address which is used as source IP. Since, it is required that server sees original client IP, this module does SNAT on Server to proxy connection. It also creates a session to store any state information.
  
• Proxy interface
• This module can be configured with rules for redirection. Either administrator can configure the rules or proxies themselves can configure the rules. For example, web proxy might configure to redirect all HTTP connections coming from a particular subnet to be redirected to it. It can also configure to redirect HTTP connections going to a particular server (Reverse proxy scenario).
  
• This module provides interface to return original server IP address when proxy requests it. Proxy needs this IP address to make connection to the server end point.
• This module provides interface to link client side session to server side session. It is expected that proxy informs this module before connecting to the server. This module prepares itself by creating server side session and populates the session with state information do to the SNAT.

Direct Download Links/One Click Hosters - Detection by IPS

One click hosting has become very popular in recent past. Unlike P2P protocols such as BitTorrent, one click hosting providers host the entire file (video, audio or data) at one place and provide access to the files using normal browsers using HTTP. Their model is very simple. They let users to upload files. For each uploaded file, users are provided with the 'download link'. Users can put these download links in their website, blogs or forums. When others click on this download link, it takes them to the provider site. Two providers megaupload and rapidshare are very popular one click hosting providers. There are many sites providing this kind of service.

Another kind of sites are video hosting websites such as youtube. These sites allow users to upload videos and view existing videos. Please see this link to see some of video hosting sites. It appears that traditional P2P file sharing popularity is declining with these two kinds of sites.

Network security devices, specifically IPS functionality, have been providing P2P application detection and facility to block these applications or throttle the traffic from these applications, thereby saving precious bandwidth for Enterprise applications' traffic. With One-click-hosting sites and video sharing sites, these controls are becoming less effective. Network security devices need to change with current reality. Due to the usage of HTTP for downloading the video content, it is a challenge for network security devices to detect this traffic. That is where, signature based application detection comes in handy.

As an administrator, you should look for solution that offers:

• Detection of hosting provider with no false positives.
• Detection of hosting provider within first 2K byte of connection.
  
• Ability to set the throttling parameters based on
  
• hosting provider(s).
• machine(s) accessing the hosting site.
• Time of day
  
• Ability to set throttling parameter such as
• Bandwidth (bytes/sec or packets/sec).

IntruPro-IPS from Intoto provides following facilities:

• Signatures to detect hosting providers. Each hosting provider is identified by 'Application ID' using signatures.
• Signatures can be developed with HTTP protocol keywords. Hence detection can happen with zero false positives.
• Traffic Enforcement rules with each rule containing
• Source IP address(es)
• Application ID(s)
• Time of day and Day of week.
• Action : Block Or throttle
  
• Bandwidth in bytes/sec or pkts/sec
• Flag to indicate whether to apply traffic throttling based on each source IP.

PCI DSS - UTM technology requirements

Many security vendors claim that their products can be used to comply with PCI DSS requirements. But, it is difficult to find exactly what is it one should look for in these kinds of products. I try to address this in this blog entry. My focus in this article is on network firewall, IPS, VPN , AntiVirus and web application proxy firewall products.

PCI DSS (Payment Card Industry Data Security Standard) defined 12 requirements. For more information on these requirements, please refer to PCI DSS standards. Those 12 requirements are:

• Requirement 1 - Install and Maintain a firewall configuration to protect cardholder data.
• Requirement2 - Don't use vendor-supplied defaults for system passwords and other security parameters.
• Requirement3 - Protect stored cardholder data
• Requirement4 - Encrypt transmission of cardholder data across open, public networks.
• Requirement 5 - Use and regularly update anti-virus software or programs.
• Requirement 6 - Develop and maintain secure systems and applications.
• Requirement 7 - Restrict strong access to cardholder data by business need-to-know.
• Requirement 8 - Assign a unuqie ID to each person with computer access
• Requirement 9: Restrict physicall access to cardholder data
• Requirement 10: Regularly monitor and test networks
• Requirement 11: Regularly test security systems and processes
• Requirement 12: Maintain an Information Security Policy

Security infrastructure products like firewall, IPS, VPN, Web application firewalls are used to satisfy the PCI DSS requirements.

Expectation from Network based Firewalls:

• Ability to support multiple zones: Cardholder data servers must be separated from the frontend servers such as Web Servers. Thereby, any compromised front server does not give access to cardholder information to attackers. Typically, frontend servers are kept in DMZ of firewall. Cardholder information must be kept in other zones. Firewall should have facility to define new zone and firewall must have facility to setup rules for each zone. All cardholder servers can be kept in the zone separate from 'corporate zone', 'dmz zone' and 'untrusted zone'.
  
• Ability to create access control policy rules: Firewalls must support creation of rules among zones. For example, access to cardholder data servers should only be allowed from 'frontend servers' in 'DMZ' zone. In addition, only specifc ports should be allowed. Firewalls must have capability allowing rule creation with 'From' and 'To' Zones, 'From' and 'To' IP addresses and Service Ports.
• Ability to define rules with named objects: Firewall rules can become pretty complex. For readability and manageability, administrators would like to create rules with named objects (IP address objects and Service Objects).
  
• Ability to generate logs and alerts: Any attempt to card holder data other than the allowed policy rules must be notified. It is also required that firewalls have ability to generate log events for each connection that was allowed. Firewalls should send enough information along with the notification for analysis.
  
• Ability to detect and protect from DOS & DDOS attacks.
• Ability to hide internal IP addresses using NAT capability : Any outbound connection from any zone should hide its internal addresses.
• Factory defaults:
• 5 zones - DMZ for front end servers, PCI for payment systems, CORP for internal users, VISITOR for visitors and MGMT for management traffic.
• ACL rules:
• Allow only DMZ to PCI traffic. Deny PCI to ALL zone traffic.
• Allow only HTTP and HTTS traffic from ANY to DMZ.
• Allow only Enterprise protocol from CORP to ANY and VISITOR to ANY.

Expectation from Network based Intrusion Prevention Systems:

• Ability to protect all services of machines in corporate network, card holder data zone, DMZ zone from attacks exploiting known vulnerabilities: IPS devices are expected to have up-to-date signatures to protect internal resources from exploiting known vulnerabilities.
  
• Ability to differentiate from patched and un-patched services in internal machines: IPS devices are expected to have facility to control generation of logs based on targeted system version.
  
• Ability to detect and stop connections and packets transporting malware to internal network: IPS devices are expected to have up-to-date signatures to detect malware by monitoring the connections and packets.
  
• Ability to detect infected machines in internal zones by monitoring the traffic and connections from the internal machines to other zones: This typically happens if an infected system was brought into the network. IPS devices are expected to detect these machines by monitoring the traffic using up-to-date signatures.
  
• Ability to provide signature additions and editions: Beyond signatures which are auto updated, IPS systems are expected to provide facilities to create custom signature rules. It facilitates the administrator to create rules which are specific to the deployment. Administrator can create rules to detect default passwords of the applications and other characteristics of applications. Also administrator can create rules to detect specific information about cardholders.
  
• Ability to detect protocol anomalies of HTTP.
  
• Ability to detect traffic anomaly: Especially this is required to detect anomaly between frontend servers and cardholder data servers. Administrator can setup normal traffic profile for day and night and check for any anomaly. IPS deviecs are expected to provide this function.
• Ability to detect and prevent from SQL, XSS injections: IPS devices are expected to monitor HTTP POST values, GET values and XML data to detect SQL or XSS injections and check for any blind SQL and XSS injections using its up-to-date signatures.
• Ability to generate logs and alerts: IPS devies are expected to generate logs with comprehensive information for administrators to analyze the issue and take corrective actions.

Expectation from IPSec VPN:

• Ability to create Site-to-Site tunnels: Yet times, frontend servers and cardholder data servers may not be in same location. In these cases, it is expected that Ipsec VPN tunnels are used to transport data among these servers to provide data security on wire.
• Ability for Remote Access VPN: Administrators and other privileged users may need to get to the cardholder data servers remotely. IPSec VPN component of security appliance is expected to allow remote access via VPN tunnel.
• Ability to create new key generation periodically ( as small as 5 minutes).
• Ability to create IKE policies without preshared keys. When preshared keys are used, IPsec VPN should check for the strengh of the preshared keys.
• Atleast one digit.
• Atleast one non-alphabet and digit.
• Minimum length of 6 characters.
  
• Ability to support EAP authentication in remote Access VPN cases.
  

Expectation from Network based AntiVirus:

• Ability to scan email/HTTP traffic for virus and stop virus reaching internal machines: Internal machines are eventually used to access cardholder servers. Network based Virus scanning is one way to stop viruses reaching the internal servers and machines. Note that, network based AV can only do limited job. It is required that host based AV software is installed on all endpoints and servers.

Expectation from Web Application Firewalls:

• Ability to look into SSL traffic: All transactions are based on SSL. Any deep inspection requires decoding SSL traffic.
• Ability to provide HTTP protocol anomaly detection
• Ability to detect exploit traffic
• Ability to detect SQL and XSS injections.
• Ability to provide access control for different services running on HTTP.
• Ability to look deep into XML for SQL, XSS, command injections.
  
• Ability to generate log events and alerts.

Since these security devices are part of merchant network, these also must adhere to generic requirements of PCI DSS. They are:

• Configuration management of these devices should only be allowed by privileged users.
• Auditing of configuration changes: If there are multiple administrators, then each administrators must have unique ID. Each change in the configuration must be logged with information such as 'name of user' , ' change made', 'time & date of change' etc..
• Security devices also can be vulnerable. It must have facilities to upgrade new firmware.
• Mandate change of default passwords first time administrators log in, if local user database is used.
• Check for strong passwords, if local database is used.
• 6 Character length.
• Atleast one digit
• Atleast one non-alphanumeric character.
  
• Security devices predominantly should show alert message in their home page of default passwords.
• Mandate the password change if unchanged for a month or as per company policy.
  

Trace Route Diagnostics - TR-069 profile

Tracing the routing path to a given destination machine is very important diagnostic tool for administrators and service providers. TR-098 Amendment 1defined 'IP PING' diagnostics, but did not define trace route diagnostics.

Trace route utility is provided in many operating systems today. Its main purpose is to find out the route IP packets take to reach a specific destination. It gives indication on the routers in between and round trip time of each probe. This utility sends UDP, TCP or ICMP probes with small TTL and listen for ICMP 'time exceeded' reply. It starts with TTL 1 to find out the first hop, TTL 2 to find out the second hop and so on.

Trace route can happen by sending ICMP, UDP or TCP packets. Trace route utility provides this option for traversing through firewalls. When firewalls don't allow ICMP, trace route can be used with UDP or TCP.

Since, a given host given may have multiple outbound interfaces, trace route utility gives facility to use specific link for its source IP address to ensure that responses come back to this IP address. It also provides option of specifying the gateway to route the packets through a specific link of the host.

Trace route utility provides options such as:

• Destination Host IP address or FQDN.
  
• Use ICMP, UDP or TCP.
• Use IPv4 or IPv6
  
• Packet size : Valid in case of ICMP and UDP. Not applicable if TCP is chosen. TCP probe always goes with SYN flag.
• Port: Port number to use for destination port of the UDP or TCP probe. In case of ICMP, it is used as sequence number.
• TOS: TOS value to use in the IP header of probe packet.
  
• Link interface to use: Utility uses IP address of this link as source IP of the probe packet. if not specified, default is to use link determined by route.
• Gateway IP address: This is mainly to select the right link, if there are multiple links on the host. Default is 'based on route'.
  
• Maximum TTL: Indicates the maximum number of hops to discover. Default : 30
  
• Number of Probes: Number of probe messages to each hop. Default 3.
• Wait time: wait time to wait for the response to probe. Default : 5 seconds.
  
• Send interval: Interval between probe messages to a hop: Default 0 seconds.
  

Results of trace route utility can be represented as:

• Destination Host: For which trace route diagnostics was run.
  
• Number of hops.
  
• Sequence of hops. Each hop consisting of
  
• IP address of router: Display * if no response from that hop.
• FQDN of the router: By doing Reverse DNS lookup
  
• Probe1 round trip time in milli seconds.
• Probe2 round trip time in milli seconds.
• Proble3 round trip time in milli seconds.
• Rest of round trip times in comma separated string (upto 32 bytes).

With this TR-069 profile could be as follows:

• internetGatewayDevice.IPTraceRouteDiagnostics P
• diagnosticsState: RW, String, It takes values of "None", "Requested", "Completed", "Error_HostNameResolutionError", "Error_HopCuntExhausted": Similar to PING diagnostics stage.
  
• destination host : RW, String, 256 bytes max, IP address in dotted decimal form or fully qualified domain name.
• probeProtocolSupported: R, String, comma separated strings. "ICMP", "UDP", "TCP", this is the capability of device.
  
• probeProtocol: RW, String, Takes one of values of "ICMP", "UDP" or "ICMP".
  
• IPv4OrIPv6 : RW, String, Values are "IPv4", "IPv6"
• packetSize: RW, Integer, Not applicable in case of TCP.
• Port: RW, Integer, Destination Port to use. In case of ICMP, it is used as sequence number.
• TOS: RW, Integer
• LinkInterface: RW, String, Fully qualified instance from VLAN, LANDevice, WANPPPConnection or WANIPConnection etc.. IP address of this interface is used as source IP of the probe packet.
  
• gatewayIPAddress: RW, String, Dotted decimal form. It is to select the link.
• maximumHops: RW, Integer
• numberOfProbles: RW, Integer, Number of probes to use for each hop.
• responseWaitTime: RW, Integer, in seconds.
• sendInterval RW, Integer, in seconds.
• internetGatewayDevice.IPTraceRouteDiagnostic.response P
• hostName
• status: "Error_UresolvedHost", "Error_MaxHopCountReached", "Success"
  
• numberOfHopEntriesDiscovered: RW, Integer
• hopIPAddress: RW, String
• hopFQDN: RW, String
  
• probe1RTT: RW, Integer in milliseconds.
  
• proble2RTT: RW, Integer
• proble3RTT: RW, Integer
• OtherProbeRTT: RW, string, comma separated. Upto 32 bytes.

Mobiles - Why Document Management System.

See this article on Risk Management techniques.

Some excerpts from this article:

In years of consulting with Wall Street clients, John Pironti, a board member of ITGI (IT Governance Institute) and chief strategist for Getronics (www
.getronics.com), has learned that some of these security-obsessed financial giants lose as many as 10 BlackBerrys per day. A 2005 survey by CheckPoint Software (www.check
point.com) found more than 25,000 PDAs and laptops left in Chicago taxis over a six-month period. Many have unsecured, confidential data that, if in the wrong hands, could have significant adverse ramifications�a third of CheckPoint’s respondents don’t use passwords or any other security protection on their mobile devices.

25000 PDAs and laptops in one city over 6 months is too high a number. It means that confidential data is not so confidential anymore.

As I mentioned in my previous blog entries, one of best ways is a way where the information does not leave Enterprise. That is where I feel that document management systems should come in very useful. It should provide facilities for access, modify existing documents and create new documents. Of course, this facility is to be provided only if the user is privileged to do the operations. Since mobiles are becoming versatile, a good document management system must provide thick java based application on mobiles for accessing document management system in easy-to-use manner. It also need to provide facility to do off-line work on a specific documents if they are allowed to be downloaded. Also, these downloaded documents must be stored locally in mobiles with strong encryption - Either this could be application based or this can be done using encrypted file systems on mobiles.

If I am IT professional, I look for this minimal feature set in document management systems:

• Easy-to-create work spaces.
• User Group management.
  
• Association of Users to User Groups ( Could be done in LDAP or RADIUS Servers)
• Creation of new documents, Modification of existing documents with history maintained.
• Modification only after checkout with lock.
• Releasing lock upon check-in.
  
• Task Management.
• Work flow management.
• Access control
  
• Read permission on work space and document.
• Write permissions on modifying on per item in workspace.
• Create new documents.
• Allow Synchronization with mobiles.
  
• Mobile segment related features:
• Thick Client on Mobiles.
• User authentication (beyond authentication required to unlock the mobile).
• Easy-to-use UI
  
• Both online and offline editing should be possible.
• Synchronization of document data between Mobile application and backend document management system using OMA-DS.
  
• Encrypted storage.

Referencing - ACS responsibility

TR-069 based data models can become complex with referencing. Some examples of references are:

• internetGatewayDevice.Layer2Bridging.Filter.{i}.FilterInterface takes value of 'AvailableInterfaceKey' of table internetGatewayDevice.Layer2Briding.AvailableInterface.{i}
• internetGatewayDevice.Layer2Bridging.Marking.{i}.MarkingInterface takes value of 'AvailableInterfaceKey' of table internetGatewayDevice.Layer2Briding.AvailableInterface.{i}
• internetGatewayDevice.QueueManagement.Classification.{i}.ClassInterface takes one of the values from WANPPPConnection instances, WANIPConnection instances, Ethernet interface instances of LANDevices, USB interface instances of LANDevice, Wireless LAN interfaces instances of LANDevices or VLAN interface instances.
  

ACS implementation considerations:

• Must to have for interoperability:
  
• ACS must send referred instances first before sending referencing instances to the device. That is, if WANPPPConnection instance is referred by QueueManagement.Classification table, then WANPPPConnection instance creation and configuration must happen before Classification table instance is created and configured. Device may fail to accept the configuration if Classification instance is configured before configuring the referred WANPPPConnection. Hence, ACS must keep this ordering in mind while sending configuration to the devices.
• Note: Data model standard developers must never do the bidirectional cross referencing between two tables.
  
• ACS must not allow administrators to remove instances if they are being referred by others. Going by above example, ACS must not allow removal of WANPPPConnection instance if it is being referred by Classification instance. It should allow this operation only if WANPPPConnection instance reference is removed from the classification instance. Yet times, same instance is being referred from multiple places. Unless all the references are removed, it should not allow removal.
  
• Nice to have features
• ACS may display all possible places where a particular instance object is being referenced. For example, all references of WANPPPConnection instance can be displayed to the administrator so that he/she can remove references.
  

Mobile battery power drain attack - What to do about it?

I recently came across this post http://isc.sans.org/diary.html?storyid=4150&rss

ISC SANS article and paper mentioned in the article named Battery-Based Intrusion Detection describes the intrusion detection using batter power usage in mobiles. It appears that there is significant amount of power consumption on packet processing even though there is no application listening on those packets. I guess this is due to reception and transmission on wireless interface and amount of processing that happens in the TCP/IP stack of mobile before the packets are dropped (power consumption by CPU). Mobiles supporting 802.11x wireless interface are more vulnerable to this attack due

Many mobiles are equipped with power management facilities in both mobiles and 802.11 wireless access points. It works as expected as long as there is no unintended packets are sent to the mobile. Attacks can be mounted by sending flood traffic to the IP address assigned to mobiles, there by draining the mobiles.

What are the precautions wireless infrastructure deployment can take:

• Stop any traffic that was not in response to connections that were made by the mobiles.
• Don't allow any unsolicited connections to the mobiles.
• If there is need for TCP/IP connections to the mobiles, ensure that they are allowed only based on user credentials.
  
• Don't allow broadcast packets by default.
  
• Yet times, mobiles may have VPN connection to the Enterprise security gateways. This security gateway should ensure same precautions.

To achieve above, stateful firewall must be either part of wireless access points or wireless switch. In case of VPN tunnels, VPN server also should have stateful firewall. One should ensure that stateful firewalls also support activation of user based policies upon successful authentication.

Microsoft System Center - Mobile Device Management - Missing Security pieces

Microsoft has well written product reference guide. Please see it here.

It is a comprehensive Mobile Device Manager for Enterprises to manage and control mobiles by their own IT department. It differs from other solutions which are controlled by providers.

It is very obvious that Enterprises would allow mobiles to access their networks for many business applications. Enterprises have to be geared up to provide this access without compromising security. Microsoft solution is taking care of data security on the air. It is not sufficient from threat security perspective. A complete mobile solution require network security processing functions in addition to solution provided by MDM.

MDM seems to be providing following functions using different components:

• Mobile Device enrollment : Simple facility to enroll mobile devices into corporate network.
• Mobile Device Management : Managing mobile devices by providing sub functions such as
• Over-the-Air application management
• Upload new applications.
• Configure applications.
• Inventory Reporting.
• Give complete list of devices that are in pre-enrolled stage, enrolled stage, device characteristics, installed applications, Some application settings etc..
• Role based administration
• Distribution of work among IT professionals to handle large number of mobile devices, applications and its functions.
• Self Help Portal
• For employees to view the list of their mobiles _ note that each employee can have more than one mobile and its inventory of applications etc..
  
• Remote Wipe upon loss of mobile.
• Basically, it helps reduce burden on IT professionals.
• Security Management: Basically, it helps IT professionals and Employees to control the settings on the mobile - Such as Cameras, Blue tooth connectivity, Email settings, SMS/MMS messaging etc..
  
• Mobile VPN Gateway
• To provide secure data access to corporate network from mobiles.
• It provides persistent tunnel capability, Roaming capability.

Additional Functions that are required by Enterprises to provide mobile connectivity to their networks are:

• Granular access controls based on type of user and mobile device.
  
• There are many LOB Servers (Microsoft term for Application servers) and network resources. Some may not be accessible by all employees. Having access control on a Enterprise side provides better control for security professionals.
• If the mobile device is stolen, any traffic coming from that mobile device must be stopped. Again, having control at the Enterprise level provides this capability.
  
• Network traffic scanning for infected mobiles
• Mobiles are now general purpose computers. They also can get infected by attackers as normal laptops. They can create havoc, if these are not detected and stopped immediately. It might infect servers and other network resources. Security professionals would like to have a control on network side to detect and prevent any access upon infection. This kind of security is required even if mobiles have security software installed in them.
• Anti Virus scanning and Anti Spam functions
• These are highly recommended to be on the Network side too.

In summary, mobile deployment by Enterprises must consider network security functions as part of their overall solution.

Network objects in Security infrastructure products

Security policies are complicated. It consists of many rules. Rules typically contain IP address and Service information along with other information related to particular security function. Some security products only support creation of rules with immediate values for IP addresses and services. Thought it is not a problem during creation of rules, it could be a maintenance headache when it comes to modifications due to network changes. Also, it is difficult for new administrators to understand the rules. Good security products support creation of network objects and associate them to the rules. Admins need to modify only network objects if there is any change in the network. Since network objects are named, rules are readable and easy to debug and fix any problems.

Typical network objects are IP address objects and Service Objects.

IP Objects:
IP address objects name the hosts, subnets, range of hosts. For example, all networks in Engineering department can be grouped into one object. Each server can be represented by separate object with descriptive names.

Service Objects name different kinds of services. For example TCP port 80 can be named as 'http' service object.

IMO, IP object definition should take any type of IP address(es) - Subnet, Range, Single IP address, FQDN. It should also take multiple of these in one record. With this in mind, IP object definition can be represented as

• Virtual Instance ID ( See http://srini-addepalli.blogspot.com/2008/03/virtualization-and-zones-in-secuirty.html )
  
• Object name
• Object Description
• IP address Type - Whether this definition for single IP address, IP address range or Subnet
• Multiple IP definitions. With each definition having
• IP address ( if type is single IP address)
• IP address begin (if type is IP address range)
• IP address end (if type is IP address range)
• Network (If IP address is Subnet)
• network mask (If IP address is Subnet)

IPsec policy records when implemented with IKEv1 can't have FQDN as part of selectors. Due to this, IP address objects having FQDN can't be used to represent selectors. Many security software implementations have speciall IP address objects which take only FQDN. These type of IP address objects have following parameters:

• Virtual Instance ID
  
• Name
• Description
• Multiple IP definitions. With each definition having
• FQDN

First kind of IP objects are called IPValueObjects and second kind of IP objects are called IPFQDNObjects.

Service Objects
Service objects represent services. Each Service objects contains following attributes.

• Virtual Instance ID (See http://srini-addepalli.blogspot.com/2008/03/virtualization-and-zones-in-secuirty.html )
  
• Name
• Description
• Multiple definitions of Ports. Each definition having
• Protocol Begin (It takes values of protocol values such as UDP, TCP etc..)
  
• Protocol End
• Port Range Valid (YES or NO) : This is Not Applicable if Protocol range does not have either TCP or UDP)
  
• Port Begin (If TCP or UDP is present in protocol range)
  
• Port End (If TCP or UDP is present in protocol range).
• ICMP type Valid (YES or NO): This is not applicable if protocol range does not have ICMP.
  
• ICMP type begin
• ICMP type end
  
• ICMP Code Begin
  
• ICMP Code End

In addition to objects created by administrators, there could be objects that are created by other applications in the system. These objects are dynamic and can't be deleted by administrators. It is good to show them in UI though.

Based on above explanation, I tried to give possible TR-069 data model:

• internetGatewayDevice.security.VirtualInstance.{i}.NetworkObjects P
• internetGatewayDevice.security.VirtualInstance.{i}.NetworkObjects.IPValueObject.{i} PC
• ObjectName : RW, String of 32 characters. Once the object is created, this can't be changed.
• Enable : 1 - Yes 0 - No
  
• Description: RW, string of 64 characters.
• IPAddressType: RW, Integer Value (Takes values 0 - single IP, 1 - IP address range, 2 - IP subnet )
  
• internetGatewayDevice.security.VirtualInstance.{i} .NetworkObjects.IPValueObject.{i}.IPdefinition.{i} PC
• SingleIPValue: RW, String, IP address in dotted decimal. Applicable only if IPAddressType value is 0.
  
• IPRangeMinValue, IPRangeMaxValue: RW, String. Values are IP addresses in dotted decimal. Applicable only if IPAddressType is 1.
• IPSubnet, IPSubnetMask : RW, string. Values are IP addresses in dotted decimal. Applicable only if IPAddressType is 2.
• internetGatewayDevice.security.VirtualInstance.{i}.NetworkObjects.DynIPValueObject.{i} P
• ObjectName : Read Only, String of 32 characters.
• Enable : 1 - Yes 0 - No Read Only
  
• Description: Read Only, string of 64 characters.
• IPAddressType: Read Only, Integer Value (Takes values 0 - single IP, 1 - IP address range, 2 - IP subnet )
  
• internetGatewayDevice.security.VirtualInstance.{i} .NetworkObjects.DynIPValueObject.{i}.IPdefinition.{i} P
• SingleIPValue: Read Only, String, IP address in dotted decimal. Applicable only if IPAddressType value is 0.
  
• IPRangeMinValue, IPRangeMaxValue: Read Only, String. Values are IP addresses in dotted decimal. Applicable only if IPAddressType is 1.
• IPSubnet, IPSubnetMask : Read Only, string. Values are IP addresses in dotted decimal. Applicable only if IPAddressType is 2.
• internetGatewayDevice.security.VirtualInstance.{i} .NetworkObjects.IPFQDNObject.{i} PC
• ObjectName : RW, String of 32 characters. Once the object is created, this can't be changed.
• Enable : 1- Yes 0 - No
  
• Description: RW, string of 64 characters.
• internetGatewayDevice.securityDomains.VirtualInstance.{i} .NetworkObjects.IPFQDNObject.{i}.IPdefinition.{i} PC
• IPFQDN: RW, string of max size 256.
• internetGatewayDevice.security.VirtualInstance.{i} .NetworkObjects.DynIPFQDNObject.{i} P
• ObjectName : Read Only, String of 32 characters.
  
• Enable : 1- Yes 0 - No Read Only
  
• Description: Read Only, string of 64 characters.
• internetGatewayDevice.security.VirtualInstance.{i} .NetworkObjects.DynIPFQDNObject.{i}.IPdefinition.{i} P
• IPFQDN: Read Only, string of max size 256.
• internetGatewayDevice.security.VirtualInstance.{i}.NetworkObjects.ServiceObject.{i} PC
• ObjectName : RW, String (32 bytes). Can't be changed once the object is created with a value.
  
• ObjectDescription: RW, String (64bytes)
• Enable 1 - Yes 0 - No
  
• internetGatewayDevice.security.VirtualInstance.{i} .NetworkObjects.ServiceObject.{i}.definition.{i}
• ProtocolRangeMin: RW, Integer (0-255).
  
• ProtocolRangeMax: RW, Integer (0-255)
• PortRangeValid: 1 - Yes 0 - No Also this is applicable only if TCP or UDP is present in the protocol range.
• PortRangeMin: RW, Integer (0-65535)
  
• PortRangeMax: RW, Integer (0-65535)
• ICMPRangeValid: 1 - yes 0 - No. Also this field is applicable only if protocol range has ICMP.
• ICMPTypeRangeMin: RW, Integer (0-255)
• ICMPTypeRangeMax: RW, Integer (0-255)
• ICMPCodeRangeMin: RW, Integer (0-255)
• ICMPCodeRangeMax: RW, Integer (0-255)
• internetGatewayDevice.security.VirtualInstance.{i}.NetworkObjects.DynServiceObject.{i} P
• ObjectName : Read Only, String (32 bytes).
  
• ObjectDescription: Read Only, String (64 bytes)
• Enable 1 - Yes 0 - No Read Only
  
• internetGatewayDevice.security.VirtualInstance.{i} .NetworkObjects.DynServiceObject.{i}.definition.{i}
• ProtocolRangeMin: Read Only, Integer (0-255).
  
• ProtocolRangeMax: Read Only, Integer (0-255)
• PortRangeValid: 1 - Yes 0 - No Also this is applicable only if TCP or UDP is present in the protocol range. Read Only
  
• PortRangeMin: Read Only, Integer (0-65535)
  
• PortRangeMax: Read Only, Integer (0-65535)
• ICMPRangeValid: 1 - yes 0 - No. Read Only. Also this field is applicable only if protocol range has ICMP.
• ICMPTypeRangeMin: Read Only, Integer (0-255)
• ICMPTypeRangeMax: Read Only, Integer (0-255)
• ICMPCodeRangeMin: Read Only, Integer (0-255)
• ICMPCodeRangeMax: Read Only, Integer (0-255)

Virtualization and Zones in Secuirty Appliances - A brief

I see this question being asked frequently. There is confusion between virtual instance Versus security zone. This is my small attempt to give some brief on virtualization in security appliances. It is not meant to describe this feature in detail :-).

For a brief on Security Zones, please see this entry:
http://srini-addepalli.blogspot.com/2008/02/mutliple-security-zones-in-enterprise.html

Virtual Instances:
Newer Security appliances have this feature whereby one single hardware box supports multiple security instances. They are called virtual instances. Each virtual instance has its own configuration of security functions. Some security vendors call these instances as VSGs (Virtual Security Gateways). Note that, the term Virtual is not same as the terms used by Vmware and Xen. Each virtual instance has its own security zones, firewall policy configuration, IPsec SPD, IPS configuration and so on. For all practical purposes, you can assume that multiple traditional security appliances are kept in one single box with common user interface.

As you understand by now, security zones are part of each virtual instance.

Link layer Interfaces (Ethernet, Wireless etc..):
Each virtual instance has its own interfaces. A given interface can't be part of two virtual instances. Again, imagine multiple traditional physical security appliances. Each traditional appliance has its own Ethernet ports and wireless ports. Similarly, each virtual instances has its own interfaces. If the security appliance is supporting, say 16 virtual instances with each instance supporting 4 security zones, you require 16*4 = 64 link interfaces. This number goes up very high if more virtual instances or more security zones are required. To reduce the hardware cost of adding these many physical ports, vendors support VLAN based interfaces for virtual instances. 4K VLAN interfaces can be created on each physical port. Virtual instances (VSGs) can make use of VLAN interfaces to provide virtualization with less number of physical ports. In some cases, it is not possible to have VLAN ID to map to virtual instance. One example of this type is 'packets coming from Internet' in data center environment. In these case, virtual instance needs to be identified by the destination IP address of the packet. In these cases, the IP address in 'destination IP address feild' of IP header is used to identify interfaces.

Link interfaces are assigned to each Virtual instance and Security Zone. Interface on which packets are being received is used to determine the virtual instance and security zone.

Virtual Security Gateway feature, in my view, is mainly useful for service providers and data centers who want provide security services for business customers. Each customer is treated as one VSG. With one security appliance, SPs can provide security services for many customers, thereby reducing cost dramatically.

With this background, let me describe the relation between VLAN, VSG and Security Zones by taking an example. Let us assume that a 'data center' is hosting services for 64 customers. Data center provider wants to deploy Firewall/IPS appliances to protect servers of these 64 customers. Let us also assume that the appliance has two physical ports. One physical port is connected 'Server' network (Call it as 'Server Port) and another port is connected to untrusted network (Internet Port). With this scenario Admin of this box need to do following:

• Install 64 port switch - Connect Uplink port to security appliance's Server port.
  
• Configure the switch to add VLAN ID 1 to VLAN 64 to packets coming from 64 ports and redirect them to uplink port (VLAN switching).
  
• Configure VLAN module of appliance to create 64 interfaces on VLANA1 to VLANA64.
• Install another 64 port swtich - Connect Uplink port to security appliance's Internet Port.
• Create VLANB1 to VLANB64
  
• For all 64 customers
• Associate VLANAx to 'Server Zone' and VSGx
• Associate VLANBx to 'Internet Zone' and VSGx
• Add security service configuration for each Virtual instance.
• That is all is required I guess.

What it the configuration support required for this?

• VLAN Interface configuration. I covered this in before as part of this.
• Virtual instance administration
• It is set of records and each record having
• Virtual InstanceID.
  
• Virtual Instance name.
• Enable/Disable
• Description
• Zone Description
• Zone ID
• Zone name
• Interface mapping
• Set of records. Each record having
• Interface name(Could be VLAN interface name, bridge interface name or WAN interface name etc.. )
• VSG ID
• Zone ID

Enterprise security appliances typically don't need to support virtualization and hence it can be considered to have one virtual instance.

With above back ground, I feel that TR-069 model may look like this:

• internetGatewayDevice.security P
• maxZonesPerVirtualInstance (Read Only)
• maxVirtualInstances (Read Only)
• currentNumberOfVirtualInstances
  
• internetGatewayDevice.securityDomains.VirtualInstance.{i} PC
• ID
• Enable
  
• Name
• Description
• internetGatewayDevice.security.VirtualInstance.{i}.Zone.{i} P
  
• Zone ID
  
• ZoneName
• internetGatewayDevice.mapping.{i} PC
• InterfaceReference (Fully Qualified instance from VLAN table, LANDevice and WAN Link).
• VirtualInstanceID
• ZoneID

IPS Signature development - Tips

IPS/IDS signature development is a complicated process. You don't have information at one place to gather and analyze before developing a signatures for detecting intrusion attempts. Challenges are:

• Non availability of right information at one place.
• Getting exploit scripts is not easy.
  
• Not having access to vulnerable application to verify the signature.

Some of the sites which I used to visit and guidelines I followed while developing signatures for IDS/IPS subsystems:

• Subscribe for Vulnerability notifications
• Many organizations provide this information such as CERT.
• Knowing more technical information about vulnerability information
• Check for exploit scripts
  
• visit sites such as milw0rm and secwatch
  
• Check vulnerability database in securityfocus
  
• Monitor mailing lists such as bugtraq and full-disclosure
• Monitor bleeding threats signatures for snort. ( I think now it is called as Emerging threats)
• Yet times, you may need to glee information from several resources.
  
• Yet times, assembly analysis of vulnerable code is needed to write signatures which produces less falses.
  
• Another very valuable source I find is SANS daily blog.
  
• If exploit is available, understand the vulnerability by going through the code
• Develop signature targeting the vulnerability.
• For XSS injection attacks, I used to monitor sites such as
• XSSDB at gnucitizen.org
• XSS Cheat sheet at http://www.gnucitizen.org/xssdb/
• XSS incident database.
• SQL Injection attacks: I used monitor following sites for changes
  
• SQL injection cheat sheet
• SQL injection incident database at web application security consortium.
• For P2P/IM application detection:
• Run the application, capture traffic and figure out the pattern.
• If application is available in source code from in public domain, try understanding the protocol at some details and figure out the patterns.
• Using above, develop signatures.
• Understand the protocol.
• You need to have complete understanding of IPS device capabilities with respect to rule language.
  
• Ofcourse, you need to understand vulnerability based on above information.
• You need to have good understanding of regular expressions.
  
• Testing signatures:
• Note that it is not possible to have all kinds of application packages for any IPS vendor to test the signatures.
  
• If exploit is available, develop simulation script and ensure that IPS/IDS between detects and stops the attack.
• If exploit is not available, develop simulation scripts based on information available and test the signatures.
  
• Use third party penetration tools to verify signature quality periodically.
  

As such there is no fixed methodology, but hopefully above guidelines are useful to jump start yourself.

IPS - Linux User space, Kernel space - Where should it run?

Just a thought...

Advantages of user space:

• Easier to debug : Advantageous to developers. Note that IPS is quite complex.
  
• Faster to develop new functionalities.
• No limitation on stack size. Stack size grows with its usage.
  
• Many debugging tools available for user space applications.
  
• Swap memory can be used - So, almost all memory in the system can be used. In case of kernel space, only limited amount of memory can be used.
• Many libraries available.
  
• Upon any crash due to software, faster to bring up.

Advantages of kernel space:

• Faster packet processing :
  
• No threading overhead.
• Save on buffer copy overhead.
• Straight access to TCP/IP stack functions such as routing functions and bridging functions.
  
• No or very minimal jitter when run in softirq/tasklet context. - Very useful for VOIP traffic.
• Real time characteristics of the traffic can be maintained.
  
• Physical memory access.
• Easily portable to Real time operating systems as not much of OS capabilities are used - Advantage for vendors who need to have flexibility of operating systems.

As a developer, I prefer doing this in user space entirely. But kernel space provides its advantages, mainly on performance and low jitter. IMO, combination of user space and kernel space is needed. If it onlyL4 inspection is required for a session, then it is better handled completely in kernel space. If protocol inspection beyond L4 is required such as SIP and HTTP protocol analysis, then it is better done in user space. I prefer this kind of hybrid approach.