Security

This research paper describes a telecommunications standard called Signaling System 7 (SS7). This technology defines a signaling system for control and routing of voice calls between telephone switches and switching locations. SS7 uses out-of-band signaling to place and control calls. It replaces an older system of in-band signaling to control telephone equipment. In-band signaling means the audio channel is used as a control channel for telephone switches. Operators would use tones over the audio channel to connect switches and open paths to the call destination. The use of out-of-band signaling means that control of creating an audio path through telephone switches is performed through a separate data channel that connects the switches together. The caller does not have access to this signaling channel, as they do for in-band signaling. SS7 can also carry data to switching locations about the calls they route. This data can include information for purposes of billing network time back to the call’s originating network and the caller’s account. “Signaling System 7 (SS7) is a set of telephony signaling protocols that are used to set up and route a majority of the world’s land line and mobile public switched telephone network (PSTN) telephone calls.” (Ulasien, 2007). SS7 provides more efficiency and reliability for call handling than in-band signaling. SS7 controlled calls can verify that the audio path for a call is ready to initiate, for example, and not create the audio path until the call is answered at the other end. Another example is if the destination phone number returns a busy signal, no audio path needs to be established and the switch directly connected to the caller can generate the busy sound. The strategy of delaying the creation of the audio path until the last moment prevents wasted bandwidth within the switching infrastructure. This scenario would not be possible with in-band signaling, since in-band signaling depends on having an audio path established prior to anyone answering the other end of the call. SS7 allows the creation of innovative customer features and the use of rules-based capabilities for call routing that were previously impossible with in-band signaling technology. Signaling System 7 began development in the 1970s and saw wide deployment beginning in the early 1990s. The technology research and development was sponsored by AT&T and originally named the Common Channel Signaling System (CCSS). AT&T proposed it to the International Telecommunications Union as a standard beginning in 1975. SS7 was issued as a standard in 1980 and has been refined three times since. The ITU Telecommunications Standardization Sector (ITU-TS) develops global SS7 standards. The ITU allows different countries or organizations to make their own refinements and extensions to the global SS7 standard. The American National Standards Institute (ANSI) and Bellcore define a regional SS7 standard for North America and Regional Bell Operating Companies (RBOCs). Before the adoption of Signaling System 7, the only path between telephone switches was the audio channel. Telephone operators would use in-band signaling to set up long distance calls, or route international calls over cable or satellite using touch-tones. Maintenance crews would put telephone switches into special modes using sequences of tones to turn off accounting or allow operations a normal user would not be able to perform. In-band signaling is not just used to control telephone switches. We encounter in-band signaling often through the use of telephone-based services from vendors. Call routing through most of today’s large corporate phone systems require extensive use of the touch-tone keypad. Most voicemail systems require us to enter our personal identification numbers using tones to access messages. Your bank might provide a system to check your balances or transfer money through a phone-based system that uses touch-tones to enter your account information and direct your choices. In-band signaling works well for low-bandwidth situations, such as entering an account code or choosing a menu. Routing instructions to telephone switches can result in a complex series of tones representing access codes and phone numbers. Although it is useful for vendors in providing self-service capabilities to customers, in-band signaling for mission-critical systems such as unprotected telephone switching networks, have been exploited. Exposure of the signaling channel meant that sometimes callers would discover and record the in- band signaling tones used to route calls and control switches. Sometimes the audio signals were discovered completely by accident. During the 1970s and 1980s people such as John Draper (Captain Crunch) were known for their little home-built boxes that could connect to telephone jacks and send sequences of tones to obtain free long distance calls. These were known as black boxes or blue boxes. A whistle that came as a prize in his cereal inspired John Draper’s blue box creation. “The box blasted a 2600-Hz tone after a call had been placed. That emulated the signal the line recognized to mean that it was idle, so it would then wait for routing instructions. The phreaker would put a key pulse (KP) and a start (ST) tone on either end of the number being called; this compromised the routing instructions, and the call could be routed and billed as a toll-free call. Being able to access the special line was the basic equivalent to having root access into Bell Telephone.” (Cross, 2007). Signaling System 7 moves the signaling channel out of the audio channel, and is no longer is accessible to the parties participating in the call. SS7 specifies that telephone switches connect together using a dedicated digital network used only for signaling and managing calls. The signaling network among switches is similar to a traditional computer network. The signaling network can be designed for redundancy and does not need to take the same physical path as the voice data paths. In addition to relocating the signaling channel, the protocol allows for the creation of new and innovative features related to how calls are controlled and routed through the network. The Intelligent Network is a telecommunications industry term and described by Zeichick (1998) as having more reliance on digital technologies, more contextual information about calls in addition to the voice data, and more control provided to the end user for controlling how their telephone experience works. Caller ID works, for example, because the originating caller information is passed from switch to switch through the signaling channels. As mobile phone callers move around, SS7 signaling protocol helps switches find the proper route for calls to this person’s phone. The destination switch for a mobile phone moving in a train or automobile can change quickly. Call routing between switches is optimized with SS7’s definition of shared databases that are accessed through the signaling network. The databases contain rules about how calls should be routed to their destination. Switches on an SS7 network can query shared databases to find out which provider owns a phone number and how to route the call to that number. The databases can also contain feature-specific information. This aspect of the SS7 implementation has been characterized as client-server, meaning the switches act as clients to the shared databases with rules and other information for managing calls. “SS7 links the telephone system with a client-server computer architecture to create a distributed, efficient and easily modified telephone infrastructure. The computers use information from common databases to control call switching and to allow the transfer of messages within the system.” (Krasner, 1997). New technologies are testing the longevity of the Signaling System 7 protocol. Packet switched voice over IP is causing some disruption in SS7 space. However, there is more emphasis on integration and signaling gateways than replacement of existing SS7 infrastructure with something more recent. Session Initiation Protocol (SIP) is a signaling protocol for controlling audio and video connections over Internet Protocol networks. It can be implemented in hardware or software. SIP can be used for voice, video conferencing, and instant messaging and other types of streaming multimedia. H.323 is another streaming multimedia signaling protocol used for audio and video over Internet packet networks. Microsoft’s NetMeeting application uses H.323 as its protocol to connect NetMeeting nodes together in a wide-area conference. H.323 is also a recommendation by the ITU-TS. The business value of SS7 is that it provides opportunities for security, efficiency and optimization of call routing, and it provides the foundation to build innovative features for call handling using contextual information about calls and shared databases. It is a standards-based protocol and has been used throughout the world’s established telecommunications providers for over a decade. The protocol defines the means by which telephone switches exchange call routing and feature information - it does not assume voice data is carried on any particular medium as calls are transferred through the system. This simple abstraction with SS7 allows it to work with new technologies as they arrive in the mainstream. It is possible for SS7 to work within a mixed-technology environment including circuit-switched and packet-switched data networks. Ulasien (2007) says that the extensibility of SS7 allows the incremental migration of an organization from circuit switched to packet switched calls. The voice network is turning into the streaming media network and SS7 will continue to be tested in its role of connection maker and gateway to more recent communication technologies such as VOIP and video conferencing. References Cross, Michael. (2007). Developer’s Guide to Web Application Security. Syngress Publishing 2007. ISBN:9781597490610. Hewett, Jeff. (1996). Signaling System 7: the mystery of instant worldwide telephony is exposed. Electronics Now. 67.n4 (April 1996): 29(7). Krasner, J. L., Hughes, P. & Klapfish, M. (1997). SS7 in transition. Telephony. 233.n14 (October 6, 1997): 54(4). Ulasien, Paul. (2007). Signaling System 7 (SS7) Market Trends. Faulkner Information Services. Document 00011475. July 2007. Zeichick, Alan. (1998). Lesson 125: Signaling System 7. Network Magazine. December 1, 1998: NA. ...

In this article I will discuss my configuration for traffic shaping using m0n0wall. My goals for traffic shaping include giving priority for VOIP traffic leaving my network and limit the combined incoming traffic speed destined for my servers. Some of my assumptions are that you know how to configure your LAN and WAN networks in m0n0wall, you have NAT configured for your outbound LAN network traffic, and you are using the DHCP server for your LAN. The following image shows my LAN network configuration. From m0n0wall The DHCP server for my LAN network is configured to offer addresses from 192.168.85.100-192.168.85.199. I can’t ever imagine having more than 100 clients on my network. I use the addresses below .100 for static assignments on my LAN. My three servers are configured for static addresses on the LAN - they do not use DHCP. In addition to the three servers, the wireless access points are configured for static LAN addresses and the VOIP telephone adapter uses a fixed DHCP LAN address. I use inbound NAT for my Internet services to redirect HTTP, HTTPS and SMTP from the public firewall IP address to the desired server on the LAN. The following image shows the inbound NAT configuration. You will see HTTP and HTTPS are redirected to one server and SMTP is redirected to another server. In addition to these rules, m0n0wall will add rules to the firewall to allow this traffic to pass. From m0n0wall The VOIP telephone adapter uses DHCP by default and I wanted to maintain the provider’s default configuration for the device. My strategy was to determine the network MAC address of the VOIP device and set the m0n0wall DHCP server to always offer the device the same LAN IP address. The following image shows the settings for the m0n0wall DHCP server for the VOIP adapter. From m0n0wall From this configuration, I can now create rules in the traffic shaper to manage inbound and outbound traffic speed based on the LAN IP address. The first task is to define the pipes that will control inbound and outbound traffic. I have two pipes defined - one for all outbound traffic and one for inbound server traffic. I was able to verify my outbound Internet speed at about 1.5 Mbit. I subtracted about 6% from that and came up with 1434 Kbit. I talk about why you should do this in a previous article. The basic idea is that you only want to queue packets in your m0n0wall and prevent packets from queuing in your ISP router or any other device before the packet leaves your location. The only way to be sure is to throttle-down your outbound speed by a few percent. Your connection may need more or less, and you should experiment and re-test your settings once or twice a year. The second pipe is used to limit the maximum speed of incoming data to the servers. I want to limit the combined inbound traffic to all three of the servers to about 1 Mbit. The traffic that would pass through this pipe includes incoming mail delivery and incoming requests to the web server. This pipe will not impact web server responses, i.e. page content returned. Mail delivery between servers on the Internet happens asynchronously, so the client workstations will not care if a message delivery takes 1 second or 15 seconds to occur. Client workstations are interacting with servers on the local network, so they will not feel any of the shaping. From m0n0wall The strategy for outbound traffic is to give top priority for VOIP, second priority to workstations and last priority to outbound server traffic. To accomplish this I need three queues in the m0n0wall traffic shaper section. The three queues relate to the three outbound priorities previously mentioned. The first queue is for VOIP and has a weight of 50. The second queue is for workstation traffic and has a weight of 40. The last queue is for outbound server traffic and has a weight of 10. The total weight for all three queues adds up to 100 and the weights are completely relative. All three queues are connected to the outbound 1434 Kbit pipe. If there is no outbound VOIP and workstation traffic, the server queue with the weight of 10 will get the entire 1434 Kbit outbound pipe. See the following image for the queues. From m0n0wall The reality is that the VOIP traffic only takes about 100 Kbit of the outbound traffic when in use. Even though the weight of the high priority queue is set to 50, it will never use 50% of the 1434 Kbit outbound pipe, and all it does is guarantee that the VOIP service will get all the outbound bandwidth it needs. The final piece of the traffic shaping strategy is the rules that place outbound packets in a specific queue, or place inbound server traffic into the server pipe. Inbound VOIP and workstation traffic does not get shaped. The rules I use are based on traffic leaving a specific interface. Traffic leaving the WAN interface is traffic sent out to the Internet. Traffic leaving the LAN interface is traffic received from the Internet. With that, see the following image. From m0n0wall The first five rules are for outbound traffic destined for the Internet. Rule 1 places outbound VOIP traffic in the queue with weight 50. Rules 2-4 place outbound server traffic in the queue with weight 10. Rule 5 is a catch-all and places all other outbound traffic in the medium priority queue with weight 40. Rules 6-8 are for traffic leaving the LAN interface, in other words, inbound traffic from the Internet. These rules place traffic destined for my three servers into the 1 Mbit inbound pipe. These rules will constrain the combined inbound traffic to these servers to 1 Mbit. Only the inbound server traffic is shaped. With these pipes, queues and rules, I’ve accomplished my goal - VOIP traffic leaves first, workstation traffic leaves second, and server traffic leaves last, and inbound server traffic is limited to 1 Mbit. How can I tell if these rules are working? m0n0wall has a status.php page and you can see the byte and packet counts on these rules. To see these statistics, sign-in to your m0n0wall web console. Add status.php to the browser address. The page you will see is just a textual dump of various internal statistics. The statistic you want to review is the ipfw show listing. The following image shows the statistics for my traffic shaper rules. From m0n0wall In this image you can see the queue and pipe rules with their packet and bytes counts. Take note of the out via dc0 and out via dc1 parts of the rules, which are my WAN and LAN network adapters. The first two rules and very last rule are automatically added by the m0n0wall software. You can see the queue 1 rule for high priority outbound VOIP traffic, coming from a specific LAN address. The next three rules for queue 3 are for low priority outbound server traffic, again based on LAN address. The queue 2 rule is the catch-all rule for outbound workstation traffic at medium priority. The next three rules are for inbound server traffic that is sent to the 1 Mbit pipe. All other inbound traffic is not shaped and matches the last rule. ...

In this article I will discuss the hardware used in my home-brewed firewall and what I did to bootstrap the firewall with the m0n0wall software image. My m0n0wall firewall is based on an older Dell Dimension V400. To get an idea of the machine age, this photo shows the original stickers promoting the Pentium II, Windows NT and Windows 98. From m0n0wall This machine has a 400 MHz processor and 128 MB of RAM. I removed the hard disk and disconnected the floppy drive. The older CD-ROM drive was replaced with a spare Sony CD-RW. The tray on the original CD-ROM started to make grinding noises and stopped opening when the button was pressed. The machine started with one network adapter and I added two more Linksys LNE-100 PCI adapters. You can see all three 100 Mb PCI network adapters in the following photo. From m0n0wall The most educational part of the project for me was the installation of the compact flash IDE adapter and memory card. This device plugs directly into the IDE cable connector on the motherboard and can be used in place of a hard disk. A compact flash device won’t suffer a head crash or any other type of physical damage associated with a moving, mechanical hard disk. I wanted to eliminate the primary causes of a firewall crash, so it was this approach or a pair of mirrored hard disks. The memory card solution was much less expensive and provided me with some experience if I wanted to move to a Soekris or LogicSupply solid-state PC later. I used a compact flash IDE adapter from StarTech, model IDE2CFINT. You can find them for less than $20. I bought mine from Amazon with a 2 GB memory card. StarTech’s site has several good close-up images of the adapter. In the following photo, you can see the compact flash IDE adapter plugged into the PC’s motherboard IDE cable connector. Along the right side of the compact flash IDE adapter is the memory card, which is plugged into a pin header. Above the memory card is a floppy drive power cable. The power for the adapter can come from the motherboard or from a floppy drive power cable. There is a jumper on the adapter to specify the source of power. I set it up initially this way, and it worked, so I left it. From m0n0wall This machine has two IDE channels, the first is used by the compact flash IDE adapter. The second channel is used by the CD-RW drive. You can see in the blurry background of the above photo the CD-RW cable connected to the motherboard’s second IDE channel below the compact flash IDE adapter. The cable comes up to the left of the compact flash IDE adapter and continues up to the CD-RW. The next step was to power up the machine and see what the Dell’s BIOS thought of these hardware changes. After I the powered the machine and entered the setup screen, the BIOS automatically detected the compact flash IDE adapter and memory card as a 2 GB hard disk. It also recognized the Sony CD-RW. That’s it! Save settings and exit. The next interesting task was to write the m0n0wall software image to the memory card in the PC. I have the one compact flash IDE adapter, so my approach to load the software was somewhat improvisational based on the machine I was using and the resources I had available to me the evening I decided to take this on. For me to be able to load the m0n0wall software, I had to boot the machine with an operating system from the CD-RW and then transfer the m0n0wall image directly from some media to the compact flash IDE adapter. I decided the easy approach would be to boot a FreeBSD or Linux installation disk, enter a rescue mode and get to a command prompt where I would have the basic tools available. For example, the CentOS 5.1 rescue mode on disk 1 has the dd and gunzip utilities I need to write the m0n0wall software image to the memory card. What media would I get the m0n0wall software image from? At this point it was sitting on my PowerBook’s file system after downloading it from the m0n0wall web site. The Dell PC I am using for the firewall has two USB connectors on the back. Since I didn’t want to create a custom boot CD, I decided to try to boot from the CentOS 5.1 disk in the CD-RW and use a USB memory stick with a FAT file system to contain the m0n0wall software image file. I formatted a USB memory stick with a FAT file system and simply copied the m0n0wall generic PC image to it. I plugged the USB memory stick into the back of the Dell and booted the CentOS 5.1 disk 1 from the CD-RW. I selected the rescue mode and made my way to a Bash command prompt after a couple of questions. Once at a command line, I used the dmesg command to see if the kernel had recognized USB memory stick during boot and if it had been assigned a device name. The kernel did find it and created it as a pseudo-SCSI device. The next step was to mount the FAT file system of the USB stick into the rescue file system. The root of the CentOS rescue file system is a RAM disk so this was no problem. I created a directory called /tmp/usb and mounted the USB device there. I could see the m0n0wall image file now. Section 3.2.2 of the m0n0wall handbook provides the basic template for the dd command in Linux to write the image to the memory card. I needed to take note of the different device names and location of the file containing the m0n0wall image. gunzip -c /tmp/usb/generic-pc-1.2XX.img | dd of=/dev/hdX bs=16k This took just a few seconds to complete. During the transfer of data, I could see the activity light on the StarTech IDE2CFINT flickering, so I knew something was really happening. I got a prompt back and summary from dd of how much data was written. I pulled the CentOS disk from the CD-RW and removed the USB stick from the back of the PC, and rebooted. I watched the Dell POST complete and soon after I saw the familiar spinning cursor of the FreeBSD boot loader, followed by kernel messages, and finally a m0n0wall console menu. The Dell PC booted from a compact flash memory card and m0n0wall was ready to be configured. ...

It really has been about 1.5 years since my last post. I have been busy and now have plenty to write about. A few months ago I deployed a dedicated system running m0n0wall at the edge of my network. I needed to find a firewall and router that could do the usual firewally things. I needed support for inbound and outbound NAT, DHCP and DNS for LAN clients, and inbound VPN when I am away. I did not want the firewall to rely on any other system in the network aside from the ISP’s router. Last year a new requirement surfaced in that the office needed shaping and prioritizing of traffic to and from the Internet. There is a VOIP adapter here for AT&T CallVantage. Skype is also used periodically. Real time traffic needs priority over everything else. Traffic related to the web and email servers need to run at the lowest priority. Services like SMTP don’t need the full bandwidth of my connection here in either direction. I often find bursts of incoming SMTP can cause drop-outs on the VOIP calls. The several workstations on the network here need reasonable connectivity - high priority than the servers but less than the VOIP traffic. Finally, if a class of service is not competing with any other, that service should get the bulk of available bandwidth regardless of priority. Here is a high-level diagram of my network. From m0n0wall With the next few postings, I will go into detail of how I successfully deployed m0n0wall on this network to satisfy these requirements. ...

I recently updated my PGP/GPG keys. I uploaded the public key to the MIT key server and a Google Sites page. MIT Server Google Drive

AOL, Google, and Yahoo have been in the news about their responses to a Justice Department request for search terms used by the worldwide Internet community. AOL and Yahoo have agreed, while Google has refused to hand over the information. A court battle is on the way.I really haven’t given this subject much thought until the other night when I was looking for references to my family name using Google. I searched on my name, family member’s names, addresses and even phone numbers. Then it occurred to me - search terms do contain private data. How many times have I put someone’s name into a search engine to find out about them? By now, hundreds of times. The government has said repeatedly they are not interested in who is performing the search, but I also believe there is enough private data in search terms to restrict that data as well. Considering the amount of time Google and Yahoo have probably been archiving usage data for profiling and optimizing their services, there has to be mountains of search terms that would make an NSA analyst wet themself.How many people have put their social security number into a search engine to see if it has been compromised? How many people have put a credit card number into a search engine for the same reason? How many times have you searched on something related only to you? Perhaps something private about you?The more I thought about it, the more I believe that every bit of data related to Internet search should be maintained as private and should only be obtained through proper court authority. ...

I was first introduced to DSHIELD last month. Particularly, my interest was in the textual feeds of recommended hosts to block at the firewall. The lists come in the form of a text file formatted with individual hosts and entire networks. The feeds are refreshed on a regular basis from community input. I wrote a small shell script to pull these recommended lists and create an iptables chain that is called from my existing server firewalling rules. The input, output and forwarding chains all call the DSHIELD chain. After about a month of use it seems to have paid off, because the DSHIELD chain in my firewall rules blocks many packets from these blacklisted hosts - and so far no one has complained. This script is run nightly to refresh the DSHIELD chain. If for any reason it cannot contact the DSHIELD site, it will keep the existing rules in place. Here is the BASH shell script I use on Fedora and CentOS servers. ...

Risks associated with B2B e-commerce include the technical problems of creating an Internet-facing business system that enables you and your partners to save money and react quickly by doing all transactions electronically. Additionally, I found there is some concern about the antitrust risks of business-to-business exchanges. I initially started searching for technical risks, and came across this document about the business risks of competitors working closely in collaboration to negotiate prices. http://mipr.umn.edu/archive/v2n2/gotfredson.pdf Certain models of B2B exchanges would have the competitors in an open auction against each other to win the bid for some product or service. “In spite of the promises inherent in this new business model, B2B exchanges necessarily involve collaboration between competitors in a market, and thus raise potential antitrust concerns.” There is actually nothing new here about types of antitrust activities a company might undertake with B2B. I think the point of the paper tells us that the Internet potentially makes this easier to take place. Connectivity between competitors and collaborators over the Internet and the growing sophistication of software provides an atmosphere where antitrust activities can occur without immediate notice. “A second antitrust risk associated with B2B exchanges stems from the fact that the Internet allows for the aggregation and analysis of copious information concerning the exchange’s participants.” I was not able to determine if any company has had legal action taken against them for B2B-related antitrust activities. The technical risks involved with B2B are typical for Internet-facing servers of e-commerce applications. For instance, Amazon uses a web front end to interface with their customers. The front-end of an application is one place vulnerabilities can be exploited to someone’s gain. Even though B2B exchanges may use a different kind of communication protocol, like a web-service or EDI communication, if there are weaknesses in the protocol, there is a possibility someone could use it to their advantage without immediate notice. An act that is as simple as transmitting illegal values for valid operations could allow unauthorized access because of a lack of sufficient defensive programming on the server-side. I found a PowerPoint presentation (link below) that listed some areas of potential loss from poorly designed e-commerce systems. Theft of Intellectual Property Theft of Proprietary Information Sabotage of Data Networks System Penetration Insider Abuse Financial Fraud Denial of Service Virus http://www.business.duq.edu/BusinessSecurity/docs/mootcourt.ppt ...

I had an idea today about how to make servers self destruct in case of some type of security breach. I guess this might be influenced by the Star Trek movie I saw the other night. They seem to blow up more Enterprises in the recent stories. My idea is to keep a blank CD-R in the drive of the server at all times. On hard disk there is an ISO file that is written to the CD-R on demand and then the server is rebooted. The server will ignore the blank CD-R during reboots until it is written with a valid image. The contents of the ISO needs to be a boot loader and kernel, like Grub and Linux plus a file system with a wipe program. The wipe program is started once the kernel is booted and it iterates through the collection of hard drives, which the kernel found during the boot process, and writes over them with a pattern.This kind of the self destruct sequence can be automated with a script and invoked through a terminal on the local network or through a VPN. It could also be loaded into cron and deactivated on a regular basis from going off.So, if your servers are under heavy attack, and you have no other choice, start the count down. :-) ...