Aujourd’hui on va parler d’un outil de ouf pour trouver des buckets S3 ouverts : FestIn !

C’est le genre d’outil dont raffolent les chercheurs en sécurité puisqu’il qui explore tous les recoins du web pour dénicher des trucs que vous n’auriez jamais trouvé.

FestIn c’est la grosse artillerie de l’énumération de buckets S3 puisqu’il a tellement d’options que les autres outils à côté c’est de la gnognotte. Attention, c’est bien sûr à utiliser uniquement sur vos propres noms de domaines ou dans le cadre de missions d’audit pour lesquelles vous avez toutes les autorisations.

Avec lui, vous allez pouvoir :

• Utiliser différentes techniques pour trouver des buckets : crawling du DNS et des pages web, analyse des réponses S3
• Faire vos requêtes en passant par un proxy, no stress 🕶
• Vous passer des credentials AWS, puisque ça marche avec n’importe quel provider compatible S3
• Configurer vos propres serveurs DNS, parce que vous êtes trop beau gosse.
• Profiter d’un crawler HTTP de compétition qui va retourner le web pour vous
• Faire des recherches récursives et avoir du feedback entre les différents modules pour un max d’efficacité
• Faire tourner le schmilblick en mode « watch » pour choper les nouveaux domaines en temps réel, ce qui est assez ouf quand on y pense.
• Sauvegarder tous les domaines découverts dans un fichier, pour faire joujou avec plus tard
• Indexer direct le contenu des objets des buckets pour faire des recherches full text de la mort, mieux que Google ! 😎
• Cibler votre recherche sur des domaines spécifiques si vous voulez pas vous éparpiller

Pour l’installer c’est fastoche, au choix :

pip install festin

Ou en mode Docker :

docker run --rm -it cr0hn/festin -h

C’est du brut, du bourrin, puisqu’on va envoyer des requêtes en masse et gratter un max d’infos. Attention cependant, on reste fair-play, on ne veut pas faire planter le serveur non plus.

Par défaut, FestIn prend un unique domaine en argument :

festin mon-super-site.com

Mais on peut aussi lui filer un fichier texte contenant une liste de domaines, histoire d’être plus productif :

1. Crée un fichier domaines.txt avec tes domaines, un par ligne.
2. Lance la commande :

cat domaines.txt | festin -f -

FestIn balance plusieurs tests en même temps pour aller plus vite. Par défaut, il en lance 5. Si vous êtes pressé et que votre machine encaisse, vous pouvez augmenter ce nombre avec l’option -c :

festin -c 10 mon-super-site.com

Attention cependant, ne balancez pas un truc de fou, ça risque de faire bugger le site ciblé. On est là pour glaner des infos, pas pour casser du serveur.

L’outil dispose également d’un petit bot intégré qui va scanner le site à la recherche de liens pouvant mener à des buckets S3. On peut le configurer avec plusieurs options :

• Timeout (-T ou –http-timeout) : Si le site est lent, on augmente le timeout pour pas que le scan plante. Par défaut, c’est 5 secondes.
• Récursion max (-H ou –http-max-recursion) : On limite la profondeur du scan pour éviter de partir en vadrouille sur tout le net. Par défaut, c’est 3 niveaux, genre site.com -> lien -> site2.com -> lien -> site3.com.
• Limite de domaine (-dr ou –domain-regex) : On peut dire au robot de se focaliser uniquement sur les sous-domaines qui correspondent à une expression régulière.
• Liste noire (-B) : Fich un fichier texte contenant des mots clés. Si un domaine contient un de ces mots, on l’ignore.
• Liste blanche (-W) : Même principe, mais à l’envers. On scanne uniquement les domaines contenant des mots clés de la liste blanche.

Pour cela, vous devez créer un fichier blacklist.txt contenant « cdn » et « photos » (on ignore les liens vers des CDN et des images) puis lancer la commande :

festin -T 20 -M 8 -B blacklist.txt -dr .mondomaine\.com mon-super-site.com

Attention : l’option -dr attend une expression régulière valide au format POSIX. Par exemple, mondomaine.com est invalide, alors que \.mondomaine\.com est correct.

FestIn crache un paquet d’infos intéressantes, pas seulement sur les buckets S3, mais aussi sur d’autres éléments identifiés. Ces infos peuvent ensuite être utilisées avec d’autres outils comme nmap.

Pour récupérer les résultats, FestIn propose trois modes qu’on peut combiner :

• Fichier de résultats FestIn (-rr ou –result-file) : Ce fichier contient une ligne JSON par bucket trouvé, avec le nom de domaine d’origine, le nom du bucket et la liste des objets qu’il contient.
• Fichier de domaines découverts filtrés (-rd ou –discovered-domains) : Celui-là liste un domaine par ligne. Ce sont des domaines trouvés par le crawler, le DNS ou les tests S3, mais qui ont été filtrés selon les options définies.
• Fichier brut de tous les domaines découverts (-ra ou –raw-discovered-domains) : Comme son nom l’indique, c’est la liste brute de tous les domaines identifiés par FestIn, sans aucun filtre. Idéal pour du post-traitement et de l’analyse.

récupérer les résultats dans trois fichiers distincts et enchaîner avec nmap :

festin -rr festin.results -rd domaines_filtres.txt -ra domaines_bruts.txt mon-super-site.com

festin -rd domaines_filtres.txt && nmap -Pn -A -iL domaines_filtres.txt -oN nmap-resultats.txt

FestIn peut utiliser Tor pour plus de discrétion. Il faut juste avoir un proxy Tor lancé en local sur le port 9050 (configuration par défaut). Activez-le avec l’option --tor :

tor & festin --tor mon-super-site.com

Et il peut aussi effectuer des recherches DNS. Voici les options dispo :

• Désactiver la découverte DNS (-dn ou –no-dnsdiscover) : Si on a pas besoin de ce type de recherche.
• Serveur DNS personnalisé (-ds ou –dns-resolver) : Pratique si on veut utiliser un serveur DNS différent de celui par défaut.

Comme ceci :

festin -ds 8.8.8.8 mon-super-site.com

Ce script ne se contente pas de dénicher les buckets S3 ouverts, il peut aussi télécharger leur contenu et l’indexer dans un moteur de recherche plein texte. Ça permet ensuite de lancer des recherches directement sur le contenu des buckets ! Pour activer l’indexation, FestIn utilise Redis Search, un projet Open Source.

Il faut deux options :

• Activer l’indexation (–index) : Indispensable pour que le contenu soit stocké dans le moteur de recherche.
• Configuration du serveur Redis Search (–index-server) : Uniquement si votre serveur Redis Search est sur une IP/port différent de localhost:6379 par défaut.

Lancez d’abord Redis Search en tâche de fond :

docker run --rm -p 6700:6379 redislabs/redisearch:latest -d

Puis lancez FestIn avec l’indexation et le serveur distant :

festin --index --index-server redis://127.0.0.1:6700 mon-super-site.com

Attention : l’option --index-server doit obligatoirement commencer par le préfixe redis://.

Bien sûr, on a pas forcément envie de relancer FestIn à chaque nouveau domaine à analyser. C’est pour ça qu’il existe le mode surveillance. FestIn se lance et attend l’ajout de nouveaux domaines dans un fichier qu’il surveille. Pratique pour l’utiliser avec d’autres outils comme dnsrecon.

Lancez FestIn en mode surveillance avec le fichier domaines.txt :

festin --watch -f domaines.txt

Dans un autre terminal, ajoutez des domaines à domaines.txt :

echo "encore-un-autre-site.com" >> domaines.txt

Dès qu’un nouveau domaine est ajouté au fichier, FestIn le scanne automatiquement à la recherche de buckets S3 ouverts. Pour aller plus loin, on peut combiner FestIn avec un outil de reconnaissance DNS comme DnsRecon. L’idée est de récupérer des sous-domaines potentiels liés au domaine principal et de les balancer ensuite à FestIn pour scanner d’éventuels buckets S3 cachés.

Etape 1 : Scruter le domaine cible avec DnsRecon

On va utiliser DnsRecon pour trouver des sous-domaines associés à cible.com. Sauvegardez la sortie dans un fichier CSV :

dnsrecon -d cible.com -t crt -c cible.com.csv

Etape 2 : Préparer le fichier pour FestIn

On isole les sous-domaines du fichier CSV pour les injecter dans FestIn (un domaine par ligne) :

tail -n +2 cible.com.csv | sort -u | cut -d "," -f 2 >> cible.com.domaines

Etape 3 : Lancer FestIn et récupérer les résultats

On balance le fichier de sous-domaines à FestIn en activant la recherche Tor, la concurrence à 5, un serveur DNS personnalisé et en sauvegardant les résultats dans des fichiers distincts :

festin -f cible.com.domaines -

Et pour automatiser tout ça sur plein de domaines à la chaîne, on a même un petit script loop.sh bien pratique dans les examples du repo GitHub.

Voilà les amis, vous avez toutes les clés pour utiliser FestIn comme un pro et aller secouer les buckets S3 qui traînent ! C’est quand même un outil hyper complet et puissant, pensez à l’utiliser avec un proxy ou Tor pour pas vous faire bloquer, et amusez vous bien mais toujours de manière éthique et responsable hein !

In our previous post, we discussed how to generate Images using Stable Diffusion on AWS. In this post, we will guide you through running LLMs for text generation in your own environment with a GPU-based instance in simple steps, empowering you to create your own solutions.

Text generation, a trending focus in generative AI, facilitates a broad spectrum of language tasks beyond simple question answering. These tasks include content extraction, summary generation, sentiment analysis, text enhancement (including spelling and grammar correction), code generation, and the creation of intelligent applications like chatbots and assistants.

In this tutorial, we will demonstrate how to deploy two prominent large language models (LLM) on a GPU-based EC2 instance on AWS (G4dn) using Ollama, an open source tool for downloading, managing, and serving LLM models. Before getting started, ensure you have completed our technical guide for installing NVIDIA drivers with CUDA on a G4DN instance.

We will utilize Llama2 and Mistral, both strong contenders in the LLM space with open source licenses suitable for this demo.

While we won’t explore the technical details of these models, it is worth noting that Mistral has shown impressive results despite its relatively small size (7 billion parameters fitting into an 8GB VRAM GPU). Conversely, Llama2 provides a range of models for various tasks, all available under open source licenses, making it well-suited for this tutorial. 

To experiment with question-answer models similar to ChatGPT, we will utilize the fine-tuned versions optimized for chat or instruction (Mistral-instruct and Llama2-chat), as the base models are primarily designed for text completion.

Let’s get started!

Step 1: Installing Ollama

To begin, open an SSH session to your G4DN server and verify the presence of NVIDIA drivers and CUDA by running:

nvidia-smi

Keep in mind that you need to have the SSH port open, the key-pair created or assigned to the machine during creation, the external IP of the machine, and software like ssh for Linux or PuTTY for Windows to connect to the server.

If the drivers are not installed, refer to our technical guide on installing NVIDIA drivers with CUDA on a G4DN instance.

Once you have confirmed the GPU drivers and CUDA are set up, proceed to install Ollama. You can opt for a quick installation using their binary, or choose to clone the repository for a manual installation.

To install Ollama quickly, run the following command

curl -fsSL https://ollama.com/install.sh | sh

Step 2: Running LLMs on Ollama

Let’s start with Mistral models and view the results by running:

ollama run mistral

This instruction will download the Mistral model (4.1GB) and serve it, providing a prompt for immediate interaction with the model.

Not a bad response for a prompt written in Spanish!. Now let’s experiment with a prompt to write code:

Impressive indeed. The response is not only generated rapidly, but the code also runs flawlessly, with basic error handling and explanations. (Here’s a pro tip: consider asking for code comments, docstrings, and even test functions to be incorporated into the code). 

Exit with the /bye command.

Now, let’s enter the same prompt with Llama2.

We can see that there are immediate, notable differences. This may be due to the training data it has encountered, as it defaulted to a playful and informal chat-style response. 

Let’s try Llama2 using the same code prompt from above:

The results of this prompt are quite interesting. Following four separate tests, it was clear that the generated responses had not only broken code but also inconsistencies within the responses themselves. It appears that writing code is not one of the out-of-the-box capabilities of Llama2 in this variant (7b parameters, although there are also versions specialized in code like Code-Llama2), but results may vary.

Let’s run a final test with Code-Llama, a Llama model fine-tuned to create and explain code:

We will use the same prompt from above to write the code:

This time, the response is improved, with the code functioning properly and a satisfactory explanation provided.

You now have the option to either continue exploring directly through this interface or start developing apps using the API.

Final test: A chat-like web interface

We now have something ready for immediate use. However,  for some added fun, let’s install a chat-like web interface to mimic the experience of ChatGPT.

For this test, we are going to use ollama-ui (https://github.com/ollama-ui/ollama-ui). 

⚠︎ Please note that this project is no longer being maintained and users should transition to Open WebUI, but for the sake of simplicity, we are going to still use the Ollama-ui front-end.

In your terminal window, clone the ollama-ui repository by entering the following command:

git clone https://github.com/ollama-ui/ollama-ui

Here’s a cool trick: when you run Ollama, it creates an API endpoint on port 11434. However, Ollama-ui will run and be accessible on port 8000, thus, we’ll need to ensure both ports are securely accessible from our machine.

Since we are currently running as a development service (without the security features and performance of a production web server), we will establish an SSH tunnel for both ports. This setup will enable us to access these ports exclusively from our local computer with encrypted communication (SSL).

To create the tunnel for both the web-ui and the model’s API, close your current SSH session and open a new one with the following command:

ssh -L 8000:localhost:8000 -L 11434:127.0.0.1:11434 -i myKeyPair.pem ubuntu@<Machine_IP>

Once the tunnel is set up, navigate to the ollama-ui directory in a new terminal and run the following command:

cd ollama-ui
make

Next, open your local browser and go to 127.0.0.1:8000 to enjoy the chat web inRunning an LLM model for text generation on Ubuntu on AWS with a GPU instanceterface!

While the interface is simple, it enables dynamic model switching, supports multiple chat sessions, and facilitates interaction beyond reliance on the terminal (aside from tunneling). This offers an alternative method for testing the models and your prompts.

Final thoughts

Thanks to Ollama and how simple it is to install the NVIDIA drivers on a GPU-based instance, we got a very straightforward process for running LLMs for text generation in your own environment. Additionally, Ollama facilitates the creation of custom model versions and fine-tuning, which is invaluable for developing and testing LLM-based solutions.

When selecting the appropriate model for your specific use case, it is crucial to evaluate their capabilities based on architectures and the data they have been trained on. Be sure to explore fine-tuned variants such as Llama2 for code, as well as specialized versions tailored for generating Python code.

Lastly, for those aiming to develop production-ready applications, remember to review the model license and plan for scalability, as a single GPU server may not suffice for multiple concurrent users. You may want to explore Amazon Bedrock, which offers easy access to various versions of these models through a simple API call or Canonical MLOps, an end-to-end solution for training and running your own ML models.

Quick note regarding the model size

The size of the model significantly impacts the production of better results. A larger model is more capable of reproducing better content (since it has a greater capacity to “learn”). Additionally, larger models offer a larger attention window (for “understanding” the context of the question), and allow more tokens as input (your instructions) and output (the response)

As an example, Llama2 offers three main model sizes regarding the parameter number: 7, 13, or 70 billion parameters. The first model requires a GPU with a minimum of 8GB of GPU RAM, whereas the second requires a minimum of 16GB of VRAM.

Let me share a final example:

I will request the 7B parameters version of Llama2 to proofread an incorrect version of this simple Spanish phrase, “¿Hola, cómo estás?”, which translates to “Hi, how are you?” in English. 

I conducted numerous tests, all yielding incorrect results like the one displayed in the screenshot (where “óle” is not a valid word, and it erroneously suggests it means “hello”).

Now, let’s test the same example with Llama2 with 13 billion parameters:

While it failed to recognize that I intended to write “hola,” this outcome is significantly better as it added accents, question marks and detected that “ola” wasn’t the right word to use (if you are curious, it means “wave”) .

We recently published a technical document showing how to install NVIDIA drivers on a G4DN instance on AWS, where we covered not only how to install the NVIDIA GPU drivers but also how to make sure to get CUDA working for any ML work. 

In this document we are going to run one of the most used generative AI models, Stable Diffusion, on Ubuntu on AWS for research and development purposes.

According to AWS, “G4dn instances, powered by NVIDIA T4 GPUs, are the lowest cost GPU-based instances in the cloud for machine learning inference and small scale training. (…) optimized for applications using NVIDIA libraries such as CUDA, CuDNN, and NVENC.”

G4DN instances come in different configurations:

Instance type	vCPUs	RAM	GPUs
g4dn.xlarge	4	16	1
g4dn.2xlarge	8	32	1
g4dn.4xlarge	16	64	1
g4dn.8xlarge	32	128	1
g4dn.12xlarge	48	192	4
g4dn.16xlarge	64	256	1
g4dn.metal	96	384	8

For this exercise, we will be using the g4dn.xlarge instance, since we need only 1 GPU, and with 4 vCPUs and 16GB of RAM, it will provide sufficient resources for our needs, as the GPU will handle most of the workload. 

Image generation with Stable Diffusion

Stable Diffusion is a deep learning model released in 2022 that has been trained to transform text into images using latent diffusion techniques. Developed by Stability.AI, this groundbreaking technology not only provides open-source access to its trained weights but also has the ability to run on any GPU with just 4GB of RAM, making it one of the most used Generative AI models for image generation.

In addition to its primary function of text-to-image generation, Stable Diffusion can also be used for tasks such as image retouching and video generation. The license for Stable Diffusion permits both commercial and non-commercial use, making it a versatile tool for various applications.

Requirements

You’ll need SSH access. If running on Ubuntu or any other Linux distribution, opening a terminal and typing ssh will get you there. If running windows, you will need either WSL (to run a Linux shell inside windows) or PuTTY to connect to the machine using an external software.

Make sure you have NVIDIA Drivers and CUDA installed on your G4DN machine. Test with the following command:

nvidia-smi

You should be able to see the driver and CUDA versions as shown here:

Let’s get started!

Step 1: Create a python virtual environment:

First, we need to download some libraries and dependencies as shown below:

sudo apt-get install -y python3.10-venv
sudo apt-get install ffmpeg libsm6 libxext6 -y

Now we can create the Python environment.

python3 -m venv myvirtualenv

And finally, we need to activate it. Please note that every time we log in into the machine, we will need to reactivate it with the following line:

source myvirtualenv/bin/activate

Step 2: Download the web GUI and get a model.

To interact with the model easily, we are going to clone the Stable Diffusion WebUI from AUTOMATIC1111.

git clone https://github.com/AUTOMATIC1111/stable-diffusion-webui.git

After cloning the repository, we can move on to the interesting part: choosing and downloading a Stable Diffusion model from the web. There are many versions and variants that can make the journey more complicated but more interesting as a learning experience. As you delve deeper, you will find that sometimes you need specific versions, fine-tuned or specialized releases for your purpose.

This is where HuggingFace is great, as they host a plethora of models and checkpoint versions that you can download. Please be mindful of the license model of each model you will be using.

Go to Hugging Face, click on models, and start searching for “Stable Diffusion”. For this exercise, we will use version 1.5 from runwayml.

Go to the “Files and versions” tab and scroll down to the actual checkpoint files.

Copy the link and go back to your SSH session. We will download the model using wget:

cd ~/stable-diffusion-webui/models/Stable-diffusion
wget https://huggingface.co/runwayml/stable-diffusion-v1-5/resolve/main/v1-5-pruned.safetensors

Now that the model is installed, we can run the script that will bootstrap everything and run the Web GUI.

Step 3: Run the WebUI securely and serve the model

Now that we have everything in place, we will run the WebUI and serve the model.

Just as a side note, since we are not installing this on a local desktop, we cannot just open the browser and enter the URL. This URL will only respond locally because of security constraints (in other words, it is not wise to open development environments to the public). Therefore, we are going to create an SSH tunnel.

Exit the SSH session.

If you are running on Linux (or Linux under WSL on Windows), you can create the tunnel using SSH by running the following command:

ssh -L 7860:localhost:7860 -i myKeyPair.pem ubuntu@<the_machine's_external_IP>

In case you are running on Windows and can’t use WSL, follow these instructions to connect via PuTTY.

If everything went well, we can now access the previous URL in our local desktop browser. The entire connection will be tunneled and encrypted via SSH.

In your new SSH session, enter the following commands to run the WebUI.

cd ~/stable-diffusion-webui
./webui.sh

The first time will take a while as it will install PyTorch and all the required dependencies. After it finishes, it will give you the following local URL:

http://127.0.0.1:7860

So open your local browser and go to the following URL: http://127.0.0.1:7860

We are ready to start playing. 

We tested our first prompt with all the default values, and this is what we got. Quite impressive, right?

Now you are ready to start generating!

Final thoughts

I hope this guide has been helpful in deploying the Stable Diffusion model on your own instance and has also provided you with a better understanding of how these models work and what can be achieved with generative AI. It is clear that generative AI is a powerful tool for businesses today. 

In our next post, we will explore how to deploy and self-host a Large Language Model, another groundbreaking AI tool. 

Remember, if you are looking to create a production-ready solution, there are several options available to assist you. From a security perspective, Ubuntu Pro offers support for your open source supply chain, while Charmed Kubeflow provides a comprehensive stack of services for all your machine learning needs. Additionally, AWS offers Amazon Bedrock, which simplifies the complexities involved and allows you to access these services through an API. 

Thank you for reading and stay tuned for more exciting AI content!