miércoles, 29 de julio de 2009

SEO Black Hat

SEO Black Hat tiene material interesante sobre Google y otros buscadores

 How To Get More Links to Your Remarkable Blog Posts

subversion

¿Qué es Subversion?

Subversion es un sistema de control de versiones libre y de código fuente abierto. Es decir, Subversion maneja ficheros y directorios a través del tiempo. Hay un Árbol de archivos en un repositorio central. El repositorio es como un servidor de archivos ordinario, excepto que recuerda todos los cambios hechos a sus archivos y directorios. Esto permite recuperar versiones antiguas de datos o examinar el historial de cambios de los mismos. En este aspecto, mucha gente piensa en los sistemas de versiones como en una especie de máquina del tiempo.

Subversion proporciona:

Versionado de directorios
CVS solamente lleva el historial de archivos individuales, pero Subversion implementa un sistema de archivos versionado virtual que sigue los cambios sobre árboles de directorios completos a través del tiempo. Ambos, archivos y directorios, se encuentran bajo el control de versiones.
Verdadero historial de versiones
CVS está limitado al versionado de archivos. Operaciones como copiar y renombrar, las cuales pueden ocurrir sobre archivos, pero realmente son cambios al contenido del directorio en el que se encuentran, no son soportadas por CVS. Adicionalmente, en CVS no puede reemplazar un archivo versionado con algo nuevo que lleve el mismo nombre sin que el nuevo elemento herede el historial del archivo antiguo que quizás sea completamente distinto al anterior. Con Subversion, se puede añadir, borrar, copiar, y renombrar archivos y directorios. Cada fichero nuevo añadido comienza con un historial nuevo, limpio y completamente suyo.
Envíos atómicos
Una colección cualquiera de modificaciones o bien entra por completo al repositorio, o bien no lo hace en absoluto. Ésto permite a los desarrolladores construir y enviar los cambios como fragmentos lógicos e impide que ocurran problemas cuando sólo una parte de los cambios enviados lo hace con éxito.
Versionado de metadatos
Cada archivo o directorio tiene un conjunto de propiedades claves y sus valores asociado. Se puede crear y almacenar cualquier par arbitrario de clave/valor. Las propiedades son versionadas a través del tiempo, al igual que el contenido de los ficheros.
Elección de las capas de red
Subversion tiene una noción abstracta del acceso al repositorio, facilitando a las personas implementar nuevos mecanismos de red. Subversion puede conectarse al servidor HTTP Apache como un módulo de extensión. Ésto proporciona a Subversion una gran ventaja en estabilidad e interoperabilidad, y acceso instantáneo a las caracterí­sticas existentes que ofrece este servidor: autenticación, autorización, compresión de la conexión, etcétera. También tiene disponible un servidor de Subversion independiente, y más ligero. Este servidor habla un protocolo propio, el cual puede ser encaminado fácilmente a través de un túnel SSH.
La versión de default trabaja con apache 2.0 pero es posible bajar un versión para apache 2.2.4
Manipulación consistente de datos
Subversion expresa las diferencias del archivo usando un algoritmo de diferenciación binario, que funciona idénticamente con ficheros de texto (legibles para humanos) y ficheros binarios (ilegibles para humanos). Ambos tipos de ficheros son almacenados igualmente comprimidos en el repositorio, y las diferencias son transmitidas en ambas direcciones a través de la red.
Ramificación y etiquetado eficientes
El coste de ramificación y etiquetado no necesita ser proporcional al tamaño del proyecto. Subversion crea ramas y etiquetas simplemente copiando el proyecto, usando un mecanismo similar al enlace duro. De este modo estas operaciones toman solamente una cantidad de tiempo pequeña y constante.
Subversion almacena todos los datos versionados en un repositorio central. TortoiseSvn is un proyecto hermano que proporciona integración con Windows explorer. Vea Capítulo 6, Configuración del servidor para aprender acerca de los diferentes tipos de procesos servidor disponibles y cómo configurarlos. svnserver puede correr como un servicio de Windows. Para crear el servicio http://svn.haxx.se/dev/archive-2006-11/0348.shtmlhttp://httpd.apache.org/download.cgi

http://svnbook.red-bean.com/en/1.0/ch06s03.html

http://svn.collab.net/repos/svn/trunk/notes/windows-service.txt

ASP.Net Security

tecnologias ASP.Net Make sure you are very familiar with the following terms:
  • Authentication. Positively identifying the clients of your application; clients might include end-users, services, processes or computers.
  • Authorization. Defining what authenticated clients are allowed to see and do within the application.
  • Secure Communications. Ensuring that messages remain private and unaltered as they cross networks.
  • Impersonation. This is the technique used by a server application to access resources on behalf of a client. The client's security context is used for access checks performed by the server.
  • Delegation. An extended form of impersonation that allows a server process that is performing work on behalf of a client, to access resources on a remote computer. This capability is natively provided by Kerberos on Microsoft® Windows® 2000 and later operating systems. Conventional impersonation (for example, that provided by NTLM) allows only a single network hop. When NTLM impersonation is used, the one hop is used between the client and server computers, restricting the server to local resource access while impersonating.
  • Security Context. Security context is a generic term used to refer to the collection of security settings that affect the security-related behavior of a process or thread. The attributes from a process' logon session and access token combine to form the security context of the process.
  • Identity. Identity refers to a characteristic of a user or service that can uniquely identify it. For example, this is often a display name, which often takes the form authority/user name.

Principles

There are a number of overarching principles that apply to the guidance. The following summarizes these principles:
  • Adopt the principle of least privilege. Processes that run script or execute code should run under a least privileged account to limit the potential damage that can be done if the process is compromised. If a malicious user manages to inject code into a server process, the privileges granted to that process determine to a large degree the types of operations the user is able to perform. Code that requires additional trust (and raised privileges) should be isolated within separate processes.The ASP.NET team made a conscious decision to run the ASP.NET account with least privileges.
  • Use defense in depth. Place check points within each of the layers and subsystems within your application. The check points are the gatekeepers that ensure that only authenticated and authorized users are able to access the next downstream layer.
  • Don't trust user input. Applications should thoroughly validate all user input before performing operations with that input. The validation may include filtering out special characters. This preventive measure protects the application against accidental misuse or deliberate attacks by people who are attempting to inject malicious commands into the system. Common examples include SQL injection attacks, cross-site scripting attacks, and buffer overflow.
  • Use secure defaults. A common practice among developers is to use reduced security settings, simply to make an application work. If your application demands features that force you to reduce or change default security settings, test the effects and understand the implications before making the change.
  • Don't rely on security by obscurity. Trying to hide secrets by using misleading variable names or storing them in odd file locations does not provide security. In a game of hide-and-seek, it's better to use platform features or proven techniques for securing your data.
  • Check at the gate. You don't always need to flow a user's security context to the back end for authorization checks. Often, in a distributed system, this is not the best choice. Checking the client at the gate refers to authorizing the user at the first point of authentication (for example, within the Web application on the Web server), and determining which resources and operations (potentially provided by downstream services) the user should be allowed to access.If you design solid authentication and authorization strategies at the gate, you can circumvent the need to delegate the original caller's security context all the way through to your application's data tier.
  • Assume external systems are insecure. If you don't own it, don't assume security is taken care of for you.
  • Reduce surface area. Avoid exposing information that is not required. By doing so, you are potentially opening doors that can lead to additional vulnerabilities. Also, handle errors gracefully; don't expose any more information than is required when returning an error message to the end user.
  • Fail to a secure mode. If your application fails, make sure it does not leave sensitive data unprotected. Also, do not provide too much detail in error messages; meaning don't include details that could help an attacker exploit a vulnerability in your application. Write detailed error information to the Windows event log.
  • Remember you are only as secure as your weakest link. Security is a concern across all of your application tiers.
  • If you don't use it, disable it. You can remove potential points of attack by disabling modules and components that your application does not require. For example, if your application doesn't use output caching, then you should disable the ASP.NET output cache module. If a future security vulnerability is found in the module, your application is not threatened.
The following steps identify a process that will help you develop an authentication and authorization strategy for your application:
  1. Identify resources
  2. Choose an authorization strategy
  3. Choose the identities used for resource access
  4. Consider identity flow
  5. Choose an authentication approach
  6. Decide how to flow identity
Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication

viernes, 24 de julio de 2009

Sysinternals webinar

Windows Internals with Sysinternals

2 day webinar/virtual class -

presented by David Solomon

Next offering:

 October 19 & 21, 10:00am-5:00pm Eastern Time (GMT-5)
Click here to register

SysInternals

Hace algunos años Mark Russinovich tenía un sitio llamado SysInternals donde no solo ofrecía rutinas para realizar operaciones de administración de Windows sino también el correspondiente código fuente y artículos con explicación detallada de la lógica de programación. Afortunadamente para él y desafortunadamente para los hackers curiosos Microsoft le compro el sitio y quito el acceso a los códigos fuentes y las explicaciones sobre el funcionamiento interno de Windows.
 
Ahora Microsoft incluye Windows SysInternals como parte de su sito de soporte con un enfoque de administración de sistemas en vez del de programación que originalmente tenia. No queda más que comprar Windows® Internals: Including Windows Server 2008 and Windows Vista, Fifth Edition (PRO-Developer) y compensar a Russinovich por compartir sus experiencias.