Linux auditing can help. It will at least locate users and processes making datagram network connections. UDP packets are datagrams.
First, install the auditd
framework on your platform and ensure that auditctl -l
returns something, even if it says that no rules are defined.
Then, add a rule to watch the system call socket()
and tag it for easy finding later (-k
). I need to assume that you are on a 64-bit architecture, but you can substitute b32
in place of the b64
if you aren't.
auditctl -a exit,always -F arch=b64 -F a0=2 -F a1\&=2 -S socket -k SOCKET
You have to pick through man pages and header files to build this, but what it captures is essentially this system call: socket(PF_INET, SOCK_DGRAM|X, Y)
, where the third parameter is unspecified but frequently zero. PF_INET
is 2 and SOCK_DGRAM
is 2. TCP connections would use SOCK_STREAM
which would set a1=1
. (SOCK_DGRAM
in the second parameter may be ORed with SOCK_NONBLOCK
or SOCK_CLOEXEC
, hence the &=
comparison.) The -k SOCKET
is our keyword we want to use when searching audit trails later. It can be anything, but I like to keep it simple.
Let a few moments go by and review the audit trails. Optionally, you could force a couple of packets by pinging a host out on the net, which will cause a DNS lookup to occur, which uses UDP, which should trip our audit alert.
ausearch -i -ts today -k SOCKET
And output similar to the section below will appear. I'm abbreviating it to highlight the important parts
type=SYSCALL ... arch=x86_64 syscall=socket success=yes exit=1 a0=2 a1=2 ... pid=14510 ... auid=zlagtime uid=zlagtime ... euid=zlagtime ... comm=ping exe=/usr/bin/ping key=SOCKET
In the above output, we can see that the ping
command caused the socket to be opened. I could then run strace -p 14510
on the process, if it was still running. The ppid
(parent process ID) is also listed in case it is a script that spawns the problem child a lot.
Now, if you have a lot of UDP traffic, this isn't going to be good enough and you'll have to resort to OProfile or SystemTap, both of which are currently beyond my expertise.
This should help narrow things down in the general case.
When you are done, remove the audit rule by using the same line you used to create it, only substitute -a
with -d
.
auditctl -d exit,always -F arch=b64 -F a0=2 -F a1\&=2 -S socket -k SOCKET
You could use Puppet to push out the password change to all your servers. You would define root
using the user
type like so:
user { 'root':
ensure => present,
password => '$1$blablah$blahblahblahblah',
}
To generate the encrypted password:
openssl passwd -1 -salt "blah"
I'd suggest perhaps changing it every month or so---maybe using a scheme that your SAs memorized. You could also distribute it via a secure method or put it in a safe.
Best Answer
This is because DES-based crypt (AKA 'descrypt') truncates passwords at 8 bytes, and only checks the first 8 for the purpose of password verification.
That's the answer to your direct question, but here's some general advice implied by your context:
Fortunately, from my reading,
MD5
in/etc/login.defs
is actually md5crypt ($1$), which, while a little outdated and declared deprecated by its author, is still far superior to DES-based crypt (and definitely much better than a raw, unsalted hash like plain MD5! Most unsalted hashes can be cracked on commodity GPUs at rates of billions per second)It looks like
SHA256
(actually sha256crypt) andSHA512
(actually sha512crypt) are also there. I would pick one of those instead.If you set your password to
password
or something under each scheme, you can visually verify whether or not my conclusion that they're the -crypt variants is correct (examples here are taken from the hashcat example hashes, all 'hashcat', some wrapped for readability):Not recommended - unsalted or legacy hash types, much too "fast" (cracking rates) for password storage:
OK - much better than unsalted, no truncation, but no longer sufficiently resistant to brute force on modern hardware:
Better - relatively modern hashes with large salts and work factors:
Of these, only descrypt truncates at 8. The last two are your best bet.
(Side note: the digits-only salts in the md5crypt and sha512crypt examples above are just side effects of how hashcat creates example hashes; real, healthy salts are usually drawn from a much larger keyspace).
Note also that I'm only listing the hash types that are supported by /etc/login.defs on this platform. For general use, even sha256crypt and sha512crypt have been superseded - first by bcrypt, and then later by truly parallel-attack-resistant hashes like scrypt and the Argon2 family. (Note, however, that for interactive logins that should complete in under one second, bcrypt is actually more resistant to attack than the latter)