Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
La denegación de servicio se produce cuando un sistema está sobrecargado de tal manera que los mensajes no se pueden procesar o se procesan muy lentamente.
Exceso de consumo de memoria
Se puede producir un problema al leer un documento XML con un gran número de nombres locales únicos, espacios de nombres o prefijos. Si está utilizando una clase que deriva de XmlReader y llama a la propiedad LocalName, Prefix o NamespaceURI para cada elemento, la cadena devuelta se agrega a NameTable. La colección contenida por NameTable nunca disminuye de tamaño, creando una "pérdida de memoria" virtual de los identificadores de cadena.
Las mitigaciones incluyen:
Derive de la NameTable clase y aplique una cuota de tamaño máximo. (No se puede impedir el uso de un NameTable o cambiar a NameTable cuando está lleno.)
Evite usar las propiedades mencionadas y, en su lugar, use el MoveToAttribute método con el IsStartElement método siempre que sea posible; esos métodos no devuelven cadenas y, por tanto, evitan el problema de sobrerrellenar la NameTable colección.
El cliente malintencionado envía solicitudes de licencia excesivas al servicio
Si un cliente malintencionado bombardea un servicio con solicitudes de licencia excesivas, puede hacer que el servidor use memoria excesiva.
Mitigación: use las siguientes propiedades de la LocalServiceSecuritySettings clase :
MaxCachedCookies: controla el número máximo de
SecurityContextTokens limitados por tiempo que el servidor almacena en memoria caché después de la negociaciónSPNegooSSL.IssuedCookieLifetime: controla la duración de
SecurityContextTokensque el servidor emite tras la negociaciónSPNegooSSL. El servidor almacena en caché losSecurityContextTokens durante este período de tiempo.MaxPendingSessions: controla el número máximo de conversaciones seguras que se establecen en el servidor, pero para las que no se ha procesado ningún mensaje de aplicación. Esta cuota evita que los clientes establezcan conversaciones seguras en el servicio, por lo que el servicio mantiene el estado por cliente, pero sin usarlos.
InactivityTimeout: controla el tiempo máximo que el servicio mantiene activa una conversación segura sin recibir un mensaje de aplicación del cliente para la conversación. Esta cuota evita que los clientes establezcan conversaciones seguras en el servicio, por lo que el servicio mantiene el estado por cliente, pero sin usarlos.
WSDualHttpBinding o los enlaces personalizados duales requieren autenticación del cliente
De forma predeterminada, la seguridad está habilitada en el WSDualHttpBinding. Sin embargo, es posible que, si se deshabilita la autenticación del cliente estableciendo la propiedad ClientCredentialType en None, un usuario malintencionado pueda provocar un ataque de denegación de servicio en otro servicio. Esto puede ocurrir porque un cliente malintencionado puede dirigir el servicio para enviar una secuencia de mensajes a un tercer servicio.
Para mitigar esto, no establezca la propiedad en None. Tenga en cuenta también esta posibilidad al crear un enlace personalizado que tenga un patrón de mensaje dual.
Se puede rellenar el registro de eventos de auditoría
Si un usuario malintencionado entiende que la auditoría está habilitada, ese atacante puede enviar mensajes no válidos que hacen que se escriban entradas de auditoría. Si el registro de auditoría se rellena de esta manera, se produce un error en el sistema de auditoría.
Para mitigar esto, establezca la propiedad SuppressAuditFailure en true y utilice las propiedades del Visor de eventos para controlar el comportamiento de auditoría. Para obtener más información sobre el uso del Visor de eventos para ver y administrar registros de eventos, consulte Visor de eventos. Para obtener más información, consulte Auditoría.
Las implementaciones no válidas de IAuthorizationPolicy pueden hacer que el servicio deje de responder
Llamar al Evaluate método en una implementación errónea de la IAuthorizationPolicy interfaz puede hacer que el servicio deje de responder.
Mitigación: use solo código de confianza. Es decir, use solo código que haya escrito y probado, o que proceda de un proveedor de confianza. No permita que extensiones no confiables de IAuthorizationPolicy se integren en su código sin la debida consideración. Esto se aplica a todas las extensiones usadas en una implementación de servicio. WCF no distingue entre el código de aplicación y el código externo que se conecta mediante puntos de extensibilidad.
El tamaño máximo del token Kerberos puede necesitar ser reajustado.
Si un cliente pertenece a un gran número de grupos (aproximadamente 900, aunque el número real varía en función de los grupos), puede producirse un problema cuando el bloque de un encabezado de mensaje supera los 64 kilobytes. En ese caso, puede aumentar el tamaño máximo del token kerberos. También puede necesitar aumentar el tamaño máximo del mensaje de WCF para acomodar el token Kerberos más grande.
La inscripción automática da como resultado varios certificados con el mismo nombre de firmante para la máquina
La inscripción automática es la capacidad de Windows Server 2003 para inscribir automáticamente usuarios y equipos para certificados. Cuando una máquina está en un dominio con la característica habilitada, se crea automáticamente un certificado X.509 con el propósito previsto de autenticación de cliente e se inserta en el almacén de certificados personales del equipo local cada vez que se une una nueva máquina a la red. Sin embargo, la inscripción automática usa el mismo nombre de sujeto para todos los certificados que crea en la memoria caché.
El impacto es que los servicios WCF pueden no abrirse en dominios con inscripción automática. Esto ocurre porque los criterios de búsqueda de credenciales X.509 del servicio predeterminado pueden ser ambiguos porque existen varios certificados con el nombre completo del sistema de nombres de dominio (DNS) de la máquina. Un certificado se origina en la inscripción automática; el otro podría ser un certificado auto emitido.
Para mitigar esto, haga referencia al certificado exacto que se va a usar mediante un criterio de búsqueda más preciso en serviceCredentials<>. Por ejemplo, use la FindByThumbprint opción y especifique el certificado por su huella digital única (hash).
Para obtener más información sobre la característica de inscripción automática, vea Inscripción automática de certificados en Windows Server 2003.
Último de varios nombres de asunto alternativos que se usan en la autorización
En el caso poco frecuente de que un certificado X.509 contenga varios nombres alternativos de sujeto y se autorice el uso del nombre de sujeto alternativo, puede producirse un error en la autorización.
Protección de archivos de configuración con ACL
Puede especificar declaraciones obligatorias y opcionales en archivos de código y configuración para tokens emitidos por CardSpace. Esto resulta en la emisión de elementos correspondientes en los mensajes RequestSecurityToken que se envían al servicio de tokens de seguridad. Un atacante puede modificar el código o la configuración para quitar las reclamaciones necesarias u opcionales, lo que podría hacer que el servicio de token de seguridad emita un token que no permita el acceso al servicio de destino.
Para mitigar: requerir acceso al equipo para modificar el archivo de configuración. Use listas de control de acceso a archivos (ACL) para proteger los archivos de configuración. WCF requiere que el código esté en el directorio de la aplicación o en la caché global de ensamblados antes de permitir que dicho código se cargue desde la configuración. Use las ACL de directorio para proteger los directorios.
Se alcanza el número máximo de sesiones seguras para un servicio
Cuando un servicio autentica correctamente un cliente y se establece una sesión segura con el servicio, el servicio realiza un seguimiento de la sesión hasta que el cliente lo cancela o expira la sesión. Cada sesión establecida afecta al límite para el número máximo de sesiones simultáneas activas con un servicio. Cuando se alcanza este límite, los clientes que intentan crear una nueva sesión con ese servicio se rechazan hasta que una o varias sesiones activas expiran o se cancelan por un cliente. Un cliente puede tener varias sesiones con un servicio y cada una de esas sesiones cuenta hacia el límite.
Nota:
Cuando se usan sesiones con estado, el párrafo anterior no se aplica. Para obtener más información sobre las sesiones con estado, consulte Cómo crear un token de contexto de seguridad para una sesión segura.
Para mitigar esto, establezca el límite para el número máximo de sesiones activas y la duración máxima de una sesión estableciendo la SecurityBindingElement propiedad de la SecurityBindingElement clase .