foo
Diferencias
Muestra las diferencias entre dos versiones de la página.
| Ambos lados, revisión anteriorRevisión previaPróxima revisión | Revisión previa | ||
| foo [2021/10/01 15:02] – [Construyendo una botnet] tempwin | foo [2023/04/08 15:57] (actual) – [Uncle Bob SOLID principles] tempwin | ||
|---|---|---|---|
| Línea 1: | Línea 1: | ||
| - | |||
| burpsuite | burpsuite | ||
| Línea 53: | Línea 52: | ||
| * Cliente envía ACK | * Cliente envía ACK | ||
| - | Si un puerto está abierto: | + | Si un puerto está **abierto**: |
| - | | + | |
| - | | + | |
| - | | + | |
| - | Si está cerrado | + | Si está **cerrado** |
| * SYN | * SYN | ||
| * RST | * RST | ||
| - | Si está filtrado: | + | Si está **filtrado**: |
| + | |||
| + | * SYN (aquí lo detiene un firewall) | ||
| Línea 78: | Línea 79: | ||
| - | Ciclo de vida de un ataque: | + | Ciclo de vida de un ataque |
| - Identificacion del objetivo | - Identificacion del objetivo | ||
| - Análisis de puertos y servicios | - Análisis de puertos y servicios | ||
| - Análisis de vulnerabilidades | - Análisis de vulnerabilidades | ||
| - | - Explotación | + | - Explotación |
| - | - Post-explotación | + | - Post-explotación |
| === Reconocimiento === | === Reconocimiento === | ||
| Línea 381: | Línea 382: | ||
| En el servidor veremos que se ha establecido una conexión: | En el servidor veremos que se ha establecido una conexión: | ||
| - | IMAAAAAAAAAAAAAAAAAAAGEN | + | {{ : |
| * '' | * '' | ||
| * '' | * '' | ||
| + | |||
| + | ===== Uncle Bob SOLID principles ===== | ||
| + | |||
| + | Las bases de la programación orientada a objetos son: | ||
| + | |||
| + | * Encapsulación | ||
| + | * Herencia | ||
| + | * Polimorfismo | ||
| + | |||
| + | La programación orientada a objetos va sobre la gestión de dependencias en el código para que se pueda prevenir: | ||
| + | |||
| + | * Rigidez | ||
| + | * Fragilidad | ||
| + | * No reutilización | ||
| + | |||
| + | Principios **SOLID**, principios de diseño de clases: | ||
| + | |||
| + | * **S**RP: Single Responsibility Principle. | ||
| + | * **O**CP: The Open/Closed Principle. | ||
| + | * **L**SP: The Liskov Substitution Principle. | ||
| + | * **I**SP: The Interface Segregation Principle. | ||
| + | * **D**IP: The Dependency Inversion Principle. | ||
| + | |||
| + | <WRAP center round info 60%> | ||
| + | Los principios de diseño **SOLID** son principios, no reglas. Es mejor usar el sentido común cuando se aplica SOLID. **SOLID** es una herramienta, | ||
| + | </ | ||
| + | |||
| + | ==== Single Responsibility Principle ==== | ||
| + | |||
| + | Una clase debería tener una y solo una única razón para cambiar. | ||
| + | |||
| + | La palabra **responsabilidad** no quiere decir función o lo que hace la clase. La palabra **responsabilidad** se refiere al cambio. | ||
| + | |||
| + | Si una clase tiene más de un motivo para cambiar, estaría violando este principio. | ||
| + | |||
| + | En resumen, no pongas funciones que cambian por diferentes razones en la misma clase. | ||
| + | |||
| + | ==== Open/Closed Principle ==== | ||
| + | |||
| + | Los módulos deberían estar abiertos a la extensión, pero cerrados a la modificación. | ||
| + | |||
| + | Esto quiere decir que deberías poder modificar lo que hace un módulo sin cambiar el módulo. Cambiar el comportamiento del módulo, sin cambiar el módulo. | ||
| + | |||
| + | Extiende la funcionalidad añadiendo nuevo código en lugar de cambiar el exsitente. | ||
| + | |||
| + | Separa comportamientos para que el sistema pueda ser fácilmente extensible, pero no pueda romperse. | ||
| + | |||
| + | El objetivo es llegar a un punto donde nunca podrás romper el núcleo (//core//) de tu sistema. | ||
| + | |||
| + | ==== Liskov Substitution Principle ==== | ||
| + | |||
| + | Las clases derivadas deben ser usables a través de la interfaz de base sin necesidad de que el usuario sepa la diferencia. | ||
| + | |||
| + | ==== The Interface Segregation Principle ==== | ||
| + | |||
| + | Ningún cliente debería ser forzado a depender de métodos que no usa. | ||
| + | |||
| + | Cambiar un método en una clase no debería afectar a clases que no dependen de él. | ||
| + | |||
| + | Reemplazar interfaces demasiado populadas por varias pequeñas, pero específicas interfaces. | ||
| + | |||
| + | |||
| + | ==== The Dependency Inversion Principle ==== | ||
| + | |||
| + | Los módulos de alto nivel no deberían depender de módulos de bajo nivel. Ambos deberían depender de abstracciones. | ||
| + | |||
| + | Nunca dependas de algo concreto, solo de las abstracciones. | ||
| + | |||
| + | Hay que ser capaz de modificar una implementación fácilmente sin alterar el código de alto nivel. | ||
foo.1633093340.txt.gz · Última modificación: por tempwin
