Consideraciones:

EL sistema en cuestión es la base de un sistema SAAS, el problema principal son los escenarios cambiantes.

Para que una solución de antipcopia en PHP funcione, debe considerar factores que estan fuera de nuestro control:

1 ) La pc virtual debe tener salida a internet con latencia normal.
2 ) Por lo general los clientes usan configuraciones inseguras.
3 ) Si el cliente tiene el software instalado, deberia tener lso datos en su servidor pero este no es el caso. Parte de NUESTROS servicios son alojar sus datos. En la practica las soluciones simples son:

1 ) EN SAAS solo tener la instalación de nuestro servidor operativo.
2 ) Usar un hardcoded los datos del calificador.
3 ) En lo posible usar encoders para las licencias y archivos importantes
4 ) Hacer soluciones simples con factor de supervivencia.
5 ) Si usamos soluciones del cliente, hostearlo en nuestro propio server. Un server es tan bueno como su admin, y la mayoría de clientes o no tienen admin de servers o estan perdidos en el espacio.

El principal problema que veo en toda este ejemplo, es el escenario. En la práctica la licencia podría derivar de un numero de serie / macaddress, y en la practica no muchos clientes tienen pc virtuales.

Es posible el modelo actual, y es sostenible. Sin embargo, mi sugerencia sería POR RENDIMIENTO tener tanto la palabra viva, como las pc virtuales bloqueadas, en el calificador. Es mucho mas rapido leer:

function palabraviva($numcliente){
if ($numcliente==1) return «silla»;
if ($numcliente==2) return «mesa»;
if ($numcliente==3) return «cuaderno»;
} // palabra viva

A la larga, el problema final es la tendencia de las empresas a matar moscas a cañonazos.

En un caso de seguridad mayor, como el exigido en lo relacionado con la vida humana (software para hospitales), pondría incluso una funcion que enviara correo al administrador por calificadores erroneos. En el caso de un sistema de alto rendimiento, quizá haría un cachè en variables de sesión.

Es un principio, y funcional.

AHora nos encontramos con los problemas del calificador. El calificador es el archivo que estará en el servidor, y que es llamado por el validador del ejempl oanterior, en la dirección https. Este archivo debe ir en el servidor.

Basicamente podemos complicar la cosa creando una tabla de PC virtuales. En este ejemplo banneo las virtuales 80 y 666, se supone que no son muchas las que se van a bannear y automatizar el proceso sería confuso para los fines de ejemplo.

Los mensajes de error no corresponden a una descripción detallada, para que un «cracker» de código no sepa que le salió mal. Sin embargo el hecho que las maquinas virtuales usen redes locales, impide usar una ip anti proxyes como la función que puse.

http://www.alfonsoorozcoaguilar.com/codigo/calificador.txt

Lo siguiente es el Solicitador de Licencia.

Este archivo debe ir en la pc cliente.

Idealmente el archivo deberia ir encriptado.

Estamos obligados a pasar por parametro la direccion ip del cliente porque quizá esta en un proxy o een una red local tipo
192.*
127.*
10.*

Asi que el antiproxie no funciona si validamos de manera compleja.

http://alfonsoorozcoaguilar.com/codigo/validadorcliente.txt

Añado un ejemplo de licencia a la que altere para no dar datos validos propios:
http://alfonsoorozcoaguilar.com/codigo/Licencia_11_17.txt

El proceso de validación del password necesita varias etapas. Por simplicidad los manejaré en estos blogs como archivo aparte. La parte generador de licencia necesita usar headers, asi que se complica el ponerlo dentro de un script mayor. Por eso, lo pongo en archivo aparte, por simplicidad en la explicación.

Entonces, necesitamos tres archivos:

1 ) Generador de licencia, que genera el .php verificando primero enlazandose a la tabla de datos de clientes y que estemos conectados a un script global. Actualiza la palabra viva en servidor.

2 ) Solicitador de Licencia , que irá en la PC virtual. Si la ip no cuadra, o el resultado es diferente, impide el acceso al aplicativo.

3 ) Calificador de Licencia. Archivo que va en el servidor, y que idealmente debe guardar ip fecha y hora de quien solicita la validación. Por simplicidad no guardo bitácora en el ejemplo.

Requisitos entonces:

1 ) Tanto PC Virtual como servidor, deben tener habilitado curl
2 ) Preferentemente el servidor debe tener HTTPS para reducir riesgo de DNS poisoning
3 ) Enlace con internet de parte del cliente, para validar que el sistema tenga palabra viva.

Se asume por obvio:
1 ) Debe adaptarse el script para enlace a base de datos.
2 ) La variable de sesion variable, en el generador debe ser valids en el proyecto general. Si se omite no hay problema pero es inseguro.
3 ) Debe modificarse la tabla de clientes para añadir un campo llamado Palabra Viva
4 ) Debe definirse en PC virtual el numero de maquina virtual por un define
5 ) Debe llamarse al validador desde el aplicativo de la pc virtual.
6 ) Los paths absolutos deben modificarse. El dominio example.com es un ejemplo.
7 ) El archivo debe tener extension php-
==============================================
Al terminar la serie comentaré las posibles mejoras que pueden hacerse.

Puedes descargar aqui el generador de licencia.
http://www.alfonsoorozcoaguilar.com/codigo/generador.txt

Aunque hace unos diez años escribí sobre como evitar copias no autorizadas de software hecho en Visual Basic – Clipper, no me había visto en la necesidad de evitar de manera compleja que un software php corriera en máquinas virtuales.

Lo tipico en php, para mi, es hacer una verificacion dura sobre la direccion IP Suponiendo sin conceder que tenemos una función llamada md5_Ip, es tan facil como una linea:

if (md5_ip()<>«md5guardado») Die(«Copia no autorizada para este dominio»);

Este enfoque tiene dos problemas. El primero es que una alteración de los archivos hosts puede convencer de que del dominio está en otro lugar y es otra cosa. El segundo problema es que una copia puede dejar de ser autorizada por la acción del simple transcurso del tiempo. En un sistema que hice hace años, recuerdo que tuve que poner la facilidad para desactivar remotamente el acceso de una PC a cierto sitio web, por casos de robo.

Asi que nos enfrentamos a una situación similar . Ayer me pidieron pensar en un mecanismo de protección de copia no autorizada en una MAQUINA VIRTUAL GENERICA, misma que TODOS los clientes de cierto tipo usan. Asi que, la dirección Mac address es la misma, el numero de serie es el mismo, y vamos a suponer que no podemos cambiar con una utilería el numero de serie del disco duro de la maquina virtual, tanto en caso de clientes que no paguen como en el caso de robo de equipos.

Hay otras dos complicaciones. Algunos clientes tienen varias sucursales, aunque cada sucursal tiene una y solo una PC por razon social, algunas sucursales manejan 3 numeros de cliente por sus diferentes razones sociales, y a su vez una razón social puede tener varias sucursales.

Los unicos datos «estables» que se tienen entonces, es el NUMERO de la razon social (que para otros casos practicos podría ser su CURP o su RFC o numero de contrato), pero dicho valor se va a repetir.

Tampoco podemos usar como llave el numero de direccion ip ni la puerta de enlace. Si es una empresa competente con sucursales, probablemente todas las sucrsales tengan su propia red local con el mismo numero de Gateway , y la misma direccion ip.

Ademas el software de las maquinas virtuales, debe conectarse con nuestro server FORZOSAMENTE o no pueden disfrutar de lo que les interesa del servicio.

Entonces, nos encontramos ante un problema extraño. Necesitamos poder bloquear una instalación en casos de SaaS (software as service), para clientes cautivos, y poder cortar el servicio además de copias pirata. Debido a que no hay acceso fisico ni virtual a las PC, excepto en la implementación y actualizaciones prioritarias, nuestro esquema no puede estar basado en candados de hardware, y al ser igual el hardware por ser maquinas virtuales, si no queremos modificar la MAC address o la serie del disco duro, nos quedan pocas alternativas.

a )Cambiar numro de serie disco duro, o Mac Address. Es impractico y no funciona en el caso de varias razones sociales en la misma pc
b ) Numero de serie de activación, por unica vez. No sirve para desactivar de manera inmediata ni previene copias no autorizadas.
c ) Numero de serie de activación, por mes con mes. No sirve para desactivar de manera inmediata, pero limita el daño.
d ) Archivo de configuración en la PC que use validación por palabra viva .

El punto a no es práctico, el b y c no resuelven el problema, así que se necesita una interface de la PC virtual con nuestro server.

Punto 1:
* Instalar Https en el server del dominio. Esto es prioritario para reducir posibilidades de alteración por DNS poisoning ( http://es.wikipedia.org/wiki/DNS_cache_poisoning )
Punto 2: Disminuir todo lo posible que sea el TTL del dominio.Manejando un TTL bajo, u uno alto se evitan ciertos problemas pero no puede coexistir. bajo y alto en TTL (time to live). Mi enfoque sería un TTL Alto http://www.google.com/#hl=es&xhr=t&q=ttl+domain&cp=10&pf=p&sclient=psy&aq=f&aqi=&aql=&oq=ttl+domain&pbx=1&fp=b85a9cc57c1f0455

Punto 3: Utilizar un archivo generado en instalación de Pc Virtual.
El archivo podría llamarse licencia_clavecliente_numeromaquinavirtual.php y debería contener información que identifique esa razon social y esa maquina virtual. Si de entrada ya estamos configurando logotipos y otras cosas cliente por cliente, editar un archivo mas por cliente antes de bajarlo, no tiene problema. Podemos tener equis numero de licencias, y podemos parar una sin problemas.

Punto 4: El archivo en cuestión tiene que usar una clave de hash no reversible y de contenido conocido para evitar modificación. Es decir, aunque hay sitios especializados en calcular colisiones de palabras que den un hash / sha / md5 y encontrar equivalentes, debemos conocer parte de la clave, asi que si tratan de reemplazarlo, debemos poder hacerlo con un valor que solo nosotros conocemos, y esa es la palabra viva.

Idea:
Vamos a suponer que la palabra viva del cliente uno es «silla», del cliente dos es «mesa» y del cliente tres «cuaderno» (en la practica) la palabra viva no debe ser del mismo tipo, por ejemplo que en una sera españa y en otro argentina, nos hace saber que la palabra viva es pais, lo cual no debe ser.

Sabemos entonces por http://md5-hash-online.waraxe.us/ o md5() que estos son los has de la palabra viva:

silla = 86aa0eab194b5fe69e3c1706b4c041d9
mesa = 85770ae9def3473f559e0dbe0609060a
cuaderno = bf1199db079512f58adad8caa049cef1

Asi que nuestro archivo debe guardar una cadena de textos de tres diferentes hash (prefiero independientes porque así deberían romperse tres y no uno )

Entonces un hipotetico licencia.php sería así:

< ?php define("LICENCIA","86aa0eab194b5fe69e3c1706b4c041d9"); // clave silla ?>

Pero el archivo puede llevarse a otras pc.

Para la situación particular ne que me encuentro, estos son los tres factores que usaré.

1 ) Dirección IP de la PC virtual.
2 ) Numero de cliente mas numero de contrato con nosotros, formato cadena.
3 ) Palabra viva.
La palabra viva se genera al generar el archivo.
Así que, suponiendo que la ip de silla sea: 127.0.0.1, y el cliente mas contrato 008_95,

Calcularemos Hash de dos factores:
1 ) hash de «silla127.0.0.1» = 8fc0ba017f02eaf1b12022798162cc87
2 ) hash de «silla008_95» = d661c0239340663258ced49954b50879

Asi que mi archivo de licencia, que se instalaría al generar la pc virtual numero 17 del cliente 15 es :

licencia_15_17.php
< ? Define ("licencia","8fc0ba017f02eaf1b12022798162cc87d661c0239340663258ced49954b50879"); ?>

Y la verificación de la cadena se puede hacer llamando al servidor por un

function validalicencia(){
$status=file_get_contents(«http://example.com/validate.php?mv=15_17&licencia=8fc0ba017f02eaf1b12022798162cc87d661c0239340663258ced49954b50879»);
return $status;
}

El archivo puede entonces ver base de datos, y si la licencia cambia con la palabra viva, solamente necesitas verificar así:

if ($validalicencia<>«OK») Die («Licencia expirada»);

Asi que , cambiando la palabra viva en nuestro validate.php del servidor, efectivamente deshabilitamos cliente de SaaS, por razón social especifica, sucursal especifica, dejando activas otras.

En la practica yo usaría un hash5 del numero de serie del disco duro o de la fecha de instalación de /home o C:windows, pero al ser PC virtual no se puede.