4 ms·

$ echo "install dccp /bin/true" >> /etc/modprobe.d/dccp.conf $ sudo rmmod dccp # in case it's already loaded This is a good idea for any modules you don't

$ echo "install dccp /bin/true" >> /etc/modprobe.d/dccp.conf $ sudo rmmod dccp # in case it's already loaded This is a good idea for any modules you don't expect to ever need. In my case: $ cat /etc/modprobe.d/disabled_modules.conf install appletalk /bin/true install bluetooth /bin/true install cramfs /bin/true install dccp /bin/true install firewire-core /bin/true *snipped* install tipc /bin/true install udf /bin/true install usb-storage /bin/true install vfat /bin/true The original -- to me -- recommendations for this were found in some "hardening guide" for RHEL (CIS, NSA, etc.), although I don't remember which. See also the "modprobe.blacklist=" kernel parameter, which you'll have to use for "modules" that are compiled into the kernel itself (i.e., they are not actually loadable kernel modules). 15 years ago, when building your own kernels was a normal everyday thing, I simply built my kernels with everything compiled in and modules disabled. This (would have) prevented attacks such as kernel-level rootkits. In addition, "one neat trick" was that you could halt (not poweroff) the machine (!) -- such as in the case of a Linux box simply acting as a router/firewall -- and the kernel would still be running. Good luck compromising that! :-)

tptacek 10y ago
This is a useful post. I'm going to nerd out at you though and point out that disabling LKMs doesn't really do anything to disable kernel-resident rootkits; any kernel memory corruption vulnerability can be used to create an ad-hoc module loader. If you Google for amodload, you can find (uuencoded, in a Bugtraq message --- it's 2017 and I just uudecoded something!) Josh Daymont's old SunOS 4.1.3 modloader hack, which overwrote a kernel socket callback and used socket buffers to hold module text.
- jlgaddis 10y ago
  > This is a useful post. I'm going to nerd out at you though and point out that disabling LKMs doesn't really do anything to disable kernel-resident rootkits; ... I really hate to question you but... are you sure? The particular case that I'm thinking of was probably ~15 years ago. There was some 0-day or worm or something (details are a little vague now, obviously) that would install a kernel module and then loaded it to hide itself. I can recall a discussion at the time and this was a recommendation. It wasn't just disabling individual modules -- it was actually disabling support for loading kernel modules. That is, whatever the kernel itself needed in order to support dynamic loading of modules at run-time was needed; the kernel was not able to load a module. Like I said, it's been probably 15 years ago and I'm sure I'm not remembering everything 100% correctly so you may very well be correct... but I'm almost certain you could entirely disable loading of kernel modules (the kernel itself didn't support loading them). Googling "amodload" now, thanks for the pointer...
  - tedunangst 10y ago
    The kernel has function pointers and dynamic memory. You can "build" a module if you need to.
    - jlgaddis 10y ago
      Interesting. Thanks.
  - tptacek 10y ago
    Check out amodload; that was what was so interesting about it at the time: it built its own module loader back into a kernel compiled without loadable modules. If course: table stakes for modern rootkits!
    - jlgaddis 10y ago
      Thanks for the replies and pointers, Thomas. You've given me even more to read and learn about.
  - shawnz 10y ago
    Surely if you can write to /dev/mem, it doesn't matter whether your kernel has support for modules or not. You could just create a rootkit which is not in the form of a loadable module. EDIT: Here's an example of this very thing. https://www.blackhat.com/presentations/bh-europe-09/Lineberry/BlackHat-Europe-2009-Lineberry-code-injection-via-dev-mem.pdf https://www.blackhat.com/presentations/bh-europe-09/Lineberr...
rcdmd 10y ago
Great advice. Using /bin/false also works, as I found on the Arch Wiki. Do you know what the difference is? modprobe dccp #with /bin/false fails with modprobe: ERROR: Error running install command for dccp modprobe: ERROR: could not insert 'dccp': Operation not permitted
- throwaway2048 10y ago
  /bin/true sets the return code to 0, signifying success to the modprobe process, /bin/false sets it to 1, signifying failue, and producing said message. Due to the way modprobe may be hooked by various things, its best to use /bin/true to ensure less breakage.
- jlgaddis 10y ago
  Like throwaway2048 mentioned, the only difference is the return code. I think the original documentation described them something like this: /bin/true does nothing, successfully. /bin/false does nothing, unsuccessfully.
ciupicri 10y ago
Isn't VFAT required for UEFI?
- deathanatos 10y ago
  Wouldn't it only be required if you wanted to mount the UEFI system partition? (Which is formatted in a variant of the FAT FS, IIRC.) If you don't want to mount the system partition, you shouldn't need the module. (Although, my system puts kernel images there. IDK if this is typical of UEFI systems. IIRC, Grub is capable of loading from ext FSs, so this shouldn't be a hard-and-fast requirement.)
  - shawnz 10y ago
    Well, even if kernel images didn't go there, you would still need to access it for grub updates. So it might not be a good recommendation for everyday users.
- jlgaddis 10y ago
  No idea, that particular host doesn't use UEFI.
compuguy 10y ago
Sounds like your referring to STIG.
- jlgaddis 10y ago
  Among others, yes.

tptacek 10y ago

This is a useful post. I'm going to nerd out at you though and point out that disabling LKMs doesn't really do anything to disable kernel-resident rootkits; any kernel memory corruption vulnerability can be used to create an ad-hoc module loader. If you Google for amodload, you can find (uuencoded, in a Bugtraq message --- it's 2017 and I just uudecoded something!) Josh Daymont's old SunOS 4.1.3 modloader hack, which overwrote a kernel socket callback and used socket buffers to hold module text.

jlgaddis 10y ago
> This is a useful post. I'm going to nerd out at you though and point out that disabling LKMs doesn't really do anything to disable kernel-resident rootkits; ... I really hate to question you but... are you sure? The particular case that I'm thinking of was probably ~15 years ago. There was some 0-day or worm or something (details are a little vague now, obviously) that would install a kernel module and then loaded it to hide itself. I can recall a discussion at the time and this was a recommendation. It wasn't just disabling individual modules -- it was actually disabling support for loading kernel modules. That is, whatever the kernel itself needed in order to support dynamic loading of modules at run-time was needed; the kernel was not able to load a module. Like I said, it's been probably 15 years ago and I'm sure I'm not remembering everything 100% correctly so you may very well be correct... but I'm almost certain you could entirely disable loading of kernel modules (the kernel itself didn't support loading them). Googling "amodload" now, thanks for the pointer...
- tedunangst 10y ago
  The kernel has function pointers and dynamic memory. You can "build" a module if you need to.
  - jlgaddis 10y ago
    Interesting. Thanks.
- tptacek 10y ago
  Check out amodload; that was what was so interesting about it at the time: it built its own module loader back into a kernel compiled without loadable modules. If course: table stakes for modern rootkits!
  - jlgaddis 10y ago
    Thanks for the replies and pointers, Thomas. You've given me even more to read and learn about.
- shawnz 10y ago
  Surely if you can write to /dev/mem, it doesn't matter whether your kernel has support for modules or not. You could just create a rootkit which is not in the form of a loadable module. EDIT: Here's an example of this very thing. https://www.blackhat.com/presentations/bh-europe-09/Lineberry/BlackHat-Europe-2009-Lineberry-code-injection-via-dev-mem.pdf https://www.blackhat.com/presentations/bh-europe-09/Lineberr...

rcdmd 10y ago

Great advice. Using /bin/false also works, as I found on the Arch Wiki. Do you know what the difference is? modprobe dccp #with /bin/false fails with modprobe: ERROR: Error running install command for dccp modprobe: ERROR: could not insert 'dccp': Operation not permitted

throwaway2048 10y ago
/bin/true sets the return code to 0, signifying success to the modprobe process, /bin/false sets it to 1, signifying failue, and producing said message. Due to the way modprobe may be hooked by various things, its best to use /bin/true to ensure less breakage.
jlgaddis 10y ago
Like throwaway2048 mentioned, the only difference is the return code. I think the original documentation described them something like this: /bin/true does nothing, successfully. /bin/false does nothing, unsuccessfully.

ciupicri 10y ago

Isn't VFAT required for UEFI?

deathanatos 10y ago
Wouldn't it only be required if you wanted to mount the UEFI system partition? (Which is formatted in a variant of the FAT FS, IIRC.) If you don't want to mount the system partition, you shouldn't need the module. (Although, my system puts kernel images there. IDK if this is typical of UEFI systems. IIRC, Grub is capable of loading from ext FSs, so this shouldn't be a hard-and-fast requirement.)
- shawnz 10y ago
  Well, even if kernel images didn't go there, you would still need to access it for grub updates. So it might not be a good recommendation for everyday users.
jlgaddis 10y ago
No idea, that particular host doesn't use UEFI.

compuguy 10y ago

Sounds like your referring to STIG.

jlgaddis 10y ago
Among others, yes.