CAINE offers a complete forensic environment that is organized to integrate existing software tools as software modules and to provide a friendly graphical interface: contains numerous tools that help investigators during their analysis, including forensic evidence collection
A VMware-based appliance designed for small-to-medium sized digital investigation and acquisition and is built entirely from public domain software, like Autopsy, the Sleuth Kit, the Digital Forensics Framework, log2timeline, Xplico, and Wireshark. The system maintenance is provided by Webmin.
A Linux distribution customized in order to perform various forenics tasks like password discovery , social media analysis, data carving, windows registry analysis, malware analysis, log analysis and more.
Security Onion is a special Linux distro aimed at network security monitoring featuring advanced analysis tools:
Security Onion is a Linux distro for intrusion detection, network security monitoring, and log management. It’s based on Ubuntu and contains Snort, Suricata, Bro, OSSEC, Sguil, Squert, ELSA, Xplico, NetworkMiner, and many other security tools.
The SIFT Workstation is
a VMware appliance, preconfigured with the necessary tools to perform
detailed digital forensic examination in a variety of settings.
SIFT Workstation demonstrates that advanced incident response
capabilities and deep dive digital forensic techniques to intrusions can be accomplished using cutting-edge open-source tools that are freely available and frequently updated
The X server is no longer setuid, and may be started without root privileges. If the startx command is run as a non-root user, the Xorg.0.log (or Xorg.*.log for alternative displays) file will be written to ~/.local/share/xorg/ instead of /var/log/.
PHP 7.0 replaces PHP 5.6. There are new metapackages without a version number in them: php-fpm, php-cli, etc. You may use these for future compatibility.
Most of the library packages with debugging symbols have been moved to a new repository. If you require these packages, you will need to add an entry to your sources.list or sources.list.d. Also note that the package names are different (ending with -dbgsym instead of -dbg).
How to upgrade?
Before you move on with the upgrade, be sure that your current Debian Jessie was fully updated:
EXT4 is a journaling file system for Linux, developed as the successor to ext3: it modifies important data structures of the previous filesystem such as the ones destined to store the file data. The result is a filesystem with an improved design, better performance, reliability and features. It was accepted as “stable” in the Linux 2.6.28 kernel in October 2008.
The publication of the ‘episodes’ continued since years, and recently Hal has published the part 6, focused on “Directories”.
Here the list of all parts:
20 Dec 2010
EXT4 has moved to 48-bit block addresses. I’ll refer you to the paper cited above for the whys and wherefores of this decision and what it means as far as maximum file system size, etc. What’s really a departure for EXT4 however, is the use of extents rather than the old, inefficient indirect block mechanism used by earlier Unix file systems (e.g. EXT2/EXT3) for tracking file content. Extents are similar to cluster runs in the NTFS file system- essentially they specify an initial block address and the number of blocks that make up the extent. A file that is fragmented will have multiple extents, but EXT4 tries very hard to keep files contiguous.
The EXT4 developers tried very hard to maintain backwards compatibility with the EXT2/EXT3 inode layout. 64-bit timestamps and a completely new file creation timestamp obviously complicate this goal. The EXT4 developers solved this problem by putting the extra stuff in the upper 128 bits of the new, larger 256-bit EXT4 inode.
[…] you can only have a maximum of 4 extent structures per inode. Furthermore, there are only 16 bits in each extent structure for representing the number of blocks in the extent, and in fact the upper bit is reserved (it’s used to mark the extent as “reserved but initialized”, part of EXT4’s pre-allocation feature). That means each extent can only contain a maximum of 2¹⁵ blocks- which is 128MB assuming 4K blocks.
Now 128MB is pretty big, but what happens when you have a file that’s bigger than half a gigabyte? Such a file would require more than 4 extents to fully index. Or what happens when you have a file that’s small but very fragmented? Again, you could need more than 4 extents to represent the collections of blocks that make up the file.
I got curious about what would happen when I deleted my /var/log/messages file. How does the inode change? What happens to block 131090, which holds my extent tree structure? Well, there’s really only one way to find out: I deleted the file… carefully so I didn’t lose any logging data. In fact, I didn’t just delete the file; I used “shred -u /var/log/messages” to overwrite the data blocks with nulls before unlinking the file. Once the file had been purged, I dumped out the both inode associated with the file as well as block 131090 and took a look at them in my hex editor.
[…] you can only have 32K blocks in an extent. Assuming a typical 4K block size, that means you can only have 128MB of data in a single extent. A 4GB file is therefore going to require at least 32 extents, and even that assumes you can find 32 runs of 32K contiguous blocks to use. More likely we’ll have more than 32 extents, some of which don’t use the full 128MB length.
One item I never got around to was documenting how directories were structured in EXT. Some recent research has caused me to dive back into this topic, and given me an excuse to add additional detail to this EXT4 series.
If you go back and read earlier posts in this series, you will note that the EXT inode does not store file names. Directories are the only place in traditional Unix file systems where file name information is kept. In EXT, and the classic Unix file systems it is evolved from, directories are simply special files that associate file names with inode numbers.
Furthermore, in the simplest case, EXT directories are just sequential lists of file entries. The entries aren’t even sorted. For the most part, directory entries in EXT are simply added to the directory file in the order files are created in the directory.
Yesterday i read a really inspiring article written by Joe Nelson, concerning the making of a extremely-geek Linux workstation, with a minimalist and reactive user interface.
Truly interesting, imho, are the ‘Design Goals’ (with my highlights in bold):
User actions should complete instantaneously. While I understand if compiling code and rendering videos takes time, opening programs and moving windows should have no observable delay. The system should use minimalist tools.
Corollary: cache data offline when possible. Everything from OpenStreetMaps to StackExchange can be stored locally. No reason to repeatedly hit the internet to query them. This also improves privacy because the initial download is indiscriminate and doesn’t reveal personal queries or patterns of computer activity.
No idling program should use a perceptible amount of CPU. Why does CalendarAgent on my Macbook sometimes use 150% CPU for fifteen minutes? Who knows. Why are background ChromeHelpers chugging along at upper-single-digit CPU? I didn’t realize that holding a rendered DOM could be so challenging.
Delegate to quality hardware components. Why use a janky ncurses Linux audio mixer when you can use…an actual audio mixer?
Hardware privacy. No cameras or microphones that I can’t physically disconnect. Also real hardware protection for cryptographic keys.
Software privacy. Commercial software and operating systems have gotten so terrible about this. I even catch Mac command line tools trying to call Google Analytics. Sorry homebrew, your cute emojis don’t make up for the surveillance.
The selected distro is a Debian stable with i3 as Windows Manager, and a really interesting list of installed softwares: