vSwitchPro – Introduction:

When DTMF Networks wanted to expand its Voice Network they went out to look for a solution that is reliable, scalable and suits the needs of complex business scenarios like prepay monitoring, automated blocking, alert system etc. But current offerings does not have all those required features and those who have these features are very expensive, so DTMF Networks decided to build its own solution for the expansion.

Engineers from DTMF Networks spent 6 months on the white board in nailing down the required feature set, UI and UX was the priority for DTMF Networks, so the design team had to work very hard to make this complex system easier to manage.

Current Salient feature set of vSwitchPro:

• One Box Solution, capable of handling 5000 SIP session per node
• Automated Prepaid blocking
• CRM Panel
• RTP Proxy support
• Advanced routing management
• Detailed CDR reports for effective monitoring includes QoS/NER/Engineering Reports
• Alarm Provisioning
• Role based access

5000 Session per node: to achieve this DTMF Networks opted for Sofia SIP Engine (an open source SIP Engine used in FreeSwitch) But of coarse a lot of modification ahs been done to made that SIP stack so efficient so that it can handle upto 5000 sessions with 200 CPS

Automated Prepaid Blocking: This feature was absent in class 4 softswitches and it was a must have feature for small/medium size voip operators, so DTMF Networks decided to incorporate automated prepaid blocking system in vSwitchPro so the operators can feel confident on the system and without having to worry about losses due to excess usages.

CRM Panel: Again a missed feature in class 4 softswitches, but customers of operators always want to know their balance, usage, payment history, CDRs so it was added. Now operators do not need to worry about above mentioned enquiries.

RTP Proxy: RTP Proxy was made optional for the operators, so those who need this feature can enable it

Routing Management: Having experience of different softswitches DTMF Networks designed a simple interface for complex routing like Time of Day (TOD), Pool based routing, Source based, DNIS based routing. All those required features was added in the system to enhance the productivity of the operators.

CDR Reports: vSwitchPro have 3 level of CDRs, starting from collective calls to one call. it classifies calls in four categories:
- Abandoned
-Busy
-Error
-Normal

Alarm Provisioning: Quality is very critical in VoIP Business and no one knows better it than DTMF Networks. so we have implemented Alarms in switch. it generates alarm (Email) for system issues, Route issues, Low Balance, Voice Quality Degradation, ASR, ACD, PDD

Role Based Access: Again a must have feature to make the system secure, now operators can assign roles to their system user. For example a NOC user cannot add balance in customer or a commercial guy cannot add the endpoint.

 

You Can download vSwitchPro from: http://www.vswitch.cc/Docs/vSwitchPro-package.zip 

User and Installation manuals are also available at : http://www.vswitch.cc/vSwitchPro_user_manual.html

 

VoipSwitch is one of the most widely deployed VoIP solution, just because of its cost and familiarity of users with its interface. However managing it could be worse nightmare of Network Administrators or Support persons. By Stats it is highly vulnerable for attacks. Reasons are simple:

• Design flaws (not secured by design)
• Based on Windows (Prior to Windows Server 2008, Windows Servers could be easy target for attackers)
  Hackers usually use simple techniques to create accounts on VPS, like SQL injection, RDP to DB/Application Servers, use brute force attacks to login VSC/VPS.
  To Prevent these kind of attacks, first & foremost change generic username on Windows machines such as by default user “vsc” is created to login to VSC, change that to “myvsc6581” so that its hard for hackers to guess the username. also change the Administrator username or better create another username and assign it to Administrator group and Disable the default user “Administrator”. Account lockout policy should also be properly configured so in case of brute force attack Account is locked out after 5 incorrect attempts.
  To secure VoIPSwitch Servers from attacks always put DB on separate machine and DB should be configured to listen ONLY on Private IP (DB & Application should be on same LAN) and RDP to DB machine should not be allowed on public IP. Its always better to put a Firewall in front of DB & Application machines, all ports other than configured SIP ports, Web ports & required ports like SNMP should be blocked on Firewall.
  All Application machines should be configured to allow RDP from your Known Public IP or VPN.
  Default VSC web path should be changed to custom path like www.xyz.com/myvps3-u/admin/index.aspx
  Logs on Windows machines should also be monitored at least once in a week and see which processes are running on the machine using Task Manager, All un-used Windows services should be disabled so it will be easy to recognize any unknown service
  Above mentioned points are some of the very basic security that should be applied on VoIPSwitch installations.

Hardware Address Spoofing

at the hardware layer, network interface cards (NIC) will have hardware interface address, Most network interfaces can be put into promiscuous mode and may receive frames with any  destination address. A more serious problem occurs if the network interface can alter the source address and send data that appears to come from various source address. Each network interface has 48 bit hardware address, Networks use this hardware address to match the variety of destination address of the frames it sees. The interface copies the matching destination address into its internal buffer and notifies the OS that they are available for further processing. Packets coming from the OS to the interface do not typically specify a source address; the interface always puts its hardware address in the source field.

Most softwares does not typically control the source field of frames leaving an Ethernet interface. When another host examines a packet containing a hardware source address associated with an interface of a particular machine, it assumes that packet is originated from that machine and accepts it as authentic.

ARP Spoofing

Address Resolution Protocol (ARP) is a more common way of spoofing. ARP is part of Ethernet and some other protocols that associate hardware address with IP address. ARP itself is not a part of IP but part of these Ethernet like protocols; ARP supports IP and other arbitrary network-layer protocols. Ehen an IP datagram is ready to go out on such a network, the host needs to know the hardware address of destination to associate with with the given IP destination address. For local IP adestinations, the hardware address to use will be the address of one of the routers on the local network.

To find the hardware address, the host sends out an ARP request using the hardware broadcast address. A frame with the hardware broadcast address reaches every network interface on the local network and each host on the local network has its OS interrupted by the network interface. The ARP request asks the question “What is the hardware address of this corresponding IP I have here?”, Typically only the host of matching IP address sends an ARP reply while remaining hosts just ignores the request.  As the ARP request contains the IP address of source other hosts could potentially store the association between hardware and IP address of the sender of the request for future reference. The association between hardware and IP address of other machines on a network in stores in ARP cache on each host. so if a spoofer wants to be the target of IP datagrams being sent to a particular IP address from a particular host it needs to make sure it has the IP address and hardware address binded on his system and he is good to go.

Believe it or not, Windows have its fair share in Server Market where many of the critical services and applications running on windows machines. Since Windows Server 2003, Windows is very stable and can meet 99.9% availability criteria IF properly configured and managed.

[Image Source]

Windows PowerShell is the new tool released by Microsoft for the lovers of Command Line Users. its pretty much same like Unix Shell and give the same power and flexibility which NIX users are enjoying for over two decades now. If you would like to know more about PowerShell follow this link

So After digging it for few minutes I found a way to monitor services on Windows machines and powershell script can e-mail if the service is down. I was looking for this thing for quite some time now as we have some windows machines which are running some critical applications. the following script will just check if the mentioned service (MSN messenger in below sample) is running or not and send the status e-mail. We can automate the script to run every hour or half an hour or continuously check for the services and sends and email when the service is down. depending upon the nature of services you are monitoring.

$SmtpClient = new-object system.net.mail.smtpClient // initializing smtp client
$SmtpServer = "mail.xyz.com" // SMTP mail server
$myvar = (get-process | where-object {$_.Name -eq "msnmsgr"}).count // gets the number of processes running with the name of msnmsgr

$From = "Test Server <root@xyz.com>" // sets the mail from name and address
$To = admin@xyz.com // sets the recipients of email
$Title = "MSN STATS" // sets the subject of mail 
$Body = // Starting the Body of email
"Status of MSN messenger =  $myvar Instance of MSN messenger running //puts the myvar variable
$SmtpClient.Send($from,$to,$title,$Body)  // sends the mail message with the given parameters

We can of coarse customize the script to suit our needs. but I think its a great step from Microsoft side to provide this tool and give flexibility to Windows Server users.

So this leaves us wondering what the impact will be when these two inevitable trends merge.

Not that many years ago, we were quite concerned about VoIP due to the bandwidth overhead. Voice packets tend to be quite small. In fact, for the low-bit-rate codecs that tend to be used with VoIP, a typical packet size is on the order of 20 to 40 bytes. (These small packets are necessary in order to avoid too much latency.)

And the overhead simply due to IPv4 and UDP about equals the payload size, with at least 20 bytes (octets ) for IPv4 plus at least 8 octets for UDP. Now IPv6 is coming, and at least doubling the header size.

We can see two sides to this situation.
On the plus side, IPv6 offers some much-needed additional control. Overall, VoIP should perform “better” when it’s VoIPv6.

At the same time, the additional overhead is a concern. Have we finally reached the point that we can make the same assumption of “free unlimited bandwidth” for WAN communications that we’ve made for years concerning LAN communications?

http://www.bing.com/search?q=snmp&form=SNYTDF&pc=MASN&src=IE-SearchBox

SNMP is based on UDP (A stateless protocol) and it has inherently a weak authentication system. For Private communities it has RW (Read/Write) and for Public it has R (read only) access. These strings pass on networks unencrypted and often left in their original state.

Using a simple sniffer (such as wireshark), an attacker can capture SNMP requests sent to servers thus potentially security of important servers can be at risk. and since the private community has RW access it can be used to mis-configure a router or network devices by attackers to gain access to core servers.

A simple SNMP walk can reveal installed software information; windows users (considering SNMP is enabled on windows); open TCP ports.

Therefore, SNMP should be dealt with using security in mind and considering this that this simple tool can put a fairly secure network at greater risks.

Above packet seems to be a normal one; all tags are in place, call ID is same; CSeq is same…so why does Nextone does not understand it, where is the problem?

Well the problem lies in Warning field; take a closer look:

Warning: 399 SoftX3000 R601-CCU Rel POS:[14131] Release from CR

but as per SIP RFC 3261 Warnging field text should be quoted, so it should look like this:

Warning: 399 SoftX3000 “R601-CCU Rel POS:[14131] Release from CR”

Reference from SIP RFC 3261:

Page: 231 – Standard tracks

Warning        =  "Warning" HCOLON warning-value *(COMMA warning-value)
warning-value  =  warn-code SP warn-agent SP warn-text
warn-code      =  3DIGIT
warn-agent     =  hostport / pseudonym
                  ;  the name or pseudonym of the server adding
                  ;  the Warning header, for use in debugging
warn-text      =  quoted-string
pseudonym      =  token

  So lets see how to install Asterisk. I assume you have fresh installation of Centos. now follow these steps

 Asterisk Setup

1. cd /usr/src   —-> Go to the src Directory, This could be any directory where you want to download the packages. This does not affect installation folders.

2. wget http://downloads.asterisk.org/pub/telephony/asterisk/releases/asterisk-1.6.0.13.tar.gz –> download Asterisk package

3. tar-xvzf asterisk-1.6.0.13.tar.gz –> un-tar (unzip) asterisk package

4. cd asterisk-1.6.0.13 —> Go to Asterisk directory

5. make clean –>

6. ./configure —> Install Asterisk package on your machine

7. make samples —-> make sample configuration files for your reference.

***** You are done with basic Asterisk setup. *****

Now for initial starters there are only two files on which you can perform basic funstions.

extensions.conf (located at /etc/asterisk/)

sip.conf (located at /etc/asterisk)

Extensions.conf

Extensions.conf is basically the dial plan of Asterisk, in other words its the brain of asterisk and here you define what to do when a user places a call or asterisk receives the call. Below is a basic dial plan, it receives the call and playback hello world.

[sample]   <— this is the context; we’ll discuss this later
exten => _X.,1,Answer()
exten => _X.,n,PlayBack(Hello-world)
exten => _X.,n,Hangup()

_X. for any string which has been dialled from user.
1  for the priority, the order of instructions, in next steps numeric number replaced by n it means the next step, we could have used 2 3 in next steps but we have preferred to use n because in long dial plans using numeric can be headache.
Answer() is the function call to asterisk to answer the call
PlayBack(Hello-world) his tells Asterisk to play a specified sound file. By default, it plays files found in /var/lib/asterisk/sounds/, but you can also specify another source directory. No file extension is specified because the directory may contain the same sound in different formats. Asterisk will select the most appropriate format
Hangup() this tells asterisk to terminate the call

Sip.conf

Sip.conf is the file where you define the user/gateways of asterisk. Below is the sample configuration for a user

[2000]
type=friend
secret=2000abc
disallow=all
allow=ulaw
allow=g729
host=dynamic
nat=yes
context=sample

[2000] is the username
type determines whether it is Ingress (to Asterisk) or Egress (from Asterisk) user. there can be three type of users a) friend b) peer c) user

friend = can make calls both way
peer = only “from asterisk” calls are allowed
user = only “to asterisk” calls are allowed
secret = password of user
disallow= disallow all codec other than explicitly defined
allow = allowed codec list
host=IP address of client
nat= enable/disable nat option
context= dial plan to follow when this user dials a number. (Remember extensions.conf)

Now download eyebeam client and check it out….in case of any query you can always contact me