En parte, estoy de acuerdo con DW , la prevención es mayor que la detección pero solo cuando funciona. Una vez que su máquina se vea comprometida, se pateará por no tener implementados mecanismos de detección mejores (¡o ninguno!). En general, trato de dividir mi enfoque en ambos, y en algunos puntos la detección puede obtener un poco más de atención.
Alguien con su perfil de riesgo (propietario de una pequeña empresa con un proveedor de alojamiento compartido básico, etc.), generalmente no tiene la capacidad de gastar el tiempo, dinero y esfuerzo o hacer los cambios necesarios para invertir completamente en una solución de seguridad. Recomendaría un enfoque de 3 puntas que consiste en prevención , detección y recuperación .
Nota, esta no es una discusión exhaustiva sobre cada una de estas "puntas", sino que están aquí para poner en marcha sus pensamientos. ¡Me encantaría escuchar lo que decida implementar, junto con el de cualquier otra persona!
Prevention
No dedicaré mucho tiempo a la prevención, hay mucho que cubrir. D.W. señaló algunos puntos de partida en su publicación , y hay un montón de recursos en línea relacionados con la codificación segura. Le sugiero que comience con las guías de OWASP y Mozilla:
enlace
enlace
enlace
enlace
Detection
Algunos programas maliciosos modernos (y los intrusos) tienen la capacidad de enraizarse tan profundamente en las entrañas del sistema operativo de la víctima que la eliminación verificable parece imposible. Sin embargo, no sugeriría poner todos sus huevos en una canasta, por ejemplo, solo enfocándose en la prevención. Enfocarse solo en la prevención deja mucho espacio después del compromiso que podría haber estado reuniendo artefactos y pruebas.
Los entornos de alojamiento compartido no siempre son los mejores para su personalización en términos de lo que debe suceder para una iniciativa de seguridad, por lo que es muy dependiente del proveedor. (consulte ¿Cómo mantener seguro un servidor de alojamiento web compartido? )
Es probable que su incidente forme parte de un compromiso masivo, por ejemplo, la inyección de SQL de un sitio en su host compartido que lleve al compromiso del sistema operativo. Ese script luego busca * .php para inyectarse en. Una vez infectado, el gusano / atacante pasa al siguiente host (es). Si bien esto puede no ser exactamente lo que sucedió, es un caso común y demuestra un patrón de ataque común que no es un ataque sofisticado o una tarea imposible de detectar y limpiar.
Dependiendo de lo que se pueda implementar localmente, su mejor opción es utilizar un servicio de terceros que busque signos de infecciones, por ejemplo,
enlace
enlace
Otra opción es usar un script simple para comparar las sumas de comprobación de todos tus archivos y enviarte un correo electrónico cuando sea diferente. Luego, podría usar los ganchos de git para actualizar la configuración de su script con las sumas de verificación "buenas" actuales. También he tenido suerte con scripts simples como este para otras cosas, por ejemplo, verificación de certificados SSL, verificación de encabezados, etc.
Recuperación
Ahora que tiene instalado un mecanismo de detección, ¿qué sucede cuando recibe ese temido correo electrónico a las 3 am? Tener un proceso claro en el lugar reducirá en gran medida el tiempo de inactividad y los cabellos grises.
Como mencionó git en su pregunta, asumiré que usted es un usuario actual. Hay algunas publicaciones buenas sobre cómo usar Git para administrar un sitio web. Recomendaría utilizar un proceso similar al detallado en:
enlace
enlace
enlace
Recuerde, ese es solo su código, no necesariamente todos sus datos, por ejemplo, bases de datos y contenido cargado.