¿Es segura la programación de socket?

Voy a hacer un par de suposiciones sobre su servicio y luego daré algunas sugerencias.

Suposiciones

• El cliente (teléfono) inicia todas las conexiones a su servicio; y
• El servidor solo debe atender las solicitudes de su aplicación cliente.

Ahora aquí están mis sugerencias, y la razón detrás de ellas.

• ¿Es posible escuchar en un puerto específico usando sockets sin formato?
• ¿Cuál es una explicación fácil de las propiedades de las relaciones como reflexiva, irreflexiva, simétrica, asimétrica, antisimétrica y transitiva?
• ¿Es posible asignar IP flotante / IP virtual en OpenVZ / Virtuozzo para fines de alta disponibilidad?
• ¿Cuál sería la diferencia en los roles laborales entre la certificación CCNA / CCNP frente a un Máster en Redes de Computadores?
• ¿Por qué no se realiza la fragmentación en IPv6 como en IPv4?

• No use una dirección IP estática, use un nombre de dominio:
• Las direcciones IP estáticas son un muy buen vector de ataque;
• Lo atan a un proveedor de servicios específico muy estrechamente; y
• Siempre que tenga que cambiar la dirección IP, debe volver a lanzar su aplicación. No quieres tener que hacer esto. Asi que,
• Usa un nombre de dominio. Algo así como ” myapi.example.com ” o lo que sea. Su aplicación usará DNS para resolver eso a una IP e iniciar la conexión desde allí.
• Use un equilibrador de carga:
• Algo como ALB / ELB de Amazon o el equilibrador de carga de Google son muy fáciles de configurar y muy rentables de ejecutar;
• Permitirán que pueda ejecutar continuamente su servicio incluso durante una actualización (poner y quitar servidores del servicio); y
• Puede escalar su back-end si lo necesita, si termina teniendo muchos clientes legítimos, o si tiene que lidiar con un ataque DDoS que lo hace a través de las protecciones DDoS iniciales de Amazon / Google. Ver AWS re: Invent 2014 | (SEC307) Creación de una arquitectura resistente a DDoS con Amazon Web Services o similar.
• Esto no tiene que estar en “versión cero”, pero si lo planea, es fácil agregarlo más tarde.
• Usa criptografía:
• Como estará operando un servicio que está en Internet abierto, necesita un método para determinar el tráfico legítimo del ruido;
• También necesita saber si alguien ha manipulado los mensajes del cliente en tránsito; y
• También es posible que desee protegerse contra el espionaje (no sé qué tipo de servicio es, así que no sé si eso es importante para usted). Asi que,
• Use un secreto compartido y un algoritmo hash para crear una firma digital que pueda validar en el servidor, O use un certificado TLS de cliente que pueda bloquear toda comunicación a solo aquellos clientes que tengan el certificado
• NOTA: esto es un poco complicado, pero si configura su propia Autoridad de Certificación (CA) privada, no es tan difícil de hacer. También le permite hacer cosas como emitir un certificado diferente para cada versión de su aplicación, por lo que puede realizar un seguimiento de las versiones y / o controlar el acceso por versión (por ejemplo, “hay una falla en la versión X, revocar el certificado para X” dejando todos los demás certificados para funcionar sin saber que sucedió nada).
• No necesita comprar nada de nadie para poder hacer esto.
• Incluso si no está utilizando una CA privada, use TLS. Si no desea pagar un certificado, aprenda a usar Let’s Encrypt y consígalos gratis.
• Documente su API, incluso si no la va a hacer pública:
• Esto te permitirá validarlo;
• Esto te ayudará a probarlo; y
• Esto lo ayudará a cambiarlo cuando lo necesite.
• Validar todo:
• Incluso si haces todo lo anterior, aún no confíes en NADA que el cliente te envíe;
• Valide todos los parámetros de entrada contra su uso previsto, y no acepte nada fuera de eso;
• Escapar adecuadamente, etc., etc .; y
• Use el OWASP Top Ten, como mínimo, para fortalecer sus sistemas.
• Ponga la versión de su API en la URL de su solicitud en algún lugar:
• Algo así como ” https://myapi.example.com/v1.2/ ” o lo que sea;
• si no está utilizando una URL, coloque la versión en otro lugar
• Esto facilitará el mantenimiento de diferentes versiones de su API a medida que evoluciona; y
• Esto le permitirá servir diferentes versiones con diferentes servidores si es necesario (puede hacerlo con Apache o AWS ALB, etc.)
• Considere utilizar una capa adicional de cifrado entre usuarios para sus mensajes:
• ¿Quieres / necesitas poder leer sus mensajes?
• ¿Quieres / necesitas estar sujeto a algo como CALEA?
• ¿Le preocupa la exposición a metadatos de mensajes?

Los enchufes son solo un medio de comunicación. La confianza es algo completamente distinto.