On a different note: I was trying something on the size, and was dropped into a ZSH shell (as opposed to Bash), and it was pretty interesting. Made me consider trying it further on my daily driver.
Okay, so I wanted to share a little incident from a few months back that really hammered home the power of knowing your Linux internals when things go sideways. I got a frantic call, "something weird is going on with our build server, it's acting sluggish and our monitoring is throwing odd network alerts." No fancy EDR on this particular box, just the usual ssh and bash. My heart always sinks a little when it's a Linux box with vague symptoms, because you know it's time to get your hands dirty.
First thing I did, even before reaching for any specific logs, was to get a quick snapshot of the network. Instead of netstat, which honestly feels a bit dated now, I immediately hit ss -tunap. That p is crucial cause it shows you the process and user ID for each connection. What immediately jumped out was an outbound TCP connection on a high port to a sketchy-looking IP, and it was tied to a process that definitely shouldn't have been making external calls. My gut tightened. I quickly followed up with lsof -i just to be super sure no deleted binaries were clinging on to network connections.
With that IP and PID in hand, I moved to process investigation. pstree -ap was my next stop. It showed the suspicious process, and more importantly, its parent. It wasn't a child of systemd or a normal service. It was spawned by a build script that shouldn't have been executing anything like this. That hierarchical view was key. Then, to really understand what this thing was doing, I dared to strace -p <PID>. Watching the system calls unfurl was like watching a movie of its malicious intent: it was reading from /etc/passwd, making connect() calls, and trying to write to some odd /tmp directories. Simultaneously, I checked ls -l /proc/<PID>/exe to confirm the actual binary path (it was indeed in /tmp) and /proc/<PID>/cwd to see its working directory. No doubt, this was a rogue process.
Knowing it was a fresh infection, I immediately shifted to the filesystem. My go-to is always find / -type f -newermt '2 days ago' -print0 | xargs -0 ls -latr. This quickly pulls up any files modified in the last 48 hours, sorted by modification time. It's often where you find dropped payloads, modified configuration files, or suspicious scripts. Sure enough, there were a few more binaries in /tmp and even a suspicious .sh script in a developer's home directory. I also scanned for SUID/SGID binaries with find / -perm /6000 just in case they'd dropped something for privilege escalation. And while stat's timestamps can be tampered with, I always glance at atime, mtime, and ctime on suspicious files; sometimes, a subtle mismatch offers a tiny clue if the attacker wasn't meticulous.
The final piece of the puzzle, and often the trickiest, is persistence. I checked the usual suspects: crontab -l for root and every other user account I could find. Then I cast a wider net with grep -r "suspect_domain_or_ip" /etc/cron.* /etc/systemd/system/ /etc/rc.d/ and similar common boot directories. Sure enough, a new systemd timer unit had been added that was scheduled to execute the /tmp binary periodically. Finally, I didn't forget the user dotfiles (~/.bashrc, ~/.profile, etc.). It’s surprising how often an attacker will drop a malicious alias or command in there, assuming you won't dig deep into a developer's setup.
Long story short, we quickly identified the ingress vector, isolated the compromise, and cleaned up the persistence. But what really stuck with me is how quickly you can triage and understand an incident if you're comfortable with these fundamental Linux commands. There's no substitute for getting your hands dirty and really understanding what strace is showing you or why ss is superior to netstat in a high-pressure situation. These tools are your best friends in a firefight.
@ponies The solution @simontatham is/was presenting, could possibly (untested) be simplified by putting { and } around all the code. It forces #GNU#bash to read the whole block (storing it in memory, so buffered reading of the file won't be an issue -- in theory) before executing it.
Vengo a explicar mi maqueta Hace rato me aventé un script de bash buenorro, ya tenía rato que no hacía algo así
TheModArchive es una página que contiene una extensa colección de módulos de música secuenciados en 'secuenciadores' de en su mayoría, computadoras antiguas, desde la Amiga hasta la PC
Entre ellos, bastantes "chiptunes", sí, esa musiquita que suele venir en generadores de números de serie y cracks para programas conocidos, los cuales disfruto mucho escuchar
Estos módulos son reproducibles en sus secuenciadores originales, o con ayuda de reproductores de música que soporten estos formatos, sobretodo en PC, ya sea Linux, Mac o PC, pero no son un formato " accesible" como el MP3, FLAC o WAV, de la compu no pasan, ya que su formato tiene su chiste El archivo contiene la secuencia musical, con efectos en las notas, su duración etc, y, las muestras de sonido necesarias para que sean tocadas a como se necesita en esa secuencia, son partes separadas, pero trabajan en conjunto para formar una canción.
Bueno, qué hace este script?
La tirada es descargar toda esa colección, módulo por módulo, convertirlos a OPUS (MP3 is dead), etiquetarlos correctamente, calcular su ganancia de reproducción e integrarlos a mi biblioteca musical
El script descarga la página de cada módulo, busca en el marcado HTML la sección correspondiente al mismo, y descarga lo necesario, convierte, etiqueta, archiva
Todo usando herramientas comunes en Linux: wget, head, cut, y algunas extras: openmpt123, pup, rsgain, opusenc, aubio, exiftool
Esta funcionando de maravilla! Estoy orgulloso y feliz de esto Además, ya tengo para escuchar por horas y horas, días, quizá años (cuando acabe me daré cuenta de la sumatoria del tiempo de reproducción)
I am in urgent job search mode, so I'm gonna throw this out here and see if anything comes of it.
I am a #Canadian, fluent in both #English and #French. I have experience with several programming languages. My strongest proficiency is with #Haskell and #C. I also have a reasonable grasp of #HTML, #JavaScript, #SQL, #Python, #Lua, #Linux system administration, #bash scripting, #Perl, #AWK, some #Lisp (common, scheme, and emacs), and probably several others I've forgotten to mention.
I am not necessarily looking for something in tech. I just need something stable. I have done everything from software development, to customer support, to factory work, though my current circumstances make in-person work more difficult than remote work. I have been regarded as a hard worker in every job I have ever held.
A few years ago I did a quick analysis of my #Bash histfile and horrified my coworkers that `#git rebase` was my most frequently used command.
It's not on top, but It's still in the top 10. (I think gitk getting so much higher up is that I want to look at gitk so much, but with #Emacs#EXWM I loose track of windows more than I did with #WMII, so I just open a new one, and end up with 15 open gitk windows before I realize this and run `killall wish`.
This is a small personal collection of :gnu: #GNU#Bash scripts I’ve put together to simplify everyday updates for all the common stuff on :debian: Debian GNU/Linux-based systems. It has been available under the #GPLv3+ for a while, so you are free to use, study, modify, and share it however you see fit—following #Copyleft principles, always preserving the users' freedoms. If you improve it, consider sharing back your changes to help keep the spirit of #FreeSoftware alive. 🤝
I’d love to hear if it ends up being useful for you! If you run into any issues or have suggestions, please report them directly on Disroot Forgejo or just drop a comment here.
Are you just like me? Do you want to make fantastically beautiful posts and not be limited by a silly 500 character fence, but want to BANG intricate stories of 10.000 characters?
Don't be limited by those silly 500 character servers!
Browse over here, find an instance that's suitable to you and go there. The list doesn't have everyone who has that massive 5,000 character size, but the list has a lot of servers, so pick one choose one and go be the literary giant that you are
And yes there are servers which have a fantastically glorious 10,000 character limit!