INTERNET STORM CENTER SPOTLIGHT
ISC provides a free analysis and warning service to thousands of Internet users and organizations, and is actively working with Internet Service Providers to fight back against the most malicious attackers. https://isc.sans.edu/about.html
The Fun and Dangers of Top Level Domains (TLDs)
Last Updated: 2024-01-31 16:55:32 UTC
by Johannes Ullrich (Version: 1)
In the beginning, life was easy. We had a very limited set of top-level domains: .com, .edu, .gov, ..int, org, .mil, .net, .org, .edu. In addition, we had .arpa for infrastructure use and various two letter country level domains.
But that initial set of TLDs was insufficient as the internet grew, and we had several additions:
- International Domains (IDN) allow for Punycode-encoded Unicode characters.
- Generic top-level domains, allowing anybody to apply for a TLD of their choice.
- A few special use TLDs like .example, .invalid, .local, .onion and .test
And I am only considering ICANN-sanctioned TLDs. We also have a couple of alternate roots.
ICANN is consistently expanding the gTLDs. But yesterday, I noticed some news about a new interesting TLD that you may want to consider adopting: .internal.
Until now, there has been no "official" TLD for internal use. ".local" is reserved for multicast DNS, and using it internally can lead to odd conflicts if your unicast and multicast DNS processes overlap. Companies have run into issues with "adopting" unused top-level domains if they become official and used. For example, the European router manufacturer AVM used "fritz.box" for the internal admin interface of its popular "FRITZ!Box" line of routers.
First, many of these issues disappear if you use a properly registered domain name. You may, for example, register "example-internal.com" for internal use. For external users, you can configure a wildcard entry directing users to a static placeholder page. It will also be easy to get proper TLS certificates for hosts within the domain, should you need them.
Read the full entry: https://isc.sans.edu/diary/The+Fun+and+Dangers+of+Top+Level+Domains+TLDs/30608/
DShield Sensor Log Collection with Elasticsearch
Last Updated: 2024-02-03 15:44:16 UTC
by Guy Bruneau (Version: 1)
This is fork from the original work by Scott Jensen originally published here as guest diary part of the SANS.edu BACS program. This update has a number of new features now available in Github.
The docker compose is custom built to be used with the DShield Honeypot to collect, store, parse sensor logs and display the data in a visual and easy way to search and analyze them for research purposes. The assume the DShield sensor is already installed in a Raspberry using PI Raspbian OS or a system running Ubuntu 20.04 LTS either in your network or in the cloud of your choice.
Suggested Setup of ELK Server Based on Ubuntu
- Ubuntu 20.04 LTS Live Server 64-Bit
- Minimum 8+ GB RAM
- If the amount of RAM assigned to each container (see below) is more than 2GB, consider increasing the server RAM capacity.
- 4-8 Cores
- Minimum 40 GB partition assigned to /var/lib/docker
- Setting Up Docker
The instructions to setup docker and Elasticsearch are listed here ...
The docker package comes setup with the fleet-server and the elastic-agent pre-loaded in docker with 350+ integration for collecting and analyzing data which can be used to add threat intel to ELK, collect netflow data with softflowd or any other logs you want to send to ELK. Docker compose is configured with the following components ...
Read the full entry: https://isc.sans.edu/diary/DShield+Sensor+Log+Collection+with+Elasticsearch/30616/