You are not logged in.
Hi, comrades!
The kpcre module for iptables compiles again with the latest Linux kernels. My thanks to the developer of this module from South Korea. Details can be read here: https://github.com/smcho-kr/kpcre/issues/33
Get NVIDIA proprietary driver from official NVIDIA site for your GPU
If you absolutely must have the proprietary closed-source drivers, do not download them directly from the manufacturer's website! Installing drivers this way only works for the current kernel, and after the next kernel update, your video drivers will not work until they are manually reinstalled again.
You are not right! The firmware is independent of the Linux kernel version and driver version. So there won't be any problems. ;-)
I havent used your list of parameters, i tried some of the tails linux recommended parameters , not sure exactly which one locked up my computer but the mds=full,nosmt seems to stand out to me, after removing that i had no issues. It definitely a case by case basis, not all intel computers are made the same.
Tails and Whonix have a much smaller set of security options than what I have proposed. In each specific case, you need to select your own set of security parameters for the Linux kernel. In my case, everything works due to the fact that I have a fairly ancient Intel processor. I am glad that you are interested in this topic, since few people are interested in the information security of their operating system and hardware.
It's a shame that no one wants to discuss the technical details of the proposed parameters. There are parameters in the proposed parameters, the use of which I could not get a definite answer from some specialists in configuring the Linux kernel:
kmemleak=on kmemleak.stack=on kmemleak.scan=on kmemleak=scan kmemleak=clear
But, I think, the solution I proposed with these parameters will be correct, based on the logic of this subset of the Linux kernel.
Eaglet wrote:I am not forcing you to do anything if you have not noticed. A smart person will study the proposal, perhaps with the help of other people, if his knowledge is not enough, and then decide whether he needs it. Don't insult me with your distrust!
I didn't mean to insult you.
When it comes to my computer, I distrust ANYONE who hasn't already earned my trust over time.
Also, I run a web site that has had 22 million visits from all over the world. I study its server logs every day. In all these years, I can't even remember the last time my site received a visitor from Russia (you have since changed your location to USSR) that wasn't malicious and needed to be blocked. So, I am especially suspicious of security advice from anyone who is from Russia.
Sorry, my feelings are based on my own experience, and are not personal against you.
1. I, unlike you, trust only myself. 2. No need to spam and talk off topic. 3. In every country in the world there are different people, both good and bad. 4. This is my last reply to your posts, I will only reply to posts on a technical topic.
Thanks for sharing
one should definitely read up on linux kernel parameters. https://www.kernel.org/doc/html/v4.14/a … eters.html
I tried a few of those parameters awhile ago, i think disabling smt caused my rig to lock up.
If you have problems booting with the new Linux kernel parameters, then you can edit the boot parameters in the Grub menu when the bootloader starts. Unfortunately, I cannot check the performance of these parameters on many computers, since I do not have such an opportunity. I only urge specialists, especially in information security, to carefully read the official documentation for the possibility of self-defense of the Linux kernel.
In order for me to even CONSIDER making these types of changes, the person who wants me to do them has to be someone who has long- established themself as a TRUSTED expert who has a documented history of helping people like me.
I am not forcing you to do anything if you have not noticed. A smart person will study the proposal, perhaps with the help of other people, if his knowledge is not enough, and then decide whether he needs it. Don't insult me with your distrust!
Hello comrades! If you have technical questions on this topic, ask, I will be happy to answer them.
I've seen a number of people post these lists of "super secure settings" that the poster allegedly has learned about, but for which they leave little or no description as to what each change does. I can only assume that zero readers try them, since it's just a "trust me this works" list.
For an explanation of each kernel parameter, see the official documentation for the Linux kernel (different versions). You, if you have the necessary qualifications, can check each parameter I have given. I don't think you will argue that the official Linux kernel documentation is lying to you? ;-)
Eaglet wrote:Smart people learn from their mistakes
Only a fool learns from their own mistakes
You are wrong: you cannot teach a fool, because he is a fool! ;-)
Eaglet wrote:are more up-to-date than the Debian documentation.
But the De??an documentation is for the version supplied for that branch whereas the upstream documentation refers to the latest versions.
Documentation can be found in the primary sources for any version. Primary sources have more information written in more understandable language.
The hardening-runtime package will apply several of those parameters automatically.
Note that the kernel tuning can be applied via /etc/sysctl.d/ if a bootloader-independent configuration method is required.
1. The hardening-runtime package contains very few security options for the Linux kernel compared to the FULL list of security options that I have provided!
2. The hardening-runtime package contains very few security options for sysctl. I current use over 96 parameters in my sysctl.conf for heavy security hardening my Linux system: for kernel, network & etc.
I can read, study, analyze and apply the written in the documentation in the primary sources for Linux in practice. The Debian Help is very incomplete. As long as sysadmins, information security professionals, and engineers do not read the primary sources of technical information, the security of Linux systems will be threatened by their gullibility. I prefer to protect my systems myself, not using ready-made solutions with a limited (not complete) set of security parameters. My solutions take advantage of all the Linux systems security hardening capabilities that are provided by the Linux kernel, as well as those subsystems that are additionally used to secure Linux systems. Life and bitter practical experience taught me this. Smart people learn from their mistakes, it is impossible to teach fools!
Eaglet wrote:Install NVIDIA firmware for nouveau driver
Most of the NVIDIA firmware is provided by the firmware-misc-nonfree package.
Eaglet wrote:Best Xorg.conf configuration for NVIDIA Nouveau driver
I would encourage people to read nouveau(4) and make their own decisions about the various options. A blanket approach seems unhelpful (IMO).
I do not impose anything on anyone. But it's better to read and use the original sources: https://nouveau.freedesktop.org/
The primary sources provide more information and are more up-to-date than the Debian documentation.
1. Install NVIDIA firmware for nouveau driver:
$ mkdir /tmp/nouveau
$ cd /tmp/nouveau
$ wget https://raw.github.com/envytools/firmware/master/extract_firmware.py
Get NVIDIA proprietary driver from official NVIDIA site for your GPU, example
$ wget http://us.download.nvidia.com/XFree86/Linux-x86/325.15/NVIDIA-Linux-x86-325.15.run
Extract and install NVIDIA firmware to your computer:
$ sh NVIDIA-Linux-x86-325.15.run --extract-only
$ python2 extract_firmware.py # this script is for python 2 only
# mkdir /lib/firmware/nouveau
# cp -d nv* vuc-* /lib/firmware/nouveau/
2. Best Xorg.conf configuration for NVIDIA Nouveau driver. With this code, you must create a config file /usr/share/X11/xorg.conf.d/10-nouveau.conf:
Section "Module"
Load "bitmap"
Load "ddx"
Load "ddc"
Load "dri2"
Load "GLCore"
Load "extmod"
Load "freetype"
Load "int10"
Load "record"
Load "type1"
Load "vbe"
EndSection
Section "Device"
Option "WrappedFB" "true"
Option "SwapLimit" "2"
Option "AccelMethod" "exa"
Option "DRI" "2"
Identifier "Card0"
Driver "nouveau"
BusID "PCI:1:0:0"
EndSection
Section "ServerFlags"
Option "DRI2" "true"
EndSection
Section "DRI"
Mode 0666
EndSection
Section "Extensions"
Option "Composite" "Enable"
EndSection
Section "Files"
ModulePath "/lib/xorg/modules/drivers/"
EndSection
You can use a more powerful and modern implementation - DRI3 instead of DRI2 in this configuration file, if you don't have any glitches or artifacts in the graphics system. "AccelMethod" for DRI3 by default is "glamor". "SwapLimit" "2" - is turn on triple buffer for Nouveau for fix many problem with graphics system, example in KDE5. "WrappedFB" "true" - is recommend for old NVIDIA GPU. "Mode 0666" - work mode driver, you can change this mode to "664" for high security.
3. Tuning kernel parameters for Nouveau driver.
You must add the following information to your /etc/default/grub file in the "GRUB_CMDLINE_LINUX_DEFAULT =" section:
GRUB_CMDLINE_LINUX_DEFAULT="quiet acpi_backlight=vendor drm.rnodes=1 nouveau.pstate=1 nouveau.runpm=1"
And run
update-grub
in your console for refresh grub boot configuration.
4. After all these changes, you can reboot your computer and get not only a significant performance boost for your free Nouveau driver, but also the hardware media decoding available for the proprietary NVIDIA driver.
I was forced to publish this information for NVIDIA GPUs due to the fact that in Devuan Linux proprietary NVIDIA drivers do not install loosely. This solution will help people using Devuan Linux, as well as other Linux distributions without the systemd virus, in solving the problem with installing NVIDIA drivers, which, without sacrificing functionality, can now be replaced with the free Nouveau driver according to the method I described. I hope that this information, which I have collected, will be useful to many people with NVIDIA GPUs.
Warning! This changes contains noEFI parameter!
For best Linux kernel hardening for Intel CPU and fix memory leak in Linux systems add the following information to the file /etc/default/grub:
GRUB_CMDLINE_LINUX_DEFAULT="intel_pstate=force init_on_free=1 init_on_alloc=1 kvm.nx_huge_pages=force nosmt=force tsx=off mds=full,nosmt l1tf=full,force tsx_async_abort=full,nosmt random.trust_cpu=off acpi_osi=Linux drm.vblankoffdelay=1 kaslr pti=on slab_nomerge nosmt nf_conntrack.acct=1 cgroup_enable=memory swapaccount=1 numa_balancing=enable topology_updates=off noaliencache iommu=pt rodata=on pdcchassis=1 noinitrd x2apic_phys intremap=on apic_extnmi=all align_va_addr=off noht xen_emul_unplug=all acpi=copy_dsdt acpi_force_table_verification debug_guardpage_minorder=2 kmemleak=on kmemleak.stack=on kmemleak.scan=on kmemleak=scan kmemleak=clear rodata=on pcie_bus_safe ecrc=on pcie_port_pm=force noexec=on no_debug_objects dma_debug=off integrity_audit=1 iomem=strict kasan_multi_shot spectre_v1=on ssbd=force-off spec_store_bypass_disable=on intel_iommu=on spectre_v2_user=on spectre_v2=on processor.max_cstate=9 intel_idle.max_cstate=9 l1tf=flush edac_report=force hardened_usercopy=on seccomp=1 audit=1 mce=recovery slab_nomerge slub_debug=FZP intel_pstate=hwp_only noefi pti=on page_poison=1 vsyscall=none"
After adding this information, update your grub configuration:
update-grub
These Linux kernel changes are intended for secure Linux workstations. But these changes lead to a significant decrease in performance. You have a choice: performance or high security.
Can we see the actual build errors? The full list of commands used would also be useful.
Unfortunately, I can't provide a list of build errors because I removed Devuan Chimaera (Debian 11). You can play them yourself in a virtual machine. Although I have already contacted the developer of this iptables module from South Korea and added this issue to the issue list on the github page of this project. It is possible for the developer from South Korea to fix this problem. I really need Kpcre to block the traffic generated by viruses, to block telnet traffic, and to block errors in encrypted traffic.
Hi friends!
I really need your help! I am using the iptables kpcre module (https://github.com/xnsystems/kpcre.git), but there was a problem: it refuses to compile and build on the latest version of Devuan Chimaera (Debian 11). Can someone help me fix the source code of this project so that it works in the latest version of Devuan. I really need the kpcre module to block abnormal network traffic using iptables, I think some of you will need it too.
I really hope that you can help me, because I am not a programmer, but a system administrator. For my part, I undertake to post your patch on github so that other people can use it, or you will post it yourself.
Eaglet wrote:After that, the lkrg module will start running every time a user logs into DE.
What would happen if a user types ctrl-alt-F1 and logged on to a text console? Or logged on from another system via SSH etc? You have to look for ways round any security checks.
Chris
I am aware of this. That is why I proposed the solution I described.
Well the systemd unit files supplied by the upstream developers load the module at boot (ie, before the DE starts) so I presume that is the expected behaviour.
Yes, I agree with you.
Which functionality will not work?
My suggested configuration files load the module and apply the sysctl setting at boot so they do exactly what your suggested script does.
For example, removable drives (Flash, SD-card) are not mounted when the lkrg module is loaded at system boot, and not when DE starts.
Whonix has a DKMS .deb package for LKRG:
https://www.whonix.org/wiki/Linux_Kerne … ource_Code
Their current version is 0.8.1 but the git repository has a debian/watch file so it can be updated with uscan.
The .deb only supplies the systemd unit files but the same effect can be achieved by adding this line to /etc/modules (or in it's own file under /etc/modules-load.d/):
p_lkrg
And also add this line to /etc/sysctl.conf (or in it's own file under /etc/sysctl.conf.d/):
lkrg.clean_message = 0
No need for lkrg.sh or any additions to /etc/sudoers
My post is about integrating the "lkrg" module with DE (Gnome, KDE, XFCE & etc.), not for use on servers and other systems. If you follow your advice, then some of the DE functionality will not work!
Hello, comrades!
I want to share with you the intricacies of using the LKRG module in Devuan Linux with DE (Gnome, KDE, LXDE & etc.).
You can find more information about this security module at the link: https://www.openwall.com/lkrg/
To start using this module, you need to download the sources and compile the module itself using the command: "make -j8". Next, install this module using the command: "make install".
Since the installer of this module is intended for Linux systems using systemd, then during installation you will be told about an installation error. It is worth paying attention to this only if you want this module to be loaded at the start of the operating system, but when used on systems with DE (Gnome, KDE, LXDE & etc.) I do not advise you to do this, because . false positives are possible when starting DE. In order for this module to start working at DE startup, you need to create an executable file in the user's working directory, for example, lkrg.sh with the following content:
#!/bin/bash
sleep 10
sudo /sbin/modprobe p_lkrg p_init_log_level=3
sleep 3
sudo /sbin/sysctl lkrg.clean_message=0
exit 0
And add the following information to the "/etc/sudoers" file:
your_user ALL = NOPASSWD: /sbin/sysctl lkrg.clean_message=0,/sbin/modprobe p_lkrg p_init_log_level=3
After that, the lkrg module will start running every time a user logs into DE.
Devuan is not blocking access but it is recommended that users not use pkgmaster directly because it can impede updating of the devuan mirrors. Maybe try deb.devuan.org or pick a specific mirror from the mirror list.
Thanks for your recommendation. I will try to follow your advice.
There is absolutely no reason for blocking, this shouldn't happen! Can you post a traceroute or detail how access is denied?
To avoid censorship and blocks to the Internet the Devuan website is also accessible using Tor at the address http://devuanzuwu3xoqwp.onion
traceroute to 54.36.142.184 (54.36.142.184), 30 hops max, 48 byte packets
1 * * *
2 188.254.25.224 (188.254.25.224) 14.186 ms 13.893 ms 14.031 ms
3 87.226.146.100 (87.226.146.100) 13.759 ms 13.966 ms 13.979 ms
4 ae40.stkm-cr4.intl.ip.rostelecom.ru (217.107.67.31) 50.333 ms 53.467 ms 53.586 ms
5 * * *
6 * * *
7 * * *
8 * * *
9 be102.rbx-g3-nc5.fr.eu (54.36.50.243) 91.055 ms 82.845 ms be102.rbx-g4-nc5.fr.eu (54.36.50.233) 84.152 ms
10 * * *
11 * * *
12 * * *
13 nash.devuan.org (94.23.30.104)!!!!!!!!! 75.453 ms 75.434 ms 83.621 ms
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *