Category: Ubuntu


Web MeetMe : Conferencing in FreePBX

Filed under: Linux, Open Source, Ubuntu, work — Leave a comment
November 30, 2012

The company I work for currently uses TrixBox as their VoIP server. It’s an excellent piece of software but being no longer supported, the decision was taken to upgrade to the later and more active FreePBX. Since they are both built around the asterisk core, I figured this upgrade wouldn’t be too much of a problem. In fact it wasnt, most of the features in TrixBox I got working in FreePBX with no effort.

There was one stumbling block: conferencing. In TrixBox, users used to dynamically create conferences on the fly using WebMeetMe. In TrixBox, installation and activation of WebMeetMe was as simple as downloading and activating the appropriate module. Alas, in FreePBX the excellent WebMeetMe is not pre-installed (why??). So the installation is a bit more involving though ultimately works just as well :)

I am taking the opportunity to document exactly what I’ve done to get this working:

1. Download latest version of FreePBX

2. Install FreePBX as per usual procedures. Create a couple of SIP extensions and make sure they work before proceeding. Pleny of documentation on the ‘net if you get stuck here

3. Download the latest version of WebMeetMe

Note: For any of the below to work you need to ensure that FreePBX is setup to use the meetme module rather than the newer “confbridge”. This is done via:

FreePBX > Settings > Advanced Setting and ensure that Conference Room App is set to “app_meetme“

3

4. The README within the tarball downloaded from 3 has some good install notes, however I found Mark In the Dark’s install notes to be much clearer and helpful. So, I followed the steps outlined here:

http://www.markinthedark.nl/news/ubuntu-linux-unix/75-install-web-meetme-402-for-freeppbx-28-with-asterisk-18-on-centos-55.html

5. Once the above procedure was done, visiting the page http://%5Bmy-ip-address%5D/web-meetme/meetme_control.php returned a HTTP 500 error. Checking the /var/log/httpd/error logs I saw a corresponding entry similar to:

PHP Parse error:  syntax error, unexpected $end in /var/www/html/web-meetme/lib/defines.php on line 145

To resolve the above, open the file defines.php, scroll to the bottom, and change the last three lines from this:

<?
}

?>

To this:

<?php
}

?>

6. If, like me, you decided on using MYSQL for authentication rather than LDAP, I again ran into an HTTP 500 error when attempting to logon. The error was:

PHP Fatal error:  Call to undefined function authsql() in /var/www/html/web-meetme/lib/functions.php on line 73

To resolve this, copy the contents of:

/var/www/html/web-meetme/lib/sqldb.php 

into:

/var/www/html/web-meetme/lib/functions.php

The above should allow you to login and schedule calls using web meet me. That said, I found documentation on how to setup an extension which callers could use to dial into WebMeetMe woefully lacking. Here’s what I did:

1. Add a custom extension

> SSH into the box, and edit the file: /etc/asterisk/extensions_custom.conf

> Add the following to the file:

[conferences]
include => ext-meetme; in [ext-meetme] contest are stored all the conferences created in FreePBX
exten => s,1,Answer
exten => s,n,Wait(1)
exten => s,n,Playback(welcome); Insert your welcome recording
exten => s,n,Goto(STARTMEETME,1)

2. Add custom destination
This step is needed to make the FreePBX GUI aware of the custom extension we define above, and make it available as a choice within the GUI. Within FreePBX: [admin > custom destination] and use:

Custom Destination: conferences,s,1
Description: conftest

1

At this stage, you have an extension you can use. In our case we needed the webmeetme to be dialed into from both an external number and an internal one.

For external callers

  • FreePBX > Connectivity > Inbound Routes. Select the appropriate DID, ex 21123456, and set the destination as a custom destination and select conftest from the pull-down menu (or whatever you entered in step 2 above)

For Internal callers

  • FreePBX > Applications> Misc Applications. Enter in a description, a “feature code” (which is the number internal users will dial, example *789, and select the destination to be a custom destination and select conftest from the pull-down menu (or whatever you entered in step 2 above)

2

About these ads
Tags: , ,
Comment

Update: SQUID transparent SSL interception : Squid v3.2

Filed under: Linux, Open Source, Security, Ubuntu — 2 Comments
July 5, 2012

In order to keep this blog post a bit more relevant, there have been some improvements since that post was written. Squid v3.2 has been released earlier this year, making ssl interception more seamless and easier. The new features for HTTPS interception can be found while reading through the man page for http_port:

http://www.squid-cache.org/Versions/v3/3.2/cfgman/http_port.html

More specifically:

1. The “transparent” keyword has been changed to “intercept“:

           intercept    Rename of old 'transparent' option to indicate proper functionality.

INTERCEPT is now better described as:

intercept	Support for IP-Layer interception of
			outgoing requests without browser settings.
			NP: disables authentication and IPv6 on the port.

2. In order to avoid more certificate errors when intercepting HTTPS sites, squid now can dynamically generate SSL certificates, using generate-host-certificates. This means the CN of the certificate should now match that of the origin server, though the certificate will still be generated using SQUID’s private key:

SSL Bump Mode Options:
	    In addition to these options ssl-bump requires TLS/SSL options.

	   generate-host-certificates[=<on|off>]
			Dynamically create SSL server certificates for the
			destination hosts of bumped CONNECT requests.When 
			enabled, the cert and key options are used to sign
			generated certificates. Otherwise generated
			certificate will be selfsigned.
			If there is a CA certificate lifetime of the generated 
			certificate equals lifetime of the CA certificate. If
			generated certificate is selfsigned lifetime is three 
			years.
			This option is enabled by default when ssl-bump is used.
			See the ssl-bump option above for more information.

Looks like the above is an offshoot of the excellent work here: http://wiki.squid-cache.org/Features/DynamicSslCert

Make sure to use the above two features for smoother HTTPS interception – though remember, always warn users that SSL traffic is being decrypted, privacy is a highly-valued right…

Tags: , , , , ,
Comment

SQUID transparent SSL interception

Filed under: Linux, Open Source, Security, Ubuntu — 20 Comments
March 22, 2011

July 2012: Small update on new versions of squid (squid v 3.2) here

There seems to be a bit of confusion about configuring SQUID to transparently intercept SSL (read: HTTPS) connections. Some sites say it’s plain not possible:

http://www.faqs.org/docs/Linux-mini/TransparentProxy.html#ss2.3

Recent development in SQUID features have made this possible. This article explores how to set this up at a basic level. The SQUID proxy will basically act as a man in the middle. The motivation behind setting this up is to decrypt HTTPS connections to apply content filtering and so on.

There are some concerns that transparently intercepting HTTPS traffic is unethical and can cause legality issues. True, and I agree that monitoring HTTPS connections without properly and explicitly notifying the user is bad but we can use technical means to ensure that the user is properly notified and even gets prompted to accept monitoring or back out. More on this towards the end of the article

So, on to the technical details of setting the proxy up. First, install the dependencies . We will need to compile SQUID from scratch since by default it’s not compiled using the necessary switches. I recommend downloading the latest 3.1 version, especially if you want to notify users about the monitoring. In ubuntu:

apt-get install build-essential libssl-dev

Note : for CentOS users, use openssl-devel rather than libssl-dev

Build-essentials downloads the compilers while libssl downloads SSL libraries that enable SQUID to intercept the encrypted traffic. This package (libssl) is needed during compilation. Without it, when running make you will see the errors similar to the following in the console:

error: ‘SSL’ was not declared in this scope

Download and extract the SQUID source code from their site. Next, configure, compile and install the source code using:

./configure –enable-icap-client –enable-ssl
make
make install

Note the switches I included in the configure command:

* enable-icap-client : we’ll need this to use ICAP to provide a notification page to clients that they are being monitored.

* enable-ssl : this is a prerequisite for SslBump, which squid uses to intercept SSL traffic transparently

Once SQUID has been installed, a very important step is to create the certificate that SQUID will present to the end client. In a test environment, you can easily create a self-signed certificate using OpenSSL by using the following:

openssl req -new -newkey rsa:1024 -days 365 -nodes -x509 -keyout http://www.sample.com.pem  -out http://www.sample.com.pem

This will of course cause the client browser to display an error:

tranSSL

In an enterprise environment you’ll probably want to generate the certificate using a CA that the clients already trust. For example, you could generate the certificate using microsoft’s CA and use certificate auto-enrolment to push the certificate out to all the clients in your domain.

Onto the actual SQUID configuration. Edit the /etc/squid.conf file to show the following:

always_direct allow all
ssl_bump allow all

http_port 192.9.200.32:3128 transparent

#the below should be placed on a single line
https_port 192.9.200.32:3129 transparent ssl-bump cert=/etc/squid/ssl_cert/www.sample.com.pem key=/etc/squid/ssl_cert/private/www.sample.com.pem

Note you may need to change the “cert=” and the “key=” to point to the correct file in your environment. Also of course you will need to change the IP address

The first directive (always_direct) is due to SslBump. By default ssl_bump is set to accelerator mode. In debug logs cache.log you’d see “failed to select source for”. In accelerator mode, the proxy does not know which backend server to use to retrieve the file from, so this directive instructs the proxy to ignore the accelerator mode. More details on this here:

http://www.squid-cache.org/Doc/config/always_direct/

The second directive (ssl_bump) instructs the proxy to allow all SSL connections, but this can be modified to restirct access. You can also use the “sslproxy_cert_error” to deny access to sites with invalid certificates. More details on this here:

http://wiki.squid-cache.org/Features/SslBump

Start squid and check for any errors. If no errors are reported, run:

netstat -nap | grep 3129

to make sure the proxy is up and running. Next, configure iptables to perform destination NAT, basically to redirect the traffic to the proxy:

iptables -t nat -A PREROUTING -i eth0 -p tcp –dport 80 -j DNAT –to-destination 192.9.200.32:3128
iptables -t nat -A PREROUTING -i eth0 -p tcp –dport 443 -j DNAT –to-destination 192.9.200.32:3129

Last thing to be done was to either place the proxy physically in line with the traffic or to redirect the traffic to the proxy using a router. Keep in mind that the proxy will change the source IP address of the requests to it’s own IP. In other words, by default it does not reflect the client IP.

That was it in my case. I did try to implement something similar to the above but using explicit mode. This was my squid.conf file, note only one port is needed for both HTTP and HTTPS since HTTPS is tunneled over HTTP using the CONNECT method:

always_direct allow all
ssl_bump allow all

#the below should be placed on a single line

http_port 8080 ssl-bump cert=/etc/squid/ssl_cert/proxy.testdomain.deCert.pem key=/etc/squid/ssl_cert/private/proxy.testdomain.deKey_without_Pp.pem

As regards my previous discussion of notifying users that they are being monitored, consider using greasyspoon:

http://dvas0004.wordpress.com/2011/02/28/squid-greasyspoon-enhancing-your-proxy-deployment-with-content-adaptation/

With this in place, you can instruct greasyspoon to send a notify page to the clients. If they accept this notify page, a cookie (let’s say the cookie is called “NotifySSL”) is set. GreasySpoon can then check for the presence of this cookie in subsequent requests and if present, allow the connection. If the cookie is not present, customers again get the notify page. Due to security considerations, most of the time cookies are only valid for one domain, so you may end up with users having to accept the notify for each different domain they visit. But, you can use greasyspoon in conjunction with a backend MySQL database or similar to record source IP addresses that have been notified and perform IP based notifications. Anything is possible :)


Tags: , ,
Comment

User based access control for Skype

Filed under: BlueCoat, Linux, Open Source, Ubuntu — Leave a comment
March 16, 2011

I recently wrote an article for Bluecoat describing how to limit Skype access based on usernames and passwords. The article is available here.

This got me wondering if I can achieve the same functionality that the Bluecoat ProxySG offers but using open source programs. In short…. yes we can with a little tinkering. For those of you not interested in reading through the draft for BlueCoat, here is a summary of requirements that this article attempts to achieve:

Skype is allowed to be installed on the desktops, but Skype connectivity should be allowed/denied based on username and password, not on source IP or destination IP. ideally, the usernames and passwords are centrally managed through Active Directory.

The above problem was tackled with BlueCoat by using SOCKS authentication. The Bluecoat proxy then uses it’s BCAAA agent to verify the provided username and password with Active Directory.

After some research, it turn out you can achieve the above method by using DANTE socks server. The site for Dante is here:

http://www.inet.no/dante/

I wont go through the caveats and security implications of this method, for that, see the BlueCoat document above. I will go into the technical details of setting up a DANTE socks server and using LDAP to verify usernames/passwords against an AD domain controller.

For my particular setup, I’ve used an Ubuntu machine which already has SQUID installed on it. DANTE and SQUID run happily side by side. Ubuntu has DANTE as a package in Synaptic so installing it is a simple matter of applying the package. When configuring DANTE, the following three sites from their documentation really helped to clarify what needed to be done:

http://www.inet.no/dante/config/server.html

http://www.inet.no/dante/config/auth.html

http://www.inet.no/dante/doc/faq.html

Let me highlight step by step what needed to be done in my case:

1. Install the DANTE server and pre-requisites for LDAP PAM authentication:

sudo apt-get install danted libpam-ldap libnss-ldap

2. These should install successfully  and you should now be able to modify the DANTE configuration file located at /etc/danted.conf. This was my (basic) configuration. I’ve commented in some explanations to the statements:

#enable logging to a particular file (/var/log/dante.log)

logoutput: stdout /var/log/dante.log

#instruct the server which IPs and ports to listen on. In my case, the server has only a single #interface, so both IPs are the same. Note the standard SOCKS port of 1080

internal: 10.91.25.3 port = 1080
external: 10.91.25.3

# (this was part of the automatically generated default configuration) when doing something that # can require privilege, it will use the userid:
user.privileged: proxy

# (this was part of the automatically generated default configuration) when running as usual, it   # will use the unprivileged userid of:
user.notprivileged: nobody

# (this was part of the automatically generated default configuration)

# If you compiled with libwrap support, what userid should it use
# when executing your libwrap commands?  “libwrap”.
user.libwrap: nobody

# the following instructs the SOCKS server which authentication method to support. In my case, # since DANTE is going to pass the credentials on to PAM which in turn hands over to LDAP, I     # specified “pam” and “none”. (see note on point 3 below)

clientmethod: pam none
method: username pam none

# these rules define who is allowed to use the SOCKS server. These rules get applied before any  # SOCKS data is passed so PAM authentication is not applied here (only can only authenticate     # using IP information at this stage)

client pass {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: error connect disconnect
}

# these rules define what the SOCKS clients can reach. This is where we enforce PAM                   # authentication using the method keyword, so only authenticated users can connect to the      # outside world

pass {
from: 0.0.0.0/0 to: 0.0.0.0/0
command: bind connect udpassociate bindreply udpreply
method: pam
log: error connect disconnect iooperation
}

3. A quick note on the above configuration file. I found that the SOCKS server would reset the skype conenction if I used

clientmethod: pam
method: username pam

Right after Skype provides it’s supported methods of authentication, SOCKS reset the connection. It seems that Skype provides two methods of authentication: none and username/password. It seems that the SOCKS server needs to be configured to support both these methods also. Using

clientmethod: pam none
method: username pam none

resolved this issue for me

Also, note that in a production environment the access rules should be very much more restricted. Keep in mind that as I outlined in the bluecoat document, the username and password are still sent as cleartext so you need very restrictive access rules in case those credentials are compromised.

4. As per the DANTE FAQ, we next modify the PAM file for the socks server to instruct it to use LDAP for authentication. The file to be created is /etc/pam.d/socksd:

# cat /etc/pam.d/socksd
#%PAM-1.0
auth       required /lib/security/pam_ldap.so
account    required /lib/security/pam_ldap.so
password   required /lib/security/pam_ldap.so

Note I deviated from the proposed file in the FAQ. The FAQ proposition checked first the LDAP server, then if that failed, checked the local password file. In my case, I want to restrict logins to only AD users, so in the above file I force PAM to use LDAP only

5. Still following the FAQ, we next move on to modify the file /etc/ldap.conf. This file controls the LDAP client, which the PAM subsytem uses to check the credentials supplied to it. In Ubuntu, the file is already pre-populated with information generated when installing the packages in step 1, but after uncommenting some lines you should end up with something similar to the fillowing:

/etc/ldap.conf

host 10.91.25.2
base dc=davidv,dc=local
ldap_version 3
binddn cn=Administrator,cn=Users,dc=davidv,dc=local
bindpw password02!
#rootbinddn cn=Administrator,cn=Users,dc=davidv,dc=local
pam_filter objectclass=user
pam_login_attribute cn

A couple of points:

  • The auto-generated file uses and LDAP URI to define which host to connect to. This didnt work for me and I had to change to the host 10.91.25.2 statement
  • The file proposed by the FAQ uses the “rootbinddn” statement, which I commented out above since the LDAP client is nornally nut run under root privileges and so I stuck to the “binddn” statement

That was really all there is to it. Of course you need to instruct users on setting up Skype to use your new SOCKS server – see the bluecoat document for info on how to do this.

Verification and Troubleshooting Tips

I found two files to be of great help during verification and troubleshooting:

/var/log/dante.log : the SOCKS server log that I specified in the configuration file

/var/log/auth.log : the PAM logs – this is where you’ll see authentication issues

Some examples of the logs:

  • Non-working dante.log (the problem here was authentcation – wrong credentials)

minty davvas # tail /var/log/dante.log

Mar 15 07:57:44 (1300175864) danted[20026]: block(0): tcp/connect [: pam%[email protected] -> 78.141.181.38.21219: pam_authenticate(): Authentication failure
Mar 15 07:57:44 (1300175864) danted[20024]: block(0): tcp/connect [: pam%[email protected] -> 78.141.181.26.33033: pam_authenticate(): Authentication failure

  • Working dante.log

minty davvas # tail /var/log/dante.log
Mar 15 07:54:01 (1300175641) danted[20027]: pass(1): tcp/connect ]: 39 -> pam%[email protected] -> 42,  42 -> pam%[email protected] -> 39: remote closed
Mar 15 07:54:01 (1300175641) danted[20027]: pass(1): tcp/connect ]: 39 -> pam%[email protected] -> 42,  42 -> 93.156.120.52.21516 -> 39: remote closed
Mar 15 07:54:02 (1300175642) danted[20027]: pass(1): tcp/connect -: 78.141.181.31.21219 -> pam%[email protected] (0)
Mar 15 07:54:02 (1300175642) danted[20027]: pass(1): tcp/connect ]: 32 -> pam%[email protected] -> 53,  53 -> pam%[email protected] -> 32: remote closed
Mar 15 07:54:02 (1300175642) danted[20027]: pass(1): tcp/connect ]: 32 -> pam%[email protected] -> 53,  53 -> 78.141.181.31.21219 -> 32: remote closed
Mar 15 07:54:06 (1300175646) danted[20027]: pass(1): tcp/connect -: pam%[email protected] -> 78.141.181.21.21219 (163)
Mar 15 07:54:06 (1300175646) danted[20027]: pass(1): tcp/connect -: 78.141.181.21.21219 -> pam%[email protected] (4)
Mar 15 07:54:07 (1300175647) danted[20027]: pass(1): tcp/connect -: pam%[email protected] -> 78.141.181.21.21219 (0)
Mar 15 07:54:07 (1300175647) danted[20027]: pass(1): tcp/connect ]: 13352 -> pam%[email protected] -> 20681,  20681 -> pam%[email protected] -> 13352: client closed
Mar 15 07:54:07 (1300175647) danted[20027]: pass(1): tcp/connect ]: 13352 -> pam%[email protected] -> 20681,  20681 -> 78.141.181.21.21219 -> 13352: client closed

  • Non working auth.log file (bad credentials)

Mar 15 07:57:39 minty danted: pam_unix(sockd:auth): check pass; user unknown
Mar 15 07:57:39 minty danted: pam_unix(sockd:auth): authentication failure; logname= uid=0 euid=13 tty= ruser= rhost=10.91.25.1

As always, wireshark is a great help. You can see the Skype authentication to SOCKS (note the cleartext credentials!):

socks1

And you can also see the SOCKS server verifying the credentials with LDAP:

socks2

Note that by default the LDAP client uses simple authentication, which sends the password out in cleartext… if this is a security issue consider securing LDAP using SSL/TLS

Some useful links for linux / microsoft LDAPS:

http://www.openldap.org/doc/admin24/tls.html

http://support.microsoft.com/kb/321051

http://support.microsoft.com/kb/938703

Tags: , , ,
Comment

Configuring basic cisco network traffic monitoring with ntop and NetFlow

Filed under: Cisco, Linux, Open Source, SonicWALL, Ubuntu — 4 Comments
February 1, 2011

If you are the admin of a cisco (and sonicwall now in the newer firmware) network, NetFlow is a good and easy way of gathering insight into what exactly is passing through your cisco. Apart from seeing link usage, netflow also allows the admin to see which protocols, ports and hosts are being used. This is much more granular and informative than the simple interface utilization that SNMP offers. this allows for easier troubleshooting such as helping to identify worms, or P2P usage, and so on.

There are several Netflow collectors out there, but my favourite is by far Ntop (http://www.ntop.org/news.php). It’s free, open source and easy to setup. Ntop usually works by listening on an interface, and parsing packet capture files to display the results in a nice graph format. In this particular case, I will disable Ntop listening on an interface and will not feed Ntop any pcap files. I am only interested in setting up Ntop as a netflow receiver and graphing those results.

I installed this on an ubuntu server. The following commands were run as root. First, the obligatory apt-get command to install the program:

# apt-get install ntop

Next, start Ntop in “interfactive” mode. Simply enter ntop at the command line:

# ntop

This is a necessary first step since you will be prompted to enter the admin password. Enter your password of choice, and wait until the output stops scrolling across the screen. There should be no errors. Then, close the ntop program by pressing ctrl+C. This should kill off the process. Next, we run ntop as root, not listening on any of the server’s interfaces, and running a web server on port 8080. Run the command:

# ntop –u root –i none –d –w 8080

A breakdown of the switches:

- u : user

-i : interface to listen on (in our case, “none”, else ntop will listen on eth0 by default)

-w : http webserver listen port

You should now be able to open a browser and browse to http://[your_server_ip]:8080. Once there, on the top menu, select Plugins > Netflow and select “activate”. Next, add a netflow “device”. You will be shown the netflow configuration. The important points here were:

- Local UDP port. I set this to the default 2055. Remember to press the “Set Port” button after!

- Virtual Netflow Interface Network Address. I set this to 10.0.0.0/255.0.0.0, since the cisco sits in front of a 10.x.x.x network. Remember to press the “set interface address” button.

- Dump File Path. You will probably need to change this to someplace with a lot of storage. Remember to press the button.

Hit the link to return to plugin or from the Plugins menu, select “all”. You should see a blue “yes” under the “active” column for NetFlow

Last step : from the “Admin” menu select “switch NIC” and choose the netflow device you created earlier

That’s it from the Ntop side of things. Now, on the cisco, as copied from the Ntop FAQs:

To enable netFlow Data Export (NDE) from a Cisco device to an ntop netFlow receiver on port 2055 (default) at address 10.1.1.1:

     ip flow-export destination 10.1.1.1 2055
     ip flow-export version 5

You may want to designate the source interface, e.g.:

     ip flow-export source Ethernet0

Enable netFlow on each interface to be monitored. netFlow normally only captures data from each incoming packet, so to see traffic in both directions netFlow must be enabled on both the incoming and outgoing interfaces. As an example, for an Internet access router this would mean enabling netFlow on both the internal (e.g. Ethernet) and the external (e.g. ISDN / Frame Relay etc) interfaces:

     interface Ethernet0
     ip route-cache flow
     interface Dialer1
     ip route-cache flow

By default netFlow will only export flow statistics shortly after the flow Terminates or when 30 minutes have elapsed. In many environments, you want ntop to be a bit more up to date. To change the timeout to five minutes:

     ip flow-cache timeout active 5

The following ‘show’ commands are useful for examining netFlow statistics directly on the Cisco box and may assist when setting up ntop:

     show ip flow export
     show ip cache flow
     show ip cache verbose flow

 

That’s all! A couple of screenshots will follow. Just in case you wonder what the colours mean:

Lower : An algorithm for predicting the values of a time series one time step

into the future

Upper : A measure of deviation between the predicted values and the observed

values.

Anomalia : A mechanism to decide if and when an observed value or sequence of

observed values is ‘too deviant’ from the predicted value(s).

1. Traffic throughput / network load

ntop1

2. Breakdown by protocol:

ntop2

Tags: , , , ,
Comment
Follow

Get every new post delivered to your Inbox.

Join 81 other followers

%d bloggers like this: