Source: https://bytelearning.blogspot.com/2016/09/
Timestamp: 2018-04-20 16:12:27+00:00

Document:
Bytelearning | Un blog centrado principalmente en Linux Bytelearning: septiembre 2016
En más de una ocasión he hablado de la importancia de la salvaguarda de datos y de diferentes métodos de prevención de borrados accidentales o recuperación de datos; tales como el uso del shred para borrar del todo un archivo o de cómo evitar que el comando rm sea tan "destructivo". Ambos conceptos son muy útiles en determinadas circunstancias, pero imaginemos que no hemos aplicado ningún método de prevención para que rm no borre como lo hace habitualmente, es decir que hemos ejecutado el comando rm y que éste ha hecho lo que debe, es decir borrar el archivo o al menos hacer que este no sea un recurso accesible... Los bytes de dicho archivo siguen estando allí a menos que sean sobrescritos, con lo que en caso de que un archivo haya sido borrado recientemente, tenemos altas posibilidades de recuperarlo, cosa que haremos en este artículo de hoy... Hay dos herramientas particularmente famosas que realizan tareas de recuperación; una de ellas es llamada photorec, mientras que la otra, que ha ido ganando popularidad estos últimos años, se trata de de foremost.
Foremost es una herramienta basada en consola cuya principal virtud es su facilidad de uso pues apenas requiere de curva de aprendizaje alguna... Además
y si bien no es una utilidad que se encuentre instalada por defecto en el sistema, se puede instalar muy rápidamente mediante los repositorios oficiales tal que así:
Esta instalación incluirá todos los binarios necesarios para la recuperación de archivos, binarios que usarán una técnica llamada File Carving, que buscará archivos que hayan sido "eliminados" de la indexación del disco duro pero que físicamente se encuentre presentes en el disco, siempre y cuando éstos se encuentre íntegros; es por eso que cuanto más reciente haya sido la eliminación del archivo, más posibilidades habrán de que el archivo sea recuperado. Los formatos de archivo soportados son: jpg, gif, png, bmp, exe, rar, riff, wmv, mov, pdf, ole, doc, zip, htm y cpp; con lo que generalmente tendremos bastantes posibilidades de poder recuperar el archivo borrado en cuestión, si bien obviamente podemos tener la mala suerte de haber borrado un fichero en un formato "no reconocido".
A la hora de usar esta herramienta hay una recomendación muy importante, que es que el destino donde se guarde el archivo restaurado se guarde en una partición diferente a la del origen; es decir que si hemos borrado un archivo en un la partición /dev/sda1, lo suyo sería restaurarlo en una partición diferente que puede ser perfectamente una unidad USB, por ejemplo.
Imaginemos que cumplimos todas las recomendaciones; es decir que hemos borrado uno o varios ficheros y que tenemos una partición diferente a mano... Para ponerlo en un caso real, supongamos que teníamos varios archivos en un USB y que los hemos borrado y que deseamos restaurarlos en nuestro disco duro; la unidad USB siempre se encuentra en una partición distinta, con lo que jamás causaría conflicto con el resto, ya sea como partición de origen o de destino. Generalmente el disco duro sería /dev/sda1 y la unidad USB /dev/sdb1.
Para realizar esa restauración lo primero que haríamos sería crear un directorio donde almacenar nuestros archivos recuperados; tal y como hemos dicho antes, el destino de restauración sería el disco duro con lo que crearíamos un directorio en este. Un directorio de ejemplo podría llamarse recuperado, con lo que crearemos un directorio tal que así:
mkdir /tmp/recuperado
El destino estaría preparado, solamente quedaría conocer el origen, que sería el USB. Simplemente habría que conectar el USB y conocer el nombre de su "partición" escribiendo el comando:
Ahí aparecerán todas las particiones, incluyendo por supuesto nuestro USB... En nuestro caso sería /dev/sdb1
Con todos los requisitos cumplidos, lo primero que habría que conocer es la estructura usada en foremost, la cual es muy sencilla:
foremost -t ${formato} -i ${origen} -o {destino}
Al hacer referencia al formato estaríamos diciendo si queremos recuperar los archivos de un formato en concreto o no... En caso de querer recuperar todos los archivos de todos los formatos disponibles, simplemente habría que poner all en el formato de recuperación, cosa que se suele hacer a menudo. En caso de querer poner un formato en concreto simplemente habría que poner uno de los mencionados anteriormente, tales como jpg, gif, rar... Para nuestro caso en concreto el comando de recuperación sería:
foremost -t all -i /dev/sdb1 -o /tmp/recuperado
El comando tardará cierto tiempo en realizar el proceso de recuperación, tiempo que generalmente variará dependiendo del tamaño del origen... Pasados unos minutos, el proceso finalizará y simplemente tendremos que desplazarnos al directorio de destino para disfrutar de nuestro contenido recuperado; aquí veremos que se han creado diferentes subdirectorios, uno por cada formato distinto que se ha restaurado, además de un fichero llamado audit.txt que contiene toda la información resumida de los ficheros restaurados . En mi caso por ejemplo tengo el siguiente listado:
Cada directorio tendrá sus correspondientes ficheros, pero veréis que, desgraciadamente el nombre de cada uno de éstos es ininteligible... Esto se debe a que, cuando se borra el archivo, su nombre pasa a ser su número de inodo, tal y como también ocurre con los archivos recuperados en lost+found. Aún así, esto no supone un problema demasiado grande, pues estos ficheros conservan sus metadatos, con lo que si consultamos cualquier de los ficheros con la utilidad exiftool, podremos datos muy informativo, entre ellos su título, el cual nos dará una idea muy aproximada de las características del fichero, tal y como podemos ver en el fichero de a continuación:
Gracias a la combinación de estas dos herramientas: Foremost y exiftool; la recuperación de archivos borrados es muy sencilla, y si bien obviamente la efectividad de esta técnica depende en gran parte de que los bytes del fichero no se hayan sobrescrito, podemos recuperar archivos borrados recientemente sin demasiadas complicaciones.
en viernes, septiembre 30, 2016 2 comentarios :
Etiquetas: Forense , Howto , Linux , Seguridad , Shell
Sacando partido a nuestra tarjeta de red con ethtool
Linux siempre ha destacado por su versatilidad y por la libertad que le ofrece a uno para cambiar lo que desee, ya sea a nivel de código fuente o configuración. Entre todas estas libertades, obviamente tenemos también la libertad de modificar el comportamiento de nuestra tarjeta de red... Algo poco común, pero que puede sernos de una enorme utilidad en algunos casos específicos en los que por algún motivo u otro la tarjeta de red no actúa como nosotros queremos... La velocidad del enlace nos la adecuada, la conexión no es Full Duplex, no detecta el enlace, etc... Generalmente con usar las herramientas clásicas como ping, traceroute e ifconfig, podemos solucionar los errores más comunes, pero a veces necesitamos tener información más detallada o "tunear" la tarjeta de red y para ello tendremos que usar una utilidad más avanzada; una utilidad llamada ethtool.
Ethtool es una herramienta que nos permite obtener información de nuestra tarjeta de red, de nuestro enlace y, lo más importante de todo, es que nos permite modificar ciertos parámetros para adaptarlos lo mejor posible a nuestra conexión; obviamente la herramienta no siempre nos dejará hacer todo lo que queramos, pero sí que nos permite tener cierta flexibilidad de la que generalmente careceríamos.
Comencemos con el uso más básico de ethtool, que sería la obtención de la información general de la tarjeta de red; algo tan sencillo como hacer:
ethtool $interfaz_de_red
Esto significaría que si quisiésemos hacer referencia a la interfaz de red más común de todas, es decir eth0, escribiríamos:
El resultado obtenido variaría dependiendo de la interfaz de red que tengamos, del tipo de conexión, de si el comando es realizado sobre una máquina virtual, el tipo de máquina virtual, etc... Pero un resultado de ejemplo sería:
Esta información está especialmente orientada al enlace entre el equipo y el router/switch (u otro equipo), pero a veces deseamos tener información del driver, información que con el comando lspci no nos es suficiente. En este caso habría que añadir el parámetro -i antes de especificar la interfaz de red.
Otro dato muy interesante que podemos obtener de la interfaz de red es el de un listado de estadísticas que mostrarían la cantidad de bytes enviados, recibidos y el tipo de éstos... Esta información puede parecer superflua, pero nos puede dar una pista sobre el tráfico generado a través de esta interfaz... Por ejemplo no tiene sentido que una interfaz de red que, supuestamente, está pensada para la gestión del equipo vía SSH, genere tráfico multicast, cosa que gracias a esta herramienta podríamos saberlo sin requerir el uso de Wireshark. Esto lo lograríamos mediante el parámetro -S.
Pero con esto no tendríamos suficiente... Conocer las características de la tarjeta y del enlace de ésta está muy bien, pero es mucho más útil modificarla a nuestro gusto para que se adapte a nuestras necesidades. Todo cambio realizado por ethtool, requiere del uso del parámetro -s (minúscula), tras el cual se pueden indicar qué parámetros deseamos cambiar. Aquí los cambios que se pueden hacer son varios y suelen estar estrechamente vinculados con los mostrados mediante la orden básica de ethtool (es decir ethtool $interfaz_de_red), con lo que antes de mostraros un par de ejemplos vamos a ver algunos de los parámetros más populares:
speed: Probablemente el parámetro más veces modificado de todos. Determina la velocidad de la conexión, la cual es establecida en megabytes por segundo; La velocidad varía dependiendo de la tarjeta de red; algunas soportan 10, otras 100 e incluso hay tarjetas de red que soportan 1000 o incluso 10000 megabytes por segundo, con lo que dependiendo de la capacidad de nuestra tarjeta podremos seleccionar una velocidad u otra. Para saber las velocidades que soporta nuestra tarjeta (y las velocidades que podemos escoger), tendremos que revisar los parámetros Supported link modes (que nos dirá la velocidad a la que puede trabajar la tarjeta de red) y Advertised Link modes (que nos dirá qué tipo de velocidad podemos especificar, pues a veces el switch/dispositivo al que estamos conectado no soporta las mismas velocidades que nosotros). Ambos parámetros pueden ser consultados mediante el uso del comando básico de ethtool. Para especificar la velocidad simplemente habría que poner speed, seguido de la velocidad; Ejemplo: ethtool -s eth0 speed 100.
port: Un parámetro que tiene bastante importancia en las conexiones es el tipo de puerto que se especifica en la interfaz de red al realizar una conexión. Generalmente este parámetro es "negociado" automáticamente cuando se conectan dos máquinas, pero a veces queremos optar por una opción más "artesanal". Los tipos de puerto que podemos especificar son:
tp: Un enlace de red usando un cable de Ethernet del tipo Twisted Pair (el enlace más común).
aui: Un enlace del tipo Attachment Unit Interface, que es el que se realizaría con un HUB.
bnc: Una conexión Ethernet que usa conectores BNC y cable coaxial (es poco común, pero la opción en sí existe).
mii: Una conexión de red usando Media Independent Interface (muy poco usado).
fibre: Como su propio nombre indica, haría que la conexión fuese de Ethernet si bien el enlace sería del tipo fibra óptica; lo cual generalmente se logra a través de adaptadores.
Ejemplo: ethtool -s eth0 port tp.
duplex: A veces queremos que el enlace actué de una manera distinta la "habitual"; es decir que la conexión sea half duplex, en vez de full duplex y viceversa. Esta información se obtiene también mediante el uso básico de ethtool y para cambiar dicho parámetro simplemente tendremos que poner duplex, seguido de half (para half duplex) o full (para full duplex). Ejemplo: ethtool -s eth0 duplex full.
autoneg: Otro de los grandes "favoritos" cuando queremos modificar un parámetro. Este parámetro establece si la autonegociación del enlace está activa o no... ¿Qué significa ésto? Que si tenemos la tarjeta de red sin conectar a ningún sitio y realizamos la conexión, los parámetros speed y port serán "negociados" automáticamente entre ambas partes, ignorando cualquier "manualidad" que hayamos realizado antes con ethtool; es por ello que generalmente se desactiva la autonegociación cuando hacemos uso de ethtool. El parámetro autoneg se puede establecer a on o a off; es decir que únicamente se activar o desactivar dicha opción. Ejemplo: ethtool -s eth0 autoneg off.
Existen más parámetros a modificar, pero los mencionados serían los más "conocidos" o importantes. Obviamente son perfectamente combinables entre sí y podemos crear modificaciones tales como las siguientes:
#Cambio de velocidad a 100 megabytes por segundo y autonegociación a off
ethtool -s speed 100 autoneg off
#Cambio de puerto y de tipo de enlace a uno adaptado para HUBS
ethtool -s duplex half port aui
#Establecer a mano todos los parámetros
ethtool -s speed 1000 duplex full port tp autoneg off
Por último hay un comando de ethtool que, si bien no es "indispensable", si que lo podríamos considerar como curioso. Imaginemos que tenemos varias interfaces de red; cada una con una ip estática configurada y perfectamente preparada para dar servicio pero que no sabemos qué puerto físico corresponde a cada interfaz debido a que se nos ha olvidado o debido a que la ubicación de los puertos físicos no da una información demasiada intuitiva. Una opción sería coger un cable de red e ir testeando puerto por puerto, pero nos podemos ahorrar dicha tarea haciendo que el puerto de red parpadee gracias a ethtool. Simplemente sería necesario usar ethtool seguido de parámetro -p y el nombre de la interfaz de red... La tarjeta de red parpadearía constantemente hasta que finalizásemos el comando pulsando ctrl + c.
Como podéis ethtool es una herramienta con un alto grado de flexibilidad que puede ayudarnos a ajustar nuestra tarjeta de red para que se adapte lo mejor posible a nuestras respectivas necesidades, convirtiéndose en una herramienta muy a tener en cuenta.
en lunes, septiembre 26, 2016 No hay comentarios :
Etiquetas: Howto , Internet , Linux , Networking , Shell
Pequeña vuelta de tuerca a la monitorización de USBs en Linux
Hace relativamente poco, publiqué en este blog un pequeño artículo en referencia a la monitorización de USBs en Wireshark; el artículo le pareció interesante a un conocido mío, el cual me hizo un par de preguntas al respecto, especialmente a nivel de hasta qué punto la monitorización de un USB puede ser visible o no de cara al usuario final... La pregunta en sí me pareció interesante, pues si bien mi artículo estaba diseñado con fines claramente benignos, todo conocimiento y/o herramienta suele ser un arma de doble filo, tanto en el ámbito de la informática como en otras áreas. A raíz de allí me pregunté: ¿Y si el tráfico USB fuese sniffeado en un segundo plano? ¿Y sí por ejemplo alguien conectase un USB a un puerto en escucha sin qué este se diese cuenta?
Pensando sobre dicho concepto me acordé de uno de los homólogos de Wireshark, cuya compatibilidad con éste es bastante alta con la diferencia de que es mucho menos visual e intuitivo que la archiconocida herramienta: Tcpdump. Esta herramienta, cuya utilidad es incalculable en entornos sin interfaz gráfica, es un sniffer con la capacidad de capturar el tráfico tal y como hace Wireshark; si bien tiene como pega que la lectura de los datos capturados no es tan intuitiva como en su "hermano". Aún así no deja de ser una gran herramienta, y además los datos capturados aquí pueden ser leídos por Wireshark, así que los problemas de lectura que tiene la herramienta se puede considerar como un mal menor. Supongamos que, hemos seguido los mismos pasos que en el anterior artículo, a excepción de que, obviamente, en este caso no habremos ejecutado Wireshark. La captura del tráfico generado por el USB se podría realizar mediante este simple comando:
sudo tcpdump -i usbmon1 -w /tmp/usb.cap
Con esto ya estaríamos capturando todo aquello que entrase por usbmon1, sin importar si hay un USB conectado o no. En este caso lo hemos hecho en la propia terminal y estaríamos viendo la captura en pantalla; captura que se estaría volcando en /tmp/usb.cap, pero que en cualquier momento puede cancelarse enviándole la señal de parado de proceso mediante ctrl + C. Obviamente esto es fácilmente modificable y podemos darle una pequeña vuelta de tuerca para que no solo el proceso se ejecute en segundo plano, sino que además el proceso no se cierre ni siquiera al cerrar la sesión activa; es decir que no se cierre hasta que reiniciemos el equipo.
Por otro lado, también podemos hacer que se ejecute como script de arranque. Ambos casos quedarían representados de la siguiente forma:
Para ejecutarlo en segundo plano y que no se detenga a menos que reiniciemos el equipo:
sudo nohup tcpdump -i usbmon1 -w /tmp/usb.cap &
En caso de querer hacer que se ejecute en cada arranque, simplemente tendríamos que añadir un script en /etc/init.d/ con el siguiente contenido:
# usbsniff init.d script
# Provides: usbsniff
# Required-Start: $local_fs $remote_fs $time
# Required-Stop: $local_fs $remote_fs $time
# Short-Description: tcpdump para USB
# Description: Sniffer del trafico USB
tcpdump -i usbmon1 -w /tmp/usb.cap &
Después habría que hacer que el script se iniciase en el arranque; cosa que, si por ejemplo el script se llamase usbsniff.sh, haríamos tal que así:
insserv usbsniff.sh
Esto resultad interesante a nivel didáctico, pero al mismo tiempo resulta peligroso, pues el tráfico capturado se estaría guardando en un fichero que podría leerse con tranquilidad en un futuro sin que nosotros tuviésemos consciencia alguna sobre ello... ¿Eso significa que debemos temer por la "intimidad" del tráfico de nuestro USB en caso de conectarlo a un equipo con Linux? En mi opinión personal sí y no. Es cierto que el método existe y qué puede suponer una "fuga" de información, pero también es verdad que la captura de dicho tráfico no es excesivamente común, con lo que es bueno ser precavidos sin caer dentro de una actitud obsesiva.
Ahora la pregunta obvia sería ¿Hay alguna forma de mitigarlo o evitarlo? En parte sí, si bien nuestra maniobrabilidad dependería de los permisos de nuestro usuario. En caso de ser un usuario sin ningún tipo de privilegios, la mejor forma de saber si podemos estar si nuestro USB está siendo monitorizado sería mediante el uso de los comandos ps y lsmod.
ps -e |grep tcpdump
lsmod |grep usbmon
En caso de que los dos comandos mostrasen algún resultado, lo aconsejable sería desconectar inmediatamente el USB, pues habrían unas altas posibilidades de que nuestro USB estuviese siendo "espiado". Desgraciadamente, al ser un usuario "normal", no tendríamos la capacidad de hacer nada más, pues cualquier tipo de acción que implicase detener el proceso tcpdump y el módulo usbmon, requeriría privilegios de administrador.
En caso de tener privilegios de administrador, en vez de optar por desconectar el USB, podemos detener el "espionaje" al que está sometido el USB. Para ello, lo único que habría que hacer sería escribir el comando killall con el que detendríamos el proceso tcpdump:
sudo killall -9 tcpdump
Con el proceso detenido, con el fin de asegurarnos de que usbmon no seguirá presente (al menos durante la sesión actual) podemos deshabilitar el módulo en cuestión. Es importante detener el proceso tcpdump primero, pues en caso contrario nos dirá que el módulo está en uso y que no es posible deshabilitarlo.
Con esto ya podríamos consultar el contenido del USB con tranquilidad, sin temor a que su tráfico esté siendo monitorizado.
Como podéis ver el sniffeado del tráfico de un USB sin que el usuario final se percate de ello, se puede realizar con mucha facilidad; afortunadamente las contramedidas que se pueden tomar contra esta acción son sencillas y efectivas.
en martes, septiembre 20, 2016 No hay comentarios :
Etiquetas: Bash , Forense , Linux , Seguridad , Shell
El tener un equipo expuesto en la red se ha convertido en una práctica cada vez más extendida, y obviamente ello a hecho que también se convierta en una práctica cada vez más peligrosa. Los cybercriminales no cesan de intentar vulnerar diferentes servicios expuestos en la red: HTTP, SSH, Asterisk, telnet, FTP... Generalmente uno piensa ¿Quien va a querer hackearme a mí? Pero hemos de tener en cuenta que hay una gran cantidad de ataques que son efectuados por herramientas automáticas que simplemente buscan IPs en la red e intentan acceder a ciertos servicios de éstas, indistintamente de si se es un particular o una empresa. Las técnicas de ataque van evolucionando con el tiempo, siendo cada vez más sutiles y efectivas, con lo cual las defensas tienen que ser equiparables para poder salvaguardar los servicios expuestos en Internet. Una buena medida es bloquear el acceso dependiendo del país de origen de la conexión.
Generalmente deseamos que todo el mundo pueda acceder a nuestro contenido desde cualquier origen, especialmente si hablamos de una web, pero hay ciertos países que tienen fama por realizar cyber-intrusiones en sistemas ajenos y que dependiendo del contenido o idioma de nuestra web, no tiene sentido que accedan; me explico: Este blog está escrito en castellano al 100% y si bien es uno de los idiomas más hablados del mundo, hay países que por un lado tienen fama por vulnerar sistemas informáticos, y que por otro lado poseen una tasa muy baja de hispanohablantes, por no decir que casi nula. Dos de esos países que tienen un gran fama por cumplir ambas condiciones serían Rusia y China, con lo que ver conexiones con dichos países de origen sería bastante inusual... Es más, hay varios sitios que, estén el idioma en el que estén, suelen bloquear esos países debido a su alta tasa de ataques cybernéticos, cosa que es más sencilla de lo que parece gracias a una combinación de iptables y xtables_addons.
Xtables_addons son una serie de complementos que se aplican sobre el kernel y que hacen que iptables tenga un mayor número de funcionalidades de las que ya de por sí traen (que no son pocas). Estos complementos se pueden instalar directamente gracias a los repositorios oficiales del sistema escribiendo lo siguiente:
apt-get install libtext-csv-xs-perl xtables-addons-common xtables-addons-dkms
Esto hará que instalemos todas las dependencias necesarias para poder usar los addons, en concreto uno de ellos que nos interesa especialmente llamado GeoIP y que asocia unos rangos de IPs con sus respectivos países. Aún así, si bien la funcionalidad está preparada, no contiene dato alguno con el que poder reconocer qué ip está asociada a qué país; es por eso que lo primero que tendremos que hacer será descargarnos la base de datos que contiene dicha información; base de datos que no tendremos que descargarnos desde ninguna web, sino que podemos descargarnos desde un script:
Este proceso nos descargará un fichero en formato .csv llamado GeoIPCountryWhois.csv que contendrá toda la información; el problema radica en qué dicha información no es reconocible por iptables ni por xtables_addons, y es por ello es necesario hacerla "legible" para ambas herramientas. Para ello primero hay que crear un directorio llamado LE dentro del directorio /usr/share/xt_geoip para después ejecutar el comando que hará el csv legible y que hará que la información correspondiente se guarde dentro del directorio que hemos creado:
mkdir /usr/share/xt_geoip/LE
/usr/lib/xtables-addons/xt_geoip_build -D /usr/share/xt_geoip/ GeoIPCountryWhois.csv
Este proceso mostrará una salida en la que se verán los países junto con el número de IPs asociados a éstas, IPs que pueden ser tanto IPv4 como IPv6... El listado mostrado es enorme, pero he aquí un pequeño extracto para que os hagáis una idea de la salida del último comando:
Ahora tanto iptables como xtables son perfectamente capaces de asociar las IPs a sus respectivos países, con lo que llegaría el turno de añadir nuevos filtros que nos proporcionen cierta seguridad. En este caso nos encargaremos de filtrar tanto los proxies anónimos como los países Rusia y China. Para ello combinaremos las reglas habituales de iptables junto con las características especiales ofrecidas por los addons instalados. Toda regla que incluya la característica GeoIP, tendrá las siguiente estructura básica:
iptables -A INPUT -m geoip --src-cc $SIGLAS_ORIGEN -j $ACCION
Al hacer referencia a las siglas del origen, estaríamos haciendo referencia al origen de la conexión. Por ejemplo los proxies anónimos tendrían las siglas "A1", mientras que china tendría las siglas "CN". La acción a tomar quedaría a nuestra elección, pero generalmente sería o ACCEPT (para aceptar la conexión de dicho origen) y DROP (denegar dicho acceso). Partiendo de la base de que vamos a aceptar las conexiones de todos lados a excepción de unos lugares concretos usaremos la acción DROP para el ejemplo de a continuación.
iptables -A INPUT -p tcp --dport 21:23 -m geoip --src-cc A1 -j DROP
iptables -A INPUT -m geoip --src-cc CN-j DROP
iptables -A INPUT -p udp --dport 5060 -m geoip --src-cc RU -j DROP
En este pequeño ejemplo estaríamos haciendo que no se pudiese acceder a los puertos 21,22 y 23 (protocolo TCP) desde proxies anónimos, que ninguna conexión procedente de China fuese posible y que todo intento de conexión hacia el puerto 5060 (protocolo UDP) procedente desde Rusia fuese posible. Obviamente estas son meras reglas de ejemplo y cada uno podría elegir el país que desee y las reglas de filtrado que más se adapten a sus necesidades.
Como podéis observar el filtrar conexiones por países no es complicado; si bien la primera instalación es algo incomoda, la gestión de las reglas del cortafuegos tras dicha instalación es una tarea muy cómoda que cualquier que tenga ciertas nociones de iptables puede realizar sin problema alguno.
en viernes, septiembre 16, 2016 No hay comentarios :
Etiquetas: Firewall , Howto , Internet , Kernel , Linux , Navegador , Networking , Seguridad
Usando Wireshark para analizar el tráfico de un USB
Probablemente más de uno se haya extrañado con el título de esta entrada, pero no se trata de ninguna errata. Wireshark es una herramienta muy potente de la que ya he hablado con anterioridad para usarla sin ser root; un herramienta de fama mundial que se ha convertido en un referente a nivel de sniffing de redes. Pero esta herramienta puede hacer más cosas a parte de analizar tramas de red de nuestro PC o de aquellos elementos que se encuentren dentro de nuestra red; también puede analizar el tráfico generado por un dispositivo físico que se halle conectado a nuestro equipo, en este caso un USB.
El proceso puede parecer algo complejo, pero veréis que con las herramientas adecuadas el proceso es mucho más simple de lo que en un principio nos puede parecer; cabe destacar que este procedimiento solo es válido en Linux y que en caso de querer aplicarlo en Windows, habrá al menos una parte que habrá que realizar de otra forma...
Lo primero e indispensable que hemos de tener en cuenta son los requisitos para lograr este análisis. El primero, y obvio, es tener instalado la herramienta Wireshark. Esta herramienta es fácilmente descargable vía repositorios oficiales, si bien con lo que podemos usarlos para realizar la instalación exitosamente. El segundo requisito, más importante, es tener un módulo nativo de Linux que nos permite monitorizar el tráfico USB; un módulo cuyo equivalente habría que buscar en Windows en caso de querer aplicarlo allí y que se denomina usbmon. Para cumplir los dos requisitos, lo primero que habría que hacer sería instalar Wireshark tal que así:
El segundo requisito afortunadamente también es sencillo de cumplir, pues el módulo usbmon, si bien está deshabilitado por defecto en Linux, existe y puede ser activado en cualquier momento. Su activación es tan sencilla como escribir en la terminal:
El problema de este método es que es temporal y que el módulo se desactivaría de nuevo al reiniciar el equipo lo cual tiene sus ventajas y desventajas como todo. Se trata de una ventaja a nivel de seguridad, pues cuantos menos módulos estén cargado, menor la cantidad de objetivos hackeables, si bien tiene como pega el hecho de que en caso de usar muy a menudo dicho módulo habría que activarlo a mano tras cada reinicio. Imaginemos que deseamos usar este módulo con asiduidad en el futuro; podemos hacer que la carga de éste sea persistente con este simple comando:
echo usbmon >> /etc/modules
Con todos los preparativos listos, lo primero que necesitaríamos tener en cuenta sería que usbmon carga dos módulos usbmon, llamados usbmon1 y usbmon2; que estarían asociados cada uno a una entrada USB; con lo que lo primero (y muy importante) sería saber a qué usbmon estaría asociado nuestro USB; es decir, donde está siendo monitorizado nuestro USB. Esto afortunadamente se puede saber con facilidad gracias al comando lsusb.
En este caso podemos ver que el BUS USB número 1 tiene el dispositivo con ID numero 4; es decir que tendríamos que usar el módulo usbmon1 en Wireshark.
Ahora que sabemos eso, tendríamos que arrancar la aplicación Wireshark; allí, como probablemente más de uno sepa, podemos escoger en qué interfaz de red deseamos ponernos a "escuchar". Ahora, gracias a usbmon, también podremos escuchar lo procedente del USB, lo cual se logra simplemente seleccionando el módulo dentro de la lista de interfaces de red:
En caso de tener más de un USB conectados al mismo BUS, tras comenzar con la captura de red podemos escoger con precisión el dispositivo USB que queremos monitorizar dentro de usbmon... En este caso en concreto por ejemplo, el ID del dispositivo era el 4, con lo que podemos hacer:
usb.device_address==4
A partir de aquí solo quedaría observar el tráfico generado por el USB, si bien unos de los paquetes más importantes son los primeros, pues allí podremos ver con detalle la descripción de las características del USB, entre otras cosas. A partir de aquí, cualquier interacción con el USB no pasará desapercibida, pues toda actividad realizada con el USB quedará registrada en Wireshark.
en viernes, septiembre 09, 2016 No hay comentarios :
Etiquetas: Forense , Howto , Kernel , Linux , Networking , Seguridad
La instalación de un sistema operativo, se cual sea, en una máquina nueva, siempre conlleva sus riesgos a nivel de compatibilidad. Generalmente pensamos que no debería haber problemas y que simplemente se trata de instalar el sistema operativo y listo; pero la realidad no siempre corresponde con nuestras expectativas. Drivers no compatibles, discos duros problemáticos, problemas de red... Los problemas pueden venir por doquier, y aún cuando logramos instalar el sistema base exitosamente, podemos descubrir que no todo acaba allí... Podemos vernos en la situación de que, al instalar un sistema operativo Linux sin entorno gráfico (es decir, un sistema operativo con solamente la consola), esta es completamente ilegible. Más de uno puede pensar que puede haber un problema de drivers o que se ha realizado un paso incorrecto durante la instalación del sistema operativo, pero no es así: Se trata de un problema de resolución de pantalla.
Este problema, si bien no impide que el equipo actué con normalidad, es increíblemente molesto a nivel de gestión, pues es prácticamente imposible distinguir nada en la pantalla y tienes que escribir a tientas con la esperanza de que el comando introducido se haya escrito correctamente, lo cual no es nada práctico. Es por eso que es importante encontrar alguna solución que nos ayude a evitar este inconveniente... En concreto habrían dos acciones que se podrían tomar:
La primera es esperar a que “aparezca” la pantalla de login; loguearnos e instalar openssh-server a tientas para luego poder gestionar remotamente vía SSH al equipo, pues remotamente la legibilidad es plena. Esto tiene como problema que en caso de tener algún problema durante el arranque, nos quedaremos a ciegas con lo que no es del todo práctico y no sería otra cosa que un "parche" que esquivaría el problema; pero el problema seguiría allí. Aún así, es un parche válido y simplemente requiere escribir:
La segunda vía es modificar la resolución de la Shell. Para ello comenzaríamos primero con una medida de carácter temporal; se trata de editar el GRUB, tal y como hemos hecho en alguna ocasión anterior, pulsando la tecla e sobre la primera opción del menú. Allí veremos todos los parámetros editables del GRUB y varias líneas referentes al sistema operativo que arranca; entre estas líneas, se encuentra el sistema que desea arrancar, seguido de los caracteres ro; A dicha línea sería necesario añadirle el parámetro vga=720 tal y como podemos ver a continuación en este GRUB de Ubuntu:
Para aplicar dicho cambio al arranque actual simplemente habría que pulsar ctrl-x o F10, con lo cual se podría ver la terminal con una resolución adecuada hasta el próximo arranque que, a menos que no se haga nada, requerirá repetir el mismo procedimiento.
Aprovechando que podemos manejar adecuadamente el sistema operativo, llegaría el turno de hacer que el cambio de resolución sea persistente para no tener que entrar en el GRUB en cada arranque... Esto se consigue editando el fichero /etc/default/grub y añadiendo las dos siguientes líneas (La resolución puesta es una genérica que a mí, personalmente, me ha valido, pero puede variar dependiendo de la pantalla):
Aún con los cambios realizados; estos de por sí no son suficientes, pues el GRUB necesita entender que se han aplicado los susodichos. Esto requiere que ejecutemos dos comandos que harán que el GRUB cargue la nueva configuración introducida:
Gracias a este cambio en los próximos reinicios podremos disfrutar de la Shell del sistema sin sufrir problemas de resolución, lo cual nos servirá para evitar tener que recurrir a "parches", tales como la gestión remota del equipo vía SSH.
en martes, septiembre 06, 2016 No hay comentarios :
Etiquetas: Howto , Kernel , Linux , Shell , Ubuntu
Sacando partido a nuestra tarjeta de red con ethto...
Pequeña vuelta de tuerca a la monitorización de US...
Cómo filtrar accesos no deseados en Linux por país...
Usando Wireshark para analizar el tráfico de un US...
Cómo solventar problemas de resolución en una shel...

References: resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución