Add initial files
Co-authored-by: Ezequiel Bellver <ebellver@itba.edu.ar> Co-authored-by: Juan Barmasch <jbarmasch@itba.edu.ar>
This commit is contained in:
commit
a9b3a97798
|
|
@ -0,0 +1,15 @@
|
||||||
|
.config/
|
||||||
|
.gdb_history
|
||||||
|
.gdbinit
|
||||||
|
.idea/
|
||||||
|
.inputrc
|
||||||
|
.viminfo
|
||||||
|
.vscode/
|
||||||
|
|
||||||
|
patches/
|
||||||
|
|
||||||
|
## Output
|
||||||
|
server
|
||||||
|
client
|
||||||
|
*.o
|
||||||
|
a.out
|
||||||
|
|
@ -0,0 +1,24 @@
|
||||||
|
MIT License
|
||||||
|
|
||||||
|
Copyright (c) 2021-2022 Santiago Lo Coco \
|
||||||
|
Copyright (c) 2021-2022 Juan Martín Barmasch \
|
||||||
|
Copyright (c) 2021-2022 Ezequiel Bellver
|
||||||
|
|
||||||
|
Permission is hereby granted, free of charge, to any person obtaining a copy
|
||||||
|
of this software and associated documentation files (the "Software"), to deal
|
||||||
|
in the Software without restriction, including without limitation the rights
|
||||||
|
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
||||||
|
copies of the Software, and to permit persons to whom the Software is
|
||||||
|
furnished to do so, subject to the following conditions:
|
||||||
|
|
||||||
|
The above copyright notice and this permission notice shall be included in all
|
||||||
|
copies or substantial portions of the Software.
|
||||||
|
|
||||||
|
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
||||||
|
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
||||||
|
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
||||||
|
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
||||||
|
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
||||||
|
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
||||||
|
SOFTWARE.
|
||||||
|
|
||||||
|
|
@ -0,0 +1,32 @@
|
||||||
|
CC = gcc
|
||||||
|
# CC = clang
|
||||||
|
CCFLAGS = -std=c11 -Wall -Wextra -Werror -Wno-unused-parameter -Wno-implicit-fallthrough -pedantic -pedantic-errors -fsanitize=address -g
|
||||||
|
|
||||||
|
SERVER_SOURCES=src/server.c src/args.c
|
||||||
|
CLIENT_SOURCES=src/client.c
|
||||||
|
SERVER_LIBS=include/server.h include/args.h
|
||||||
|
CLIENT_LIBS=include/client.h
|
||||||
|
SERVER_OBJ=server
|
||||||
|
CLIENT_OBJ=client
|
||||||
|
|
||||||
|
all: $(CLIENT_OBJ) $(SERVER_OBJ)
|
||||||
|
|
||||||
|
$(SERVER_OBJ): $(SERVER_SOURCES) $(SERVER_LIBS)
|
||||||
|
$(CC) $(CCFLAGS) -o $(SERVER_OBJ) $(SERVER_SOURCES)
|
||||||
|
|
||||||
|
$(CLIENT_OBJ): $(CLIENT_SOURCES) $(CLIENT_LIBS)
|
||||||
|
$(CC) $(CCFLAGS) -o $(CLIENT_OBJ) $(CLIENT_SOURCES)
|
||||||
|
|
||||||
|
clean:
|
||||||
|
rm -f $(CLIENT_OBJ) $(SERVER_OBJ)
|
||||||
|
|
||||||
|
test:
|
||||||
|
pvs-studio-analyzer trace -- make
|
||||||
|
pvs-studio-analyzer analyze
|
||||||
|
plog-converter -a '64:1,2,3;GA:1,2,3;OP:1,2,3' -t tasklist -o report.tasks PVS-Studio.log
|
||||||
|
cppcheck --quiet --enable=all --force --inconclusive .
|
||||||
|
|
||||||
|
cleanTest:
|
||||||
|
rm -f PVS-Studio.log report.tasks strace_out
|
||||||
|
|
||||||
|
.PHONY: all clean test cleanTest
|
||||||
|
|
@ -0,0 +1,74 @@
|
||||||
|
# BProxy
|
||||||
|
|
||||||
|
BProxy (Bottler Proxy)
|
||||||
|
|
||||||
|
## Tabla de contenidos
|
||||||
|
- [Requisitos <a name="requisitos"></a>](#requisitos-)
|
||||||
|
- [Compilación <a name="compilación"></a>](#compilación-)
|
||||||
|
- [Ejecución <a name="ejecución"></a>](#ejecución-)
|
||||||
|
- [Testeos <a name="tests"></a>](#testeos-)
|
||||||
|
- [Limpieza <a name="limpieza"></a>](#limpieza-)
|
||||||
|
|
||||||
|
## Requisitos <a name="requisitos"></a>
|
||||||
|
|
||||||
|
Debe instalar gcc y make. Estos se encuentran disponibles en el repositorio de la vasta mayoría de distribuciones de Linux/macOS.
|
||||||
|
|
||||||
|
## Compilación <a name="compilación"></a>
|
||||||
|
|
||||||
|
Para compilar todos los archivos se debe hacer:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
make all
|
||||||
|
```
|
||||||
|
|
||||||
|
## Ejecución <a name="ejecución"></a>
|
||||||
|
|
||||||
|
Ahora, tendrá dos ejecutables: `client` y `server`. Note que primero debe correr el `server` y luego conectarse con el `client`.
|
||||||
|
|
||||||
|
```bash
|
||||||
|
./server
|
||||||
|
```
|
||||||
|
|
||||||
|
y en otra terminal
|
||||||
|
|
||||||
|
```bash
|
||||||
|
./client
|
||||||
|
```
|
||||||
|
|
||||||
|
## Testeos <a name="tests"></a>
|
||||||
|
|
||||||
|
En orden de realizar un análisis estático del sistema usted debe tener instalado [cppcheck](http://cppcheck.net/) y [pvs-studio](https://pvs-studio.com/). Luego, puede correrlos con:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
make test
|
||||||
|
```
|
||||||
|
|
||||||
|
Por último, si quiere hacer un análisis dinámico (usando [valgrind](https://valgrind.org/)) puede hacerlo mediante:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
valgrind ./server
|
||||||
|
```
|
||||||
|
|
||||||
|
y en otra terminal
|
||||||
|
|
||||||
|
```bash
|
||||||
|
valgrind ./client
|
||||||
|
```
|
||||||
|
|
||||||
|
## Limpieza <a name="limpieza"></a>
|
||||||
|
Si desea borrar los archivos creados luego de la compilación debe correr:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
make clean
|
||||||
|
```
|
||||||
|
|
||||||
|
Note que si, además, quiere borrar el output de los tests (de `PVS-Studio` específicamente), lo puede hacer con:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
make cleanTest
|
||||||
|
```
|
||||||
|
|
||||||
|
# Autores
|
||||||
|
- Barmasch, Juan Martín (61033)
|
||||||
|
- Bellver, Ezequiel (61268)
|
||||||
|
- Lo Coco, Santiago (61301)
|
||||||
|
|
@ -0,0 +1,336 @@
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
May 24, 2022
|
||||||
|
|
||||||
|
|
||||||
|
Trabajo Práctico Especial 2022/1
|
||||||
|
Revisión 0
|
||||||
|
|
||||||
|
Resumen
|
||||||
|
|
||||||
|
Este documento describe el Trabajo Especial de la materia Protocolos
|
||||||
|
de Comunicación para la cursada del primer cuatrimestre del año 2022.
|
||||||
|
|
||||||
|
En su ejecución los alumnos DEBEN demostrar habilidad para la
|
||||||
|
programación de aplicaciones cliente/servidor con sockets, la
|
||||||
|
comprensión de estándares de la industria, y la capacidad de diseñar
|
||||||
|
protocolos de aplicación.
|
||||||
|
|
||||||
|
Terminología
|
||||||
|
|
||||||
|
Las palabras clave "DEBE", "NO DEBE", "OBLIGATORIO", "DEBERÁ", "NO
|
||||||
|
DEBERÁ", "DEBERÍA", "NO DEBERÍA", "RECOMENDADO", "PUEDE" y "OPCIONAL"
|
||||||
|
en este documento serán interpretadas como se describe en el RFC 2119
|
||||||
|
[RFC2119].
|
||||||
|
|
||||||
|
Tabla de Contenidos
|
||||||
|
|
||||||
|
1. Requerimientos Funcionales . . . . . . . . . . . . . . . . . 1
|
||||||
|
2. Requerimientos No Funcionales . . . . . . . . . . . . . . . . 2
|
||||||
|
3. Evaluación . . . . . . . . . . . . . . . . . . . . . . . . . 4
|
||||||
|
4. Referencias . . . . . . . . . . . . . . . . . . . . . . . . . 6
|
||||||
|
4.1. Normative References . . . . . . . . . . . . . . . . . . 6
|
||||||
|
4.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 6
|
||||||
|
|
||||||
|
1. Requerimientos Funcionales
|
||||||
|
|
||||||
|
El objetivo del trabajo es implementar un servidor proxy para el
|
||||||
|
protocolo SOCKSv5[RFC1928].
|
||||||
|
|
||||||
|
El servidor DEBE
|
||||||
|
|
||||||
|
1. atender a múltiples clientes en forma concurrente y simultánea
|
||||||
|
(al menos 500).
|
||||||
|
|
||||||
|
2. soportar autenticación usuario / contraseña [RFC1929].
|
||||||
|
|
||||||
|
3. soportar de mínima conexiones salientes a a servicios TCP a
|
||||||
|
direcciones IPv4, IPV6, o utilizando FQDN que resuelvan
|
||||||
|
cualquiera de estos tipos de direcciones.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Enunciado [Pag. 1]
|
||||||
|
|
||||||
|
Trabajo Especial 2020/2 May 2022
|
||||||
|
|
||||||
|
|
||||||
|
4. ser robusto en cuanto a las opciones de conexión (si se utiliza
|
||||||
|
un FQDN que resuelve a múltiples direcciones IP y una no está
|
||||||
|
disponible debe intentar con otros).
|
||||||
|
|
||||||
|
5. reportar los fallos a los clientes usando toda la potencia del
|
||||||
|
protocolo.
|
||||||
|
|
||||||
|
6. implementar mecanismos que permitan recolectar métricas que
|
||||||
|
ayuden a monitorear la operación del sistema.
|
||||||
|
|
||||||
|
A. cantidad de conexiones históricas
|
||||||
|
|
||||||
|
B. cantidad de conexiones concurrentes
|
||||||
|
|
||||||
|
C. cantidad de bytes transferidos
|
||||||
|
|
||||||
|
D. cualquier otra métrica que considere oportuno para el
|
||||||
|
entendimiento del funcionamiento dinámico del sistema
|
||||||
|
|
||||||
|
Las métricas PUEDEN ser volátiles (si se reinicia el servidor las
|
||||||
|
estadísticas pueden perderse).
|
||||||
|
|
||||||
|
7. implementar mecanismos que permitan manejar usuarios cambiar la
|
||||||
|
configuración del servidor en tiempo de ejecución sin reiniciar
|
||||||
|
el servidor. Las diferentes implementaciones PUEDEN decidir
|
||||||
|
disponibilizar otros cambios de ejecución en tiempo de ejecución
|
||||||
|
de otras configuraciones (memoria utilizada en I/O, timeouts,
|
||||||
|
etc).
|
||||||
|
|
||||||
|
8. implementar un registro de acceso que permitan a un administrador
|
||||||
|
entender los accesos de cada uno de los usuarios. Pensar en el
|
||||||
|
caso de que llega una queja externa y el administrador debe saber
|
||||||
|
quien fue el que se conectó a cierto sitio web y cuando.
|
||||||
|
|
||||||
|
9. monitorear el tráfico y generar un registro de credenciales de
|
||||||
|
acceso (usuarios y passwords) de forma similar a ettercap por lo
|
||||||
|
menos para protocolo POP3.
|
||||||
|
|
||||||
|
2. Requerimientos No Funcionales
|
||||||
|
|
||||||
|
Adicionalmente, la implementación DEBE
|
||||||
|
|
||||||
|
1. Estar escritos en el lenguaje de programación C, específicamente
|
||||||
|
con la variante C11 (ISO/IEC 9899:2011).
|
||||||
|
|
||||||
|
2. Utilizar sockets en modo no bloqueante multiplexada.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Enunciado [Pag. 2]
|
||||||
|
|
||||||
|
Trabajo Especial 2020/2 May 2022
|
||||||
|
|
||||||
|
|
||||||
|
3. Tener en cuenta todos los aspectos que hagan a la buena
|
||||||
|
performance, escalabilidad y disponibilidad del servidor. Se
|
||||||
|
espera que se maneje de forma eficiente los flujos de información
|
||||||
|
(por ejemplo no cargar en memoria mensajes muy grandes, ser
|
||||||
|
eficaz y eficiente en el intérprete de mensajes). El informe
|
||||||
|
DEBE contener información sobre las pruebas de stress. Algunas
|
||||||
|
preguntas interesantes a responder son:
|
||||||
|
|
||||||
|
* ¿Cual es la máxima cantidad de conexiones simultáneas que
|
||||||
|
soporta?
|
||||||
|
|
||||||
|
* ¿Cómo se degrada el throughput?
|
||||||
|
|
||||||
|
4. Seguir los lineamientos de IEEE Std 1003.1-2008, 2016 Edition /
|
||||||
|
Base definitions / 12. Utility Conventions [1] a menos que se
|
||||||
|
especifique lo contrario: Esto se refiere a cómo manejar
|
||||||
|
argumentos de línea de comandos, parámetros, etc
|
||||||
|
|
||||||
|
5. Deberá documentar detalladamente el protocolo de monitoreo y
|
||||||
|
configuración e implementar una aplicación cliente.
|
||||||
|
|
||||||
|
6. Tanto la aplicación servidor, como la aplicación cliente de
|
||||||
|
configuración/monitoreo DEBERÁN manejar los argumentos de línea
|
||||||
|
de comandos de cierta forma uniforme (por ejemplo -c <puerto>
|
||||||
|
podría especificar el puerto utilizado para el protocolo de
|
||||||
|
configuración/monitoreo). Los detalles de qué parámetros se
|
||||||
|
deben manejar será publicado en otro documento.
|
||||||
|
|
||||||
|
7. Si bien las programas son pequeños podrá utilizar librerías o
|
||||||
|
archivos (fragmento de código) desarrollados por terceros siempre
|
||||||
|
que se cumplan los siguientes requisitos:
|
||||||
|
|
||||||
|
A. La librería o fragmento NO DEBE resolver las cuestiones de
|
||||||
|
fondo del Trabajo Práctico.
|
||||||
|
|
||||||
|
B. La librería o fragmento DEBE tener una licencia aprobada por
|
||||||
|
la Open Source Initiative [2].
|
||||||
|
|
||||||
|
C. El uso de la librería o fragmento DEBE ser aprobada por la
|
||||||
|
Cátedra.
|
||||||
|
|
||||||
|
Para lograr la aprobación un alumno del grupo DEBE publicar una
|
||||||
|
secuencia en el foro de discusión del trabajo práctico. La
|
||||||
|
secuencia DEBE describir todos aquellos datos que permitan
|
||||||
|
identificar a la librería (por ejemplo la versión); su licencia
|
||||||
|
de esta forma justificando porqué es válido su uso; y el
|
||||||
|
propósito de su inclusión. En caso de que sea un fragmento de
|
||||||
|
código debe adjuntarse. Está permitido utilizar código publicado
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Enunciado [Pag. 3]
|
||||||
|
|
||||||
|
Trabajo Especial 2020/2 May 2022
|
||||||
|
|
||||||
|
|
||||||
|
por los docentes durante la cursada actual, siempre que se
|
||||||
|
atribuya correctamente.
|
||||||
|
|
||||||
|
8. A veces existirán ambigüedades en las especificaciones o
|
||||||
|
múltiples formas en como se puede resolver o implementar un
|
||||||
|
problema particular. Por ser una materia de ingeniería se espera
|
||||||
|
que los alumnos tomen decisiones de diseño razonables en estos
|
||||||
|
casos. Los alumnos pueden basar sus decisiones en lo que conoce
|
||||||
|
de ante mano de la tarea y en los objetivos enumerados en este
|
||||||
|
documento o demás enunciados. Los docentes pueden darle consejos
|
||||||
|
sobre las ventajas y desventajas de cada decisiones, pero los
|
||||||
|
alumnos son los que en última instancia las toman.
|
||||||
|
|
||||||
|
3. Evaluación
|
||||||
|
|
||||||
|
La realización del Trabajo Práctico es una actividad grupal. La
|
||||||
|
calificación es de carácter grupal; pero si hay evidencias de que un
|
||||||
|
alumno de un grupo no participó en la elaboración, o éste no puede
|
||||||
|
defender o demostrar su participación, entonces el alumno no podrá
|
||||||
|
aprobar el Trabajo Práctico. Se espera transparencia en el
|
||||||
|
desarrollo del trabajo (entregar el repositorio git).
|
||||||
|
|
||||||
|
Cada grupo DEBE entregar todo el material necesario para poder
|
||||||
|
reproducir el Trabajo Práctico. Como mínimo DEBE contener:
|
||||||
|
|
||||||
|
a. Un informe en formato PDF [RFC3778] o text/plain (con
|
||||||
|
codificación UTF-8) que contenga las siguientes secciones
|
||||||
|
(respetando el orden):
|
||||||
|
|
||||||
|
1. Índice
|
||||||
|
|
||||||
|
2. Descripción detallada de los protocolos y aplicaciones
|
||||||
|
desarrolladas.
|
||||||
|
|
||||||
|
3. Problemas encontrados durante el diseño y la implementación.
|
||||||
|
|
||||||
|
4. Limitaciones de la aplicación.
|
||||||
|
|
||||||
|
5. Posibles extensiones.
|
||||||
|
|
||||||
|
6. Conclusiones.
|
||||||
|
|
||||||
|
7. Ejemplos de prueba.
|
||||||
|
|
||||||
|
8. Guía de instalación detallada y precisa. No es necesario
|
||||||
|
desarrollar un programa instalador.
|
||||||
|
|
||||||
|
9. Instrucciones para la configuración.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Enunciado [Pag. 4]
|
||||||
|
|
||||||
|
Trabajo Especial 2020/2 May 2022
|
||||||
|
|
||||||
|
|
||||||
|
10. Ejemplos de configuración y monitoreo.
|
||||||
|
|
||||||
|
11. Documento de diseño del proyecto (que ayuden a entender la
|
||||||
|
arquitectura de la aplicación).
|
||||||
|
|
||||||
|
b. Códigos fuente y archivos de construcción
|
||||||
|
|
||||||
|
c. Un archivo README en la raíz que describa al menos:
|
||||||
|
|
||||||
|
A. la ubicación de todos los materiales previamente enumerados
|
||||||
|
|
||||||
|
B. el procedimiento necesario para generar una versión
|
||||||
|
ejecutable de las aplicaciones
|
||||||
|
|
||||||
|
C. la ubicación de los diferentes artefactos generados
|
||||||
|
|
||||||
|
D. cómo se debe ejecutar las diferentes artefactos generados (y
|
||||||
|
sus opciones)
|
||||||
|
|
||||||
|
La entrega se realizará por Campus ITBA en la asignación creada para
|
||||||
|
ello con una fecha de entrega. Se DEBE entregar un tarball que sea
|
||||||
|
el producto de clonar el repositorio GIT (por lo tanto el repositorio
|
||||||
|
GIT DEBE contener todos los materiales de entrega), y su historia.
|
||||||
|
|
||||||
|
Una vez realizada la entrega los grupos DEBERÁN mostrar el correcto
|
||||||
|
funcionamiento del sistema con casos de prueba provisto por los
|
||||||
|
equipos y provistos ese día por la Cátedra.
|
||||||
|
|
||||||
|
Para aprobar el Trabajo Práctico se DEBE cumplir TODAS las siguientes
|
||||||
|
condiciones:
|
||||||
|
|
||||||
|
o El material entregado DEBE estar completo (por ejemplo no se puede
|
||||||
|
corregir si falta el informe o alguna clase)
|
||||||
|
|
||||||
|
o Se utilizan únicamente las librería permitidas para los usos
|
||||||
|
definidos.
|
||||||
|
|
||||||
|
o DEBE ser correcta las cuestiones de entradas/salida no bloqueante.
|
||||||
|
Por ejemplo las lecturas, escrituras y el establecimiento de
|
||||||
|
nuevas conexiones DEBEN ser mediante suscripciones y no
|
||||||
|
bloquearse.
|
||||||
|
|
||||||
|
o DEBE ser correcta las cuestiones relacionadas a la lectura/
|
||||||
|
escrituras parciales.
|
||||||
|
|
||||||
|
o Sumar CUATRO puntos de calificación sobre DIEZ puntos posibles.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Enunciado [Pag. 5]
|
||||||
|
|
||||||
|
Trabajo Especial 2020/2 May 2022
|
||||||
|
|
||||||
|
|
||||||
|
Se aceptarán entregas tardías entre 0 horas (inclusive) y 24 horas
|
||||||
|
(exclusivo) luego de la fecha límite de entrega, pero la calificación
|
||||||
|
no podrá execeder de CUATRO puntos.
|
||||||
|
|
||||||
|
4. Referencias
|
||||||
|
|
||||||
|
4.1. Normative References
|
||||||
|
|
||||||
|
[RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and
|
||||||
|
L. Jones, "SOCKS Protocol Version 5", RFC 1928, March
|
||||||
|
1996.
|
||||||
|
|
||||||
|
[RFC1929] Leech, M., "Username/Password Authentication for SOCKS
|
||||||
|
V5", RFC 1929, DOI 10.17487/RFC1929, March 1996,
|
||||||
|
<https://www.rfc-editor.org/info/rfc1929>.
|
||||||
|
|
||||||
|
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||||
|
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||||
|
|
||||||
|
[RFC3778] Taft, E., Pravetz, J., Zilles, S., and L. Masinter, "The
|
||||||
|
application/pdf Media Type", RFC 3778,
|
||||||
|
DOI 10.17487/RFC3778, May 2004,
|
||||||
|
<http://www.rfc-editor.org/info/rfc3778>.
|
||||||
|
|
||||||
|
4.2. URIs
|
||||||
|
|
||||||
|
[1] https://pubs.opengroup.org/onlinepubs/9699919799/nframe.html
|
||||||
|
|
||||||
|
[2] https://opensource.org/licenses
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Enunciado [Pag. 6]
|
||||||
|
|
@ -0,0 +1,132 @@
|
||||||
|
.\" Macros
|
||||||
|
.ds PX \s-1POSIX\s+1
|
||||||
|
.de EXAMPLE .\" Format de los ejemplos
|
||||||
|
.RS 10
|
||||||
|
.BR "\\$1"
|
||||||
|
.RE
|
||||||
|
..
|
||||||
|
|
||||||
|
.TH socks5d 0.0.0 "24 de mayo 2022"
|
||||||
|
.LO 8
|
||||||
|
.SH NAME
|
||||||
|
socks5d \- proxy SOCKS versión 5 con esteroides
|
||||||
|
|
||||||
|
.SH SINOPSIS
|
||||||
|
.HP 10
|
||||||
|
.B socks5d
|
||||||
|
[ POSIX style options ]
|
||||||
|
|
||||||
|
.SH OPCIONES
|
||||||
|
|
||||||
|
.\".IP "\fB\-d\fB"
|
||||||
|
.\"Establece que debe ejecutar con la configuración predeterminada.
|
||||||
|
.\".IP
|
||||||
|
.\"Aquellos servidores donde la configuración sea persistente (el enunciado
|
||||||
|
.\"no lo requiere) presentan un desafío a la hora de realizar pruebas ya que
|
||||||
|
.\"se debe conocer la configuración actual.
|
||||||
|
.\".IP
|
||||||
|
.\"En esos casos esta opción olvida toda configuración previa y establece
|
||||||
|
.\"la configuración predeterminada.
|
||||||
|
.\".IP
|
||||||
|
.\"La configuración predeterminada consiste en tener apagada las transformaciones.
|
||||||
|
|
||||||
|
.IP "\fB-h\fR"
|
||||||
|
Imprime la ayuda y termina.
|
||||||
|
|
||||||
|
.IP "\fB\-l\fB \fIdirección-socks\fR"
|
||||||
|
Establece la dirección donde servirá el proxy SOCKS.
|
||||||
|
Por defecto escucha en todas las interfaces.
|
||||||
|
|
||||||
|
.IP "\fB\-N\fB"
|
||||||
|
Deshabilita los passwords disectors.
|
||||||
|
|
||||||
|
.IP "\fB\-L\fB \fIdirección-de-management\fR"
|
||||||
|
Establece la dirección donde servirá el servicio de
|
||||||
|
management. Por defecto escucha únicamente en loopback.
|
||||||
|
|
||||||
|
.IP "\fB\-p\fB \fIpuerto-local\fR"
|
||||||
|
Puerto TCP donde escuchará por conexiones entrantes SOCKS.
|
||||||
|
Por defecto el valor es \fI1080\fR.
|
||||||
|
|
||||||
|
.IP "\fB\-P\fB \fIpuerto-conf\fR"
|
||||||
|
Puerto SCTP donde escuchará por conexiones entrante del protocolo
|
||||||
|
de configuración. Por defecto el valor es \fI8080\fR.
|
||||||
|
|
||||||
|
.IP "\fB\-u\fB \fIuser:pass\fR"
|
||||||
|
Declara un usuario del proxy con su contraseña. Se puede utilizar
|
||||||
|
hasta 10 veces.
|
||||||
|
|
||||||
|
|
||||||
|
.IP "\fB\-v\fB"
|
||||||
|
Imprime información sobre la versión versión y termina.
|
||||||
|
|
||||||
|
.SH REGISTRO DE ACCESO
|
||||||
|
|
||||||
|
Registra el uso del proxy en salida estandar. Una conexión por línea. Los campos de una
|
||||||
|
línea separado por tabs:
|
||||||
|
|
||||||
|
.IP "\fBfecha\fR"
|
||||||
|
que se procesó la conexión en formato ISO-8601.
|
||||||
|
Ejemplo 2022-06-15T19:56:34Z.
|
||||||
|
|
||||||
|
.IP "\fBnombre de usuario\fR"
|
||||||
|
que hace el requerimiento.
|
||||||
|
Ejemplo juan.
|
||||||
|
|
||||||
|
.IP "\fBtipo de registro\fR"
|
||||||
|
Siempre el caracter A.
|
||||||
|
|
||||||
|
.IP "\fBdireccion IP origen\fR"
|
||||||
|
desde donde se conectó el usuario.
|
||||||
|
Ejemplo ::1.
|
||||||
|
|
||||||
|
.IP "\fBpuerto origen\fR"
|
||||||
|
desde donde se conectó el usuario.
|
||||||
|
Ejemplo 54786.
|
||||||
|
|
||||||
|
.IP "\fBdestino\fR"
|
||||||
|
a donde nos conectamos. nombre o dirección IP (según ATY).
|
||||||
|
Ejemplo www.itba.edu.ar.
|
||||||
|
Ejemplo ::1.
|
||||||
|
|
||||||
|
.IP "\fBpuerto destino\fR" a donde nos conectamos.
|
||||||
|
Ejemplo 443.
|
||||||
|
|
||||||
|
.IP "\fBstatus\fR" status SOCKS (0 exito, ...)
|
||||||
|
Status code de SOCKSv5. Ejemplo 0.
|
||||||
|
|
||||||
|
|
||||||
|
.SH REGISTRO DE PASSWORDS
|
||||||
|
|
||||||
|
Registra las credenciales descubiertas en salida estandar. Una credencial por línea.
|
||||||
|
Los campos de una línea separados por tabs:
|
||||||
|
|
||||||
|
.IP "\fBfecha\fR"
|
||||||
|
que se procesó la conexión en formato ISO-8601.
|
||||||
|
Ejemplo 2020-06-15T19:56:34Z.
|
||||||
|
|
||||||
|
.IP "\fBnombre de usuario\fR"
|
||||||
|
que hace el requerimiento.
|
||||||
|
Ejemplo juan.
|
||||||
|
|
||||||
|
.IP "\fBtipo de registro\fR"
|
||||||
|
Siempre el caracter P.
|
||||||
|
|
||||||
|
|
||||||
|
.IP "\fBprotocolo\fR"
|
||||||
|
Protocolo del que se trata. HTTP o POP3.
|
||||||
|
|
||||||
|
.IP "\fBdestino\fR"
|
||||||
|
a donde nos conectamos. nombre o dirección IP (según ATY).
|
||||||
|
Ejemplo www.itba.edu.ar.
|
||||||
|
Ejemplo ::1.
|
||||||
|
|
||||||
|
.IP "\fBpuerto destino\fR" a donde nos conectamos.
|
||||||
|
Ejemplo 443.
|
||||||
|
|
||||||
|
.IP "\fBusuario\fR"
|
||||||
|
Usuario descubierto.
|
||||||
|
|
||||||
|
.IP "\fBpassword\fR"
|
||||||
|
Password descubierta.
|
||||||
|
|
||||||
|
|
@ -0,0 +1,28 @@
|
||||||
|
#ifndef ARGS_H
|
||||||
|
#define ARGS_H
|
||||||
|
|
||||||
|
#include <stdbool.h>
|
||||||
|
|
||||||
|
#define MAX_USERS 500
|
||||||
|
|
||||||
|
struct users {
|
||||||
|
char *name;
|
||||||
|
char *pass;
|
||||||
|
};
|
||||||
|
|
||||||
|
struct socks5args {
|
||||||
|
char *socks_addr;
|
||||||
|
unsigned short socks_port;
|
||||||
|
|
||||||
|
char * mng_addr;
|
||||||
|
unsigned short mng_port;
|
||||||
|
|
||||||
|
bool disectors_enabled;
|
||||||
|
|
||||||
|
struct users users[MAX_USERS];
|
||||||
|
};
|
||||||
|
|
||||||
|
void parse_args(const int argc, char **argv, struct socks5args *args);
|
||||||
|
|
||||||
|
#endif
|
||||||
|
|
||||||
|
|
@ -0,0 +1,6 @@
|
||||||
|
#ifndef CLIENT_H
|
||||||
|
#define CLIENT_H
|
||||||
|
|
||||||
|
#include <stdio.h>
|
||||||
|
|
||||||
|
#endif
|
||||||
|
|
@ -0,0 +1,8 @@
|
||||||
|
#ifndef SERVER_H
|
||||||
|
#define SERVER_H
|
||||||
|
|
||||||
|
#include <stdio.h>
|
||||||
|
#include <stdlib.h>
|
||||||
|
#include "args.h"
|
||||||
|
|
||||||
|
#endif
|
||||||
|
|
@ -0,0 +1,119 @@
|
||||||
|
#include <stdio.h>
|
||||||
|
#include <stdlib.h>
|
||||||
|
#include <limits.h>
|
||||||
|
#include <string.h>
|
||||||
|
#include <errno.h>
|
||||||
|
#include <getopt.h>
|
||||||
|
|
||||||
|
#include "../include/args.h"
|
||||||
|
|
||||||
|
static unsigned short port(const char *s) {
|
||||||
|
char *end = 0;
|
||||||
|
const long sl = strtol(s, &end, 10);
|
||||||
|
|
||||||
|
if (end == s || '\0' != *end || ((LONG_MIN == sl || LONG_MAX == sl) && ERANGE == errno) || sl < 0 || sl > USHRT_MAX) {
|
||||||
|
fprintf(stderr, "Port should be in the range of 1-65536: %s\n", s);
|
||||||
|
exit(1);
|
||||||
|
return 1;
|
||||||
|
}
|
||||||
|
return (unsigned short) sl;
|
||||||
|
}
|
||||||
|
|
||||||
|
static void user(char *s, struct users *user) {
|
||||||
|
char *p = strchr(s, ':');
|
||||||
|
if (p == NULL) {
|
||||||
|
fprintf(stderr, "Password not found\n");
|
||||||
|
exit(1);
|
||||||
|
} else {
|
||||||
|
*p = 0;
|
||||||
|
p++;
|
||||||
|
user->name = s;
|
||||||
|
user->pass = p;
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
static void version(void) {
|
||||||
|
fprintf(stderr, "BProxy v0.0\nITBA Protocolos de Comunicación 2021/1 -- Grupo 7\nVer LICENSE.md\n");
|
||||||
|
}
|
||||||
|
|
||||||
|
static void usage(const char *progname) {
|
||||||
|
fprintf(stderr,
|
||||||
|
"Usage: %s [OPTION]\n\n"
|
||||||
|
" -h Imprime la ayuda y termina.\n"
|
||||||
|
" -l <SOCKS addr> Dirección donde servirá el proxy SOCKS.\n"
|
||||||
|
" -L <conf addr> Dirección donde servirá el servicio de management.\n"
|
||||||
|
" -p <SOCKS port> Puerto entrante conexiones SOCKS.\n"
|
||||||
|
" -P <conf port> Puerto entrante conexiones configuracion.\n"
|
||||||
|
" -u <name>:<pass> Usuario y contraseña de usuario que puede usar el proxy. Hasta 500.\n"
|
||||||
|
" -v Imprime información sobre la versión y termina.\n\n",
|
||||||
|
progname);
|
||||||
|
exit(1);
|
||||||
|
}
|
||||||
|
|
||||||
|
void parse_args(const int argc, char **argv, struct socks5args *args) {
|
||||||
|
memset(args, 0, sizeof(*args));
|
||||||
|
|
||||||
|
args->socks_addr = "0.0.0.0";
|
||||||
|
args->socks_port = 1080;
|
||||||
|
|
||||||
|
args->mng_addr = "127.0.0.1";
|
||||||
|
args->mng_port = 8080;
|
||||||
|
|
||||||
|
args->disectors_enabled = true;
|
||||||
|
|
||||||
|
int c;
|
||||||
|
int nusers = 0;
|
||||||
|
|
||||||
|
while (true) {
|
||||||
|
c = getopt(argc, argv, "hl:L:Np:P:u:v");
|
||||||
|
if (c == -1)
|
||||||
|
break;
|
||||||
|
|
||||||
|
switch (c) {
|
||||||
|
case 'h':
|
||||||
|
usage(argv[0]);
|
||||||
|
break;
|
||||||
|
case 'l':
|
||||||
|
args->socks_addr = optarg;
|
||||||
|
break;
|
||||||
|
case 'L':
|
||||||
|
args->mng_addr = optarg;
|
||||||
|
break;
|
||||||
|
case 'N':
|
||||||
|
args->disectors_enabled = false;
|
||||||
|
break;
|
||||||
|
case 'p':
|
||||||
|
args->socks_port = port(optarg);
|
||||||
|
break;
|
||||||
|
case 'P':
|
||||||
|
args->mng_port = port(optarg);
|
||||||
|
break;
|
||||||
|
case 'u':
|
||||||
|
if(nusers >= MAX_USERS) {
|
||||||
|
fprintf(stderr, "Maximun number of command line users reached: %d.\n", MAX_USERS);
|
||||||
|
exit(1);
|
||||||
|
} else {
|
||||||
|
user(optarg, args->users + nusers);
|
||||||
|
nusers++;
|
||||||
|
}
|
||||||
|
break;
|
||||||
|
case 'v':
|
||||||
|
version();
|
||||||
|
exit(0);
|
||||||
|
break;
|
||||||
|
default:
|
||||||
|
fprintf(stderr, "unknown argument %d.\n", c);
|
||||||
|
exit(1);
|
||||||
|
}
|
||||||
|
|
||||||
|
}
|
||||||
|
|
||||||
|
if (optind < argc) {
|
||||||
|
fprintf(stderr, "Argument not accepted: ");
|
||||||
|
while (optind < argc) {
|
||||||
|
fprintf(stderr, "%s ", argv[optind++]);
|
||||||
|
}
|
||||||
|
fprintf(stderr, "\n");
|
||||||
|
exit(1);
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
@ -0,0 +1,7 @@
|
||||||
|
// This is a personal academic project. Dear PVS-Studio, please check it.
|
||||||
|
// PVS-Studio Static Code Analyzer for C, C++ and C#: http://www.viva64.com
|
||||||
|
#include "../include/client.h"
|
||||||
|
|
||||||
|
int main(int argc, char *argv[]) {
|
||||||
|
|
||||||
|
}
|
||||||
|
|
@ -0,0 +1,8 @@
|
||||||
|
// This is a personal academic project. Dear PVS-Studio, please check it.
|
||||||
|
// PVS-Studio Static Code Analyzer for C, C++ and C#: http://www.viva64.com
|
||||||
|
#include "../include/server.h"
|
||||||
|
|
||||||
|
int main(int argc, char *argv[]) {
|
||||||
|
struct socks5args * args = malloc(sizeof(struct socks5args));
|
||||||
|
parse_args(argc, argv, args);
|
||||||
|
}
|
||||||
Loading…
Reference in New Issue