Estoy alimentando el sitio web de un banco usando WordPress. ¿Qué medidas de seguridad debo tomar?

De acuerdo, la mayoría de las respuestas aquí son inherentemente incorrectas o incompletas por varias razones. Abordemos eso con algunos datos de investigación y lluvia de ideas en cuenta.

A. ¿Qué es el sitio web de un banco?

En primer lugar, “impulsar el sitio web de un banco” es bastante vago. Hemos estado creando soluciones de WordPress para 3 bancos diferentes en los últimos 5 años. Las tres plataformas en particular fueron:

1. Un portal informativo para el banco A, principalmente adecuado para noticias de la compañía, que enumera las sucursales del banco, todo tipo de información corporativa. También hemos creado una calculadora financiera para créditos: un sistema complejo que replica los montos de procesamiento de la aplicación de software, el interés a lo largo del tiempo y algunos algoritmos de aprendizaje automático para evaluar el riesgo.
2. Una plataforma de pasarela de pago para proveedores de terceros, incluida la extensión de WordPress también. Ese era un sitio web separado (pero con la marca y mantenido por el banco) para integraciones.
3. Un conjunto de módulos de seguridad y complementos y herramientas de privacidad para otro banco integrado con una plataforma de informes. Agregando extractos de tarjetas de crédito y todo tipo de detalles impulsados ​​por el usuario relacionados con el estado de pago de uno. De hecho, se proporcionó información de datos monetarios y confidenciales, aunque el procesamiento de pagos no estaba activo en el sistema (envío de transferencias a través de otras cuentas).

Dos de las tres aplicaciones no estaban relacionadas remotamente con el sistema de pago principal que los bancos usaban para la banca electrónica. El tercero fue el más cercano, ya que fue auditado a fondo por el escuadrón de pruebas de penetración de red interna de Verizon y algunas otras organizaciones de piratería blanca de alto perfil (aprobadas con éxito).

Como conclusión, no todos los sitios web de los bancos manejan pagos o datos confidenciales.

B. Informe de vulnerabilidades de seguridad bancaria

Una de las fuentes más acreditadas con respecto a las vulnerabilidades de seguridad comunes es la Categoría: OWASP Top Ten Project. Según el informe de 2013, aquí hay una lista de las principales vulnerabilidades en línea:

Un estudio de SC Magazine de noviembre de 2013 destaca los principales ataques a sitios en los bancos más grandes del mundo:

Una empresa suiza de pruebas de penetración, High-Tech Bridge, analizó incidentes reportados públicamente que afectan a los principales sitios web de los bancos, y descubrió que, en los últimos 10 años, las vulnerabilidades de scripting entre sitios (XSS) representaron el 80 por ciento de los incidentes de seguridad.

Un método de ataque XSS común podría involucrar a un pirata informático que usa inyecciones de código para robar datos de los visitantes, como cookies, o manipula lo que las víctimas ven para engañarlos e ingresar información personal o financiera confidencial.

En el experimento, High-Tech Bridge utilizó una lista de los 50 “bancos más grandes” del mundo en 2012 (según lo determinado por la revista Global Finance) y desenterró informes de ataques públicos publicados en sitios de seguridad y piratería o archivos en línea para ataques XSS y desfiguraciones de sitios. .

Las instituciones financieras en la lista incluyeron Bank of America, HSBC, Barclays, JPMorgan Chase, Wells Fargo, Bank of Montreal y varios otros bancos importantes en todo el mundo.

De 102 incidentes reportados, ocurridos entre 2003 y el presente, High-Tech Bridge descubrió que Bank of America tenía la mayoría de los informes públicos de problemas de seguridad que afectaban su sitio.

Como conclusión, podemos esbozar dos notas separadas:

1. Parece que los sitios web que no son de WordPress son tan susceptibles a los ataques web como los de WordPress (si no más)
2. El 80% de todos los incidentes de seguridad son impulsados ​​por XSS

El documento oficial de seguridad de WordPress destaca la lista de OWASP y las principales categorías de vulnerabilidad de la industria cuando se trata de revisar la base de código existente e introducir nuevas características en curso en el núcleo de WordPress.

XSS tiene un lugar especial en el documento con algunos ejemplos prácticos de lo que el equipo de seguridad de WordPress (y otros consultores de seguridad independientes) buscan con respecto a XSS:

WordPress proporciona una variedad de funciones que pueden ayudar a garantizar que los datos proporcionados por el usuario estén seguros. Los usuarios de confianza, es decir, los administradores y editores en una sola instalación de WordPress, y los administradores del sitio solo en WordPress Multisite, pueden publicar HTML o JavaScript sin filtrar según lo necesiten, como dentro de una publicación o página. Los usuarios no confiables y el contenido enviado por los usuarios se filtra de manera predeterminada para eliminar entidades peligrosas, utilizando la biblioteca KSES a través de la función wp_kses .

Como ejemplo, el equipo central de WordPress notó antes del lanzamiento de WordPress 2.3 que la función the_search_query() estaba siendo mal utilizada por la mayoría de los autores de temas, que no escapaban de la salida de la función para usarla en HTML. En un caso muy raro de compatibilidad con versiones anteriores que se rompe ligeramente, la salida de la función se modificó en WordPress 2.3 para que se escapara previamente.

La naturaleza de código abierto del proyecto respalda esas necesidades, dado que decenas de miles de contribuyentes, investigadores y desarrolladores que usan WordPress para decenas de millones de proyectos, en diferentes aplicaciones, pueden replicar un problema en un contexto diferente, de manera fácil y fácil. identificar rápidamente posibles problemas.

En comparación con el sistema corporativo y de código cerrado, recordaré la vulnerabilidad de BadTunnel descubierta en 2016 que ” podría dar a los atacantes una forma de organizar ataques de intermediarios contra las víctimas haciendo que hagan clic en un enlace, abran un Documento de Microsoft Office o conecte una unidad USB “y” puede exponerlo a atacantes que no están en su red, y sus firewalls no lo salvarán “. Para el registro, esta vulnerabilidad afectó a todas las versiones de Windows de 95 a 10 , o alrededor de 20 años de sistema de producción vulnerable que se ejecuta en empresas e intranets corporativas con acceso remoto explotable por los sombreros negros.

Ahí va la teoría de la “fuente cerrada”, al menos en cierta medida.

Otro estudio de 2016 cubre algunos datos sobre dónde los bancos son más vulnerables a los ataques cibernéticos ahora:

Dicho esto, investiguemos qué hace que las aplicaciones web sean más vulnerables a los ataques.

Los bancos están siendo los más afectados en sus aplicaciones web. Según el informe de Verizon, el 48% de los incidentes de seguridad de datos bancarios en 2015 involucraron aplicaciones web comprometidas.

Algunas aplicaciones se ven comprometidas a través de inyecciones de código. El malware GozNym, por ejemplo, generalmente inserta código en los sitios web de los bancos que crea pantallas emergentes que solicitan información personal. A través de la inyección SQL, el malware puede acceder a información confidencial en bases de datos u obtener acceso a otras partes de una red a través de una aplicación web.

Los ataques a aplicaciones web son difíciles de detectar ya que los bancos tienen miles, a veces millones de usuarios legítimos que acceden a sus sitios. Encontrar el mal comportamiento en el ruido es difícil, especialmente si los ciberdelincuentes usan múltiples servidores proxy y espacian sus ataques durante minutos o días.

¿La mejor defensa? Autenticación de dos factores, dijo Novak. “Todavía vemos que muchas instituciones financieras usan un nombre de usuario y contraseña de un solo factor”, dijo. Según el informe, el 63% de las violaciones de datos confirmadas en 2015 involucraron contraseñas débiles, predeterminadas o robadas.

Como Matt Mullenweg (cofundador de WordPress) se dijo en una respuesta aquí, ejecutar un software actualizado y usar contraseñas seguras es absolutamente crítico. Además, la autenticación de 2 factores también se mencionó en su respuesta, incluidos varios sistemas diferentes, incluido el componente 2FA de Jetpack que también se ha probado exhaustivamente en WordPress.com, el séptimo sitio web de mayor clasificación en los EE. UU. Ahora, entre gigantes como Google , Amazon, Facebook, eBay o Wikipedia.

C. ¿Qué hace que un sitio de WordPress sea vulnerable?

Un error común es que WordPress es inherentemente inseguro. Si bien se descubren vulnerabilidades regulares y se corrigen inmediatamente en el núcleo, su número, regularidad e impacto es significativamente menor (dada su exposición) que casi cualquier otra plataforma web existente.

Las cuatro razones principales por las que los sitios web de WordPress están siendo pirateados son:

1. WordPress Core obsoleto y los temas / complementos correspondientes
2. Temas o complementos inseguros (instalados voluntariamente por los propietarios de sitios web)
3. Alojamiento intrínsecamente inseguro (que es independiente de la plataforma ya que los usuarios malintencionados pueden obtener acceso a cualquier software en línea que se ejecute en un host genérico)
4. Contraseñas deficientes, registro desde una red Wi-Fi abierta u otro error impulsado por el usuario no relacionado con la tecnología

Casi no hay motivos para explicar por qué WordPress es inherentemente inseguro para el sitio web de un banco. Por supuesto, el procesamiento de transacciones de pago a través de una plataforma de WordPress puede no ser ideal. Muchas plataformas transaccionales ni siquiera están construidas sobre una plataforma web, y se ejecutan en C ++, Java u otro lenguaje que admite subprocesos múltiples, introduce varias capas de seguridad intermedias y pasa datos a una aplicación web utilizada para interactuar con el usuario final.

Si bien hay vulnerabilidades que se pueden señalar en WordPress Core que, de hecho, pueden explotarse en un sistema obsoleto, no ha habido una investigación exhaustiva y exhaustiva que compare una compilación de WordPress Core con otro marco o plataforma de aplicación web. Confiar en la información pública de los medios de comunicación con respecto a los propietarios de pequeñas empresas que ejecutan un sitio desactualizado en un proveedor de alojamiento web de $ 3 / mes con más de 60 complementos aleatorios no es un informe exhaustivo sobre la estabilidad de la plataforma WordPress que se ejecuta en un contexto seguro.

Como conclusión, WordPress puede no ser la mejor solución para un sitio web bancario (por otras razones, como la capa de base de datos subyacente o los componentes estándar proporcionados por el Core en ciertos casos), pero no hay una razón objetiva por la que deba descartarse en todos los casos.

Sucuri es una empresa de renombre que ofrece una gran seguridad en Internet, como soluciones de firewall y antivirus para todo tipo de propietarios de sitios web.

El software le brinda una amplia gama de medidas y herramientas preventivas: si está registrado con Sucuri, está a salvo de ataques de fuerza bruta, vulnerabilidades de software y script y también eventos de día cero.

En mi trabajo anterior, he usado este complemento para el sitio de WordPress de varios clientes y noté lo bien que están, por lo tanto, recomendaría encarecidamente el servicio Sucuri CloudProxy.

Los 5 puntos más importantes de Sucuri

1. Bloquea todos los ataques

Es muy bueno escuchar que antes de afectar a su servidor, este firewall de complemento ayudaría a bloquear todos los ataques.

Son una de las compañías de seguridad más exitosas, siempre investigan e informan al equipo central de WordPress y a otros complementos de terceros con respecto a posibles problemas de seguridad.

Recientemente, su equipo está solucionando los problemas de seguridad con la ayuda de los respectivos desarrolladores.

2. Monitoreo de integridad del sitio web

El escáner Sucuri le está entregando el paquete Sucuri 2-in-1 Website AntiVirus.

En cada 3 horas, monitorea su sitio y también se asegura de que su sitio esté a salvo de malware, inyecciones de enlaces maliciosos, spam, etc.

El otro trabajo del escáner es verificar que ninguno de los servicios populares como Google, Norton, AVG, Phishtank, Opera y otros no puedan incluir su sitio en la lista negra.

3. Registro de auditoría del sitio

Todo en su sitio se mantiene seguro mediante el seguimiento de todo con el complemento WordPress de Sucuri.

Aquí todo estará alerta para usted, como cambios de archivos, nuevas publicaciones, nuevos usuarios, últimos inicios de sesión, intentos fallidos de inicio de sesión y más.

4. Escaneo del lado del servidor

Si sus usuarios infectan con malware, los hackers no se preocupan.

Tal vez su objetivo es simplemente agregar anuncios de banner en su publicación anterior / puede reemplazar sus enlaces de afiliado.

Es muy difícil atrapar este tipo de hacks porque no son obvios y no estás en la lista negra para este tipo de hacks.

En este momento, el escaneo del lado del servidor es fácil de usar.

Este escáner del lado del servidor del complemento puede revisar cada uno de los archivos individuales (incluso archivos que no son Wp) y le asegurará que no haya nada sospechoso / dañino en su servidor.

Sucuri también audita eventos que incluyen cambios de archivos y le informa según sus necesidades.

5. Servicio de limpieza de malware

Incluso todas las razones anteriores son suficientes para justificar el costo, puede obtener el servicio de limpieza de malware con páginas ilimitadas si tiene la eliminación de la lista negra.

Todavía no tenemos la oportunidad de usar esta parte del servicio, pero ¿te imaginas que si tienes expertos en seguridad limpiará tu sitio?

Si desea consultar con expertos en seguridad, en promedio le cobrará $ 250 / hora.

Que los expertos en seguridad consulten bastante caro pero Sucuri tiene una opción adicional para asegurar su sitio que no será pirateado.

Construir un sistema que tenga acceso a las cuentas bancarias de los clientes sobre WordPress es una idea espectacularmente mala.

Por favor no hagas eso. Ciertamente, puede ejecutar el blog del banco en un sistema físicamente separado, pero cualquier cosa que toque los inicios de sesión de los clientes no debe construirse en esa plataforma.

WordPress consta de:

• Núcleo
• Tema
• Complementos

Si bien la seguridad del núcleo recibe mucha atención, eso no es suficiente. Es tan grande y tan fácil de extender incorrectamente que a los atacantes les encanta explotarlo.

La mayoría de los sitios de WordPress también usan un tema y complementos de WordPress. Lo que la mayoría de la gente no se da cuenta es que el tema siempre contiene código PHP y no solo el estilo de presentación. No se presta suficiente atención a la seguridad del tema con pocas excepciones.

Los complementos de WordPress también reciben atención insuficiente para la seguridad con pocas excepciones.

Como resultado, un atacante puede y hará huellas digitales y explotará sus temas y complementos.

Si no desea usar temas y complementos, entonces no tiene ninguna razón para usar WordPress y puede elegir un marco conocido por su seguridad.

Escribir el acceso a la cuenta bancaria como complementos de WordPress no tiene sentido.

Solo no lo hagas.

No puede arriesgarse a que el sitio web de un banco ejecute WordPress incluso para la parte de front-end. Hace solo un par de días, se descubrió que la instalación predeterminada de WordPress tenía una vulnerabilidad XSS (Cross Site Scripting) que dejaba a millones de sitios web vulnerables. Esta no es la primera vez que sucede algo así con WordPress y esta no es la última.

Otra noticia reciente de principios de este año es Blind SQLi en el plugin ‘SEO for Yoast’. ¿Qué sucede si hay un SQLi en uno de los sitios web del banco de complementos que está utilizando? En combinación con algo como la falla reciente de XSS, los piratas informáticos podrán eliminar el sitio. Incluso si piratean el front-end del sitio, las consecuencias para el sitio web de un banco pueden ser realmente malas. Porque eso conducirá a la pérdida de reputación y confianza de los clientes. ¿No es eso algo en lo que los bancos confían más?

Lo anterior son vulnerabilidades de las que se apoderó el equipo de WordPress. Hay una cantidad de 0 días flotando en mercados subterráneos que mucha gente desconoce, que también podrían usarse para comprometer el sitio de un banco.

Durante el desarrollo, si tiene alguna pregunta sobre seguridad, envíela a [correo electrónico protegido] . Pero por favor no escriba código que no sea seguro.

Fuentes:
http://wptavern.com/xss-vulnerab …

http://wptavern.com/xss-vulnerab …

Mis 2 centavos

Por mucho que me encanta WordPress, el único consejo sensato aquí es hacer que la instalación de WP sea completamente independiente de la parte bancaria real de la funcionalidad.

En breve:

Esto significa que solo debe usar WordPress para el sitio de información / noticias / blog del banco. Si hay alguna funcionalidad de banca en línea, debería ejecutarse en otra cosa y solo estar vinculada desde el sitio WP.

Además, el mantenimiento del sitio de WP es crucial. Debe asegurarse de que las cosas (núcleo, complementos, tema) estén siempre actualizadas y a salvo de vulnerabilidades comunes.

Por ejemplo, aquí hay una lista de cosas que debe hacer regularmente con cualquier sitio de WP en términos de mantenimiento: http://www.codeinwp.com/blog/off …

Hay algunos pasos que puede seguir para aumentar la seguridad de su sitio web de WordPress.

1. Asegúrese de estar utilizando la última versión de WordPress.
2. Desactive la función de edición de archivos PHP desde el Panel de WordPress.
3. Habilite la autenticación de dos factores
4. Desactive el inicio de sesión en el tablero para sus clientes / suscriptores
5. Si es posible, cambie la URL de inicio de sesión del Tablero, de forma predeterminada es http://www.yoursite.xxx/wp-admin cámbiela por otra. Hay varios complementos de WordPress disponibles para esta tarea.
6. Hospede su sitio en servidores dedicados que brinden protección DDOS.
7. Restrinja el número de intentos de inicio de sesión para un usuario en particular.
8. Almacene el archivo wp-config.php un nivel por encima de la instalación de WordPress
9. Establezca los permisos de carpeta correctos.
10. Elija temas de terceros, complementos sabiamente desde el punto de vista de la seguridad y también asegúrese de auditar cada uno de ellos antes de la instalación.

Leer más:
Seguridad de WordPress | Blog de Sucuri
Endurecimiento de WordPress
Tutorial de seguridad de WordPress – Cómo asegurar WordPress
Cambio de permisos de archivo
Permisos de directorio y archivo

Nota: no se recomienda ejecutar el sitio web de un banco en WordPress.

Si debe ejecutar el front-end de marketing (solo) de un banco en WordPress; de lo contrario, probablemente seas un troll bromeando 😉 Aconsejaría lo siguiente:
1. No proporcione ningún enlace de inicio de sesión de WordPress en el front-end.
2. Elimine todos los fragmentos de código, metainformación, etc. que se refieren a WordPress.
3. Mueva `wp-content` y` plugins` a sus propias carpetas personalizadas. Y mantenga el `/ wordpress /` y `/ wp-admin /` en carpetas completamente separadas aisladas de sus rutas de acceso. Cambie el nombre de ambos a otra cosa y restrinja el acceso a esas carpetas.
4. Elimine toda la identificación del tema de WP para que sea un tema de WordPress.
5. Evite usar cualquier complemento que revelaría ser plugins de WordPress a través de sus salidas frontales, o alterar su fuente de tal manera que no puedan asociarse con WordPress.
5. Stringreplace () su salida renderizada en búfer de todas las clases predeterminadas de CSS WP a nombres de clase personalizados, y creó un tema con nombres de clase alterados para todo.

En resumen, nadie, o ningún bot, debería poder saber o sospechar fácilmente que su sitio se ejecuta en la plataforma WordPress. Los pasos anteriores son más o menos lo que se necesita para que eso suceda.

Y sí, verifique el sitio Gateway Bank of Mesa, pero como el ejemplo perfecto de total falta de seguridad para evitar a toda costa, no como modelo. Porque su backend es completamente inseguro. Su inicio de sesión en http://gcbaz.com/wp-login.php está expuesto y ni siquiera está protegido por SSL. Entonces agregaré lo obvio.

Como mínimo estricto, asegure su inicio de sesión de administrador utilizando SSL por el amor de Dios. Cualquiera que intercepte un inicio de sesión de contraseña de texto sin formato puede obtener acceso de administrador a WordPress y redirigir esos enlaces de inicio de sesión bancarios reales a un sitio de phishing.

Soy un evangelista de WP y el 99% del tiempo y creo que es factible con WP . Sin embargo, segundo Leonid S. Knyshov. No porque WP sea malo inherentemente, sino porque si estás preguntando cómo hacer eso aquí, en Quora, probablemente no tienes los recursos para hacerlo bien sin importar qué respuesta te demos.

Si solo está construyendo el sitio corporativo frontal para el banco, entonces hágalo. Siga todas las prácticas de seguridad estándar. Bloquee áreas de administración, nombres de usuario y contraseñas seguras, instale certificados SSL y minimice el uso de complementos. NO coloque datos de clientes o acceso de clientes aquí. El sitio también debe ser atendido físicamente desde fuera de la red del banco; no debe estar en el mismo servidor o red interna que cualquiera de los sistemas del otro banco.

Un buen lugar para comenzar es revisando la documentación y los servicios de estos tipos: Sucuri Security

Los sitios financieros y de salud son muy sensibles e independientemente de la plataforma, necesitan un equipo de personas para ejecutarlos correctamente.

¿Puedes hacerlo con WordPress? Claro, pero realmente necesita involucrar a un desarrollador fuerte orientado a la seguridad, o al equipo de desarrolladores, junto con la parte de seguridad de la red del negocio, y el negocio para participar en esto.

Hola, como ex director de operaciones de banca en línea, hice una prueba de concepto muy exitosa usando WordPress para los sitios web públicos. Me fui antes de que se tomara la decisión final, pero la Prueba de concepto demostró sin lugar a dudas que WordPress se puede hacer altamente seguro si trabajas con las personas adecuadas (en este caso, un equipo holandés, Forsite Media, chicos brillantes).

Las decisiones de diseño más importantes fueron:
– Para cortafuegos de la sección wp-admin, esencialmente desacoplarlo del front-end. Esto reduce significativamente la superficie de ataque de WordPress. Simplemente ya no puede comunicarse con el administrador de wp desde el front-end. No es un enfoque muy conocido / publicitado, pero se puede lograr sin desviarse del núcleo de WordPress, por lo que las actualizaciones no requieren un manejo especial
-Para tener todo el código y contenido en repositorios git. De esta manera, puede tener un proceso muy controlado para la entrega de software con un enfoque DTAP. También obtienes un proceso único y robusto para la administración de contenido que permite un enfoque por etapas en la publicación de contenido y te permite mostrar el sitio en cualquier momento, lo cual es un requisito de los reguladores

Tuve varias pruebas de penetración llevadas a cabo por líderes en el campo, numerosos escaneos de Qualys y la instalación se realizó con gran éxito.

Todos los demás consejos son sólidos, pero si trata con personas de seguridad de nivel empresarial, las dos declaraciones anteriores aliviarán gran parte del FUD que es probable que encuentre.

Espero que esto ayude.

Creo que la pregunta es: “¿Qué medidas de seguridad debo tomar?”.

1. Averigua qué banco
2. Cerrar mi cuenta
3. Restablecer todas mis contraseñas

WordPress es una excelente herramienta de blogging lamentablemente inadecuada para administrar un banco.

Supongo que por sitio web quieres decir realmente sitio web, no un sitio de banca por Internet. En ese caso, estos escenarios existen en otros lugares. En primer lugar, debería haber algunas personas con una comprensión real de la seguridad informática. Deberías hablar con ellos. Debe dividir estrictamente el entorno de banca por Internet y el entorno de su sitio web (diferentes redes). Una definición de “seguridad” es que la cosa no se puede utilizar para otro fin que no sea para el que fue diseñada y que no se puede limitar su funcionalidad sin autorización (como un ataque de DOS).
En general, esto significa que debe filtrar a las personas que desean sobrecargar el sitio y que desea no permitir los cambios no autorizados y debe poder detectar todos los cambios. Debe estar en https (obvio) con un certificado válido, detrás del firewall, debe tener pruebas de seguridad automatizadas, debe controlar el tráfico de red y debe controlar el sistema (estar actualizado, registrar tanto los cambios del sistema como los cambios de la base de datos en algunos otro sistema). Haga el sistema de archivos de solo lectura si es posible y limite los derechos del usuario bajo el cual se ejecuta la presentación web. Recorte todo lo que no necesita (complementos, etc.). Tenga procedimientos para cualquier cambio (grupo limitado de personas, una forma de actualizar las cosas, registrar todo).
Haga todo esto en coordinación con los expertos en seguridad, hay muchos detalles y le llevará años saberlo mejor que ellos.

Entonces, WordPress es una plataforma de publicación … tenerlo en el espacio bancario en línea como proveedor de contenido, pero no lo use para la banca transaccional, eso es una tontería.

Dicho esto, llevar su instalación de WordPress a la calidad empresarial (y perdóname por repasar temas similares)

Necesitará algo como CloudFlare o defensa DDoS que pueda eliminar ataques comunes como SQLI, RFI, LFI, XXE, XXS, CSRF (¿no sabe de qué estoy hablando? Mire aquí @Categoría: OWASP Top Ten Project) y DoS, DDos, es bueno para el almacenamiento en caché y el firewall de aplicaciones web, asegúrese de tener a alguien que sepa cómo interpretar la información que le brinda el gran Internet malo, de dónde provienen las mayores amenazas, lo que parece ser la automatización y lo que parece ataques bien colocados? eso aliviará mucha presión, la revisión del código (no por los tipos que lo escribieron) la lista de IP Firewall está bien, pero aún así serás víctima de ataques CSRF bien ubicados, ya que son ejecutados por la persona que ya tiene acceso a los paneles de administración , HTTPS (obviamente), pero eso solo le dará privacidad de conexión, no lo que pasa por la conexión dentro o fuera. 2FA es excelente para detener la fuerza bruta automatizada de wp-admin pero, de nuevo, si alguien roba su cookie una vez que se haya autenticado … tendrá un mal día. … suponga que va a tener un mal día. obtenga un registro de eventos ajustado por su equipo de SoC que sepa cómo se ven las infracciones o un probador de penetración / consultor de seguridad, asegúrese de que su sitio no transaccional esté cerca de cualquier sistema transaccional real … en caso de que WordPress sea golpeado por un día 0 no lo haga ‘ No desea permitirle a un atacante un punto de apoyo en su red para pasar y heredar la confianza de la posición de los servidores en la LAN / DMZ: controle sus páginas de error, no revele nada, pero escriba alertas cuando se activen, sea genérico el mundo no necesita saber los detalles de algo que sale mal, solo que no funcionó y lo lamentas. usuarios múltiples … idealmente VPN e iniciar sesión en WordPress en una LAN IP.

No use WordPress en una plataforma compartida, una forma común es que su sitio puede ser 100% ajustado, pero si se comparte con un sitio antiguo o un nuevo sitio vulnerable, es probable que el sitio vulnerable se caiga y los atacantes puedan moverse lateralmente. el sistema operativo o escalar a root / admin, este no es un problema de WordPress, es una crítica de implementación, use un VPS / servidor aislado, su propia IP, su propia caja específica, por proyecto, lo mismo para las bases de datos, tampoco las comparta

ahora, combínelo con los equipos de marketing que controlan los sitios a la izquierda y al centro, la auditoría interna cuestiona todo y el equipo de seguridad hace lo mejor que puede para poner en marcha y tiene el mismo problema con cualquier otro marco.

Yo uso WordPress en mi sitio. es perfecto para la entrega de contenido y hay una ENORME cantidad de soporte, los desarrolladores de complementos de terceros todavía están madurando a la seguridad pero responden bien cuando compartes lo que has encontrado (y generalmente se te acredita)

Recuerde, una vez que haya comprobado la seguridad de su sistema operativo / servidor web / base de datos / configuración / WordPress: cuando cualquiera de estos cambios tenga un impacto en los demás, no asuma que es tan seguro como lo era antes de actualizar, repita. validar la seguridad sigue siendo buena o identificar los riesgos introducidos

Si tiene que aceptar algún riesgo, vuelva a visitar esos riesgos en unos meses (si no antes)

Echa un vistazo a estos excelentes recursos, estoy seguro de que también puedes automatizar

• @WPScan por el equipo de WPScan
• Base de datos de vulnerabilidad @WPScan
• @OWASP Testing Guide v4 Tabla de contenido
• @Page en owasp.org
• @plecost – Herramienta de huellas digitales de WordPress – Google Project Hosting

Preguntas?
🙂

Cada plataforma tiene sus vulnerabilidades, y WordPress es de primera categoría cuando se trata de solucionar los riesgos de seguridad principales. Es una opción 100% viable para el frente y el fondo de un sitio bancario (si se toman las precauciones correctas), pero yo, personalmente, usaría un enfoque diferente …

¿A quién pertenecen mis datos?

No me gustaría almacenar datos confidenciales en la misma base de datos que el resto de los datos de WordPress. Para mí, en realidad no pertenece allí. Pertenece a otro lugar, bloqueado y encriptado de un millón de maneras diferentes. Aunque debería utilizar el alojamiento de WP administrado para cualquier sitio web de WordPress, normalmente está bloqueado en la base de datos que proporcionan. Personalmente, no quisiera que otra compañía sea ​​el guardián de mis datos comerciales centrales.

Una API simple

Construiría una API de Rest simple y fácilmente comprobable con una funcionalidad bancaria segura (por ejemplo, transferencias, depósitos o cualquier otra cosa). Usaría Lambda, API Gateway y RDS de Amazon (infinitamente escalable, barato, ~ 100% de tiempo de actividad). De esta manera, puede restringir fácilmente el acceso a través de los grupos de seguridad de AWS. Seamos realistas, usar un buen marco MVC en lugar de un script PHP básico también ahorraría un número infinito de dolores de cabeza desde el punto de vista de prueba y desarrollo.

100% de seguridad

A continuación, crearía una aplicación Ember (u otro marco JS) para interactuar con la API, luego colocaría la aplicación (etiqueta de secuencia de comandos) en una página de “Tablero”. Ahora, todo su sitio de WordPress podría ser servido desde un HTTPS CDN. Una vez que se construye el caché, puede desactivar WordPress por completo (o restringir el tráfico de administrador solo a su IP), eliminando TODAS las preocupaciones de seguridad de WordPress. Ahora, solo necesita mantener sus llaves de AWS de manera segura debajo de la almohada: D.

Bueno, lo que veo es que principalmente Banks usa WordPress como sitio web frontal. esto no tiene nada que ver con sus informes de clientes o backend. Si se concentra en estos conceptos básicos, estoy seguro de que no habrá problemas relacionados con la seguridad:

1. Asegúrese de desarrollar el sitio web desde cero con un marco de temas potente y actualizado regularmente, como génesis, etc.
2. Use la última versión de WordPress.
3. Instale y use git para la actualización del código del sitio web
4. Utilice solo complementos altamente recomendados y mejor calificados. Consulte la recomendación antes de usar.
5. Una vez que se desarrolla el sitio web, asegúrese de usar un servidor o VPS dañado. Nunca se recomienda alojamiento compartido
6. Limite el acceso usando .htaccess en los directorios de archivos. Elimine todos los archivos léame y de muestra en su tema.
7. Use una contraseña segura, mejor si usa 2FA.
8. Cambie su URL de acceso de administrador, cambie el prefijo db y asegúrese de tener un administrador limitado en su sitio web.
9. Use el límite de inicio de sesión para defender los ataques de fuerza bruta.
10. Utilice el firewall proporcionado por Sucuri

Un sitio web desarrollado para el banco y utilizado WordPress para clientes de frente. El primer banco islámico

Espero que esto le ayude bastante

Si necesita asegurar un sitio de WordPress, así es como lo hace.

Manejo la seguridad de WordPress para clientes y hay dos áreas que debes proteger.

1. El anfitrión. Asegúrese de estar trabajando con alguien que se especialice en hosting para su industria (financiera, hipaa, etc.). No podrá utilizar un host de presupuesto para esto. Además, asegúrese de tener servidores dedicados y un SSL activo. El alojamiento económico en un servidor compartido es probablemente el camino más rápido para ser hackeado.
2. El sitio web. Aquí es donde WordPress tiene muchas vulnerabilidades. Los piratas informáticos encuentran vulnerabilidades en complementos y temas y también atacan por fuerza bruta los inicios de sesión. Lo más importante es eliminar los complementos innecesarios o los complementos que el desarrollador no actualiza regularmente. Algunas personas piensan que puede lanzar tantos complementos como desee en su sitio de WordPress, esto no es cierto a menos que desee un sitio lento e hinchado que se filtre como un tamiz. Lo siguiente es instalar un complemento de seguridad que protegerá la parte frontal de su sitio. El complemento de Wordfence se encargará de todo eso. Hay otros por ahí como Sucuri, pero te diré por experiencia que Wordfence es el mejor. Lo uso para limpiar sitios pirateados y eliminar las penalizaciones de búsqueda de Google todo el tiempo, es un gran complemento. Otros están de acuerdo.

1. Cuentan con la red más grande de profesionales de seguridad y el firewall más completo en Internet para detectar vulnerabilidades rápidamente.
2. Autenticación fácil de dos factores para todos los inicios de sesión. Las credenciales de inicio de sesión comprometidas y los ataques de inicio de sesión de fuerza bruta siguen siendo el método de piratería número uno para los sitios de WordPress. Esto elimina ese riesgo todos juntos.
3. El escaneo y monitoreo más avanzado de cualquier complemento. Como dije anteriormente, uso este complemento para limpiar sitios pirateados todo el tiempo.
4. Alertas por correo electrónico cada vez que un complemento o tema necesita una actualización. La otra vulnerabilidad más común encontrada en los sitios de WordPress son los complementos y temas desactualizados. Este complemento te ayuda a estar al tanto de ellos y mantenerlos actualizados. También recomiendo instalar el complemento Jetpack y activar la actualización automática del complemento, entonces solo debe preocuparse por su tema.

Espero que eso ayude…

Sinceramente, WordPress para algo más que un blog o una simple tienda de comercio electrónico nunca me parece una buena idea. Ni siquiera puedo entender la idea de que un BANCO permitiría a una entidad solitaria acercarse incluso a la información de sus clientes o ser responsable de un componente en el que las personas confían tanto hoy. Esto debe ser una especie de cooperativa de crédito porque no hay manera en el infierno y la cadena nacional o incluso la cadena estatal estaría remotamente de acuerdo con el uso de WordPress para impulsar un banco.

No estoy sugiriendo que no sea un desarrollador competente, pero si pregunta “qué medidas de seguridad debo tomar en Quora”, diga el signo número 1. Por cierto, podría obtener una respuesta inteligente de alguien dispuesto a darle el error sugerencias con la esperanza de que escuches y te hackeen socialmente aquí mismo en Quora.

Escucha amigo, si vas a aceptar la responsabilidad por esto, sería muy, muy, muy cauteloso y escéptico al respecto.

Los bancos pequeños y medianos tienden a externalizar su banca en línea en estos días. Solo los bancos más grandes crean sus propias aplicaciones transaccionales. Mi banco me envía a secure.myvirtualbranch.com para la banca en línea, que, no hace falta decir que no es su dominio.

Si un banco no mantiene una aplicación de banca en línea, no veo por qué su sitio tiene necesidades de seguridad diferentes a las de otros sitios de negocios. Y sí, la seguridad de WordPress depende completamente de la tarea.

Todos los sitios web profesionales y comerciales deben ejecutarse en sistemas CMS seguros. Realmente no es tan difícil para cualquier desarrollador y proveedor de alojamiento web que sepa lo que están haciendo para mantener todo actualizado y seguro. Un buen desarrollador también debe saber qué complementos y personalizaciones de temas evitar. También creo que WordPress es mejor que otros sistemas CMS para la seguridad porque su ciclo de desarrollo es más rápido y despliegan actualizaciones más rápido.

• Instancia dedicada de Amazon o Azure (sin FTP, correo, solo SSH, apache / nginx y mysql). Todos los puertos excepto 80 cerrados
• Limite / wp-admin en nginx conf a su IP estática interna (VPN desde afuera para administración)
• Más y menos sin complementos de terceros. Si necesita algo específico (por ejemplo, calculadora de préstamos, calculadora de tasa de interés de ahorro), haga su propio código. Se pueden implementar muchas cosas sin complementos (o con complementos básicos en lugar de funciones temáticas, para la portabilidad / mantenibilidad / reutilización en otros temas / sitios web)
• Sin registro de usuario / cliente. Supongo que está buscando configurar un sitio web informativo B2C y B2B y debería permanecer como tal.
• Banca por Internet en subdominio y con seguridad en otra solución / servidor especializado

Si tiene la intención de publicar páginas informativas o de perfil, puede usar complementos de seguridad estándar de WordPress.

Y, como ya se mencionó, si planea hacer una base de datos de miembros o cuentas con información de los usuarios, entonces no es una buena idea usar WordPress. Tendrá que considerar un CMS personalizado con seguridad adicional para evitar que la información confidencial del cliente se vea comprometida. WordPress no es invulnerable.