xfce4 thunar添加搜索选项

 

ref:https://www.reddit.com/r/xfce/comments/94qwuo/when_is_thunar_finally_getting_a_search_file/

You can create a shortcut in Thunar’s right click menu via the “Edit” -> “Configure custom actions…” menu.

  • Name: Search files...

  • Command: catfish --path=%f

  • File pattern: *

  • Appears if selection contains: Directories

vmware modules不能在新内核更新解决方法

ref:https://communities.vmware.com/t5/VMware-Workstation-Pro/VMware-16-2-3-not-working-on-Ubuntu-22-04-LTS/td-p/2905535

cd /usr/lib/vmware/modules/source
git clone https://github.com/mkubecek/vmware-host-modules
cd vmware-host-modules
git checkout workstation-16.2.4
make
tar -cf vmnet.tar vmnet-only
tar -cf vmmon.tar vmmon-only
mv vmnet.tar /usr/lib/vmware/modules/source/
mv vmmon.tar /usr/lib/vmware/modules/source/
vmware-modconfig --console --install-all

Linux下vmware虚拟机中永久激活Windows7

原文地址: http://blog.csdn.net/royer/article/details/11313611

 

 

  1. 简述
     
    vmware 可以指定一个外部文件作为其虚拟机的BIOS ,那么就可以通过把品牌机的SLIC2.1 的信息写到这个BIOS 文件中来激活Windows 7.  只要能够生成这个BIOS 文件,其余的步骤就和兼容机刷BIOS 永久激活Windows 7 的方法一样了,网上教程到处可见,比如这篇就是个不错的教程。
     
  2. 基本环境
     
    1. 主机操作系统:Ubuntu 13.04 64bit
    2. 虚拟机软件:vmware player for linux 64bit
    3. 目标虚拟机:Windows 7 64bit 旗舰版
       
  3. 所需工具
     
    1. SLIC Toolkit V3.2 ( 用来验证SLIC 是否成功写入)
    2. rw-everything
      下载地址: http://rweverything.com/
    3. PhoenixTool ( 需要.Net Framework 2.0)
  4. 流程
     
    1. 第一步:提取 vmware  bios
      Ubuntu , vmware bios  /usr/lib/vmware/bin/vmware-vmx 中。用objcopy 提取 bios440section 
      objcopy vmware-vmx -O binary -j bios440 --set-section-flags bios440=a bios440.rom.z
      注:这里我先把/usr/lib/vmware/bin/vmware-vmx拷贝到里临时目录下。

      如果不能提取,可以用objdump命令:
      objdump -h vmware-vmx | grep bios440
      确认下 bios440 section 是否存在或名称是否正确(有些版本的vmware section 名字是 .bios440。得到结果如下:

      28bios440 00033d47 0000000000000000 0000000000000000 00d6c0d0 2**0

      另外也可以根据objdump 的信息用dd 命令把 bios440 section dump 出来。
      dd skip=14074064 bs=1 count=212295 ibs=1 obs=1 if=vmware-vmx of=bios440.rom.z

      其中14074064 对应与objdump 00d6c0d0, bios440 seciton vmware-vmx 中起始位置,而212295 是大小,对应objdump 00033d47 段。

      用下面的命令对刚才提出的 bios440.room.z 解压:
      <div class="dp-highlighter bg_plain" style="font-family: Consolas, 'Courier New', Courier, mono, serif; font-size: 12px; width: 621.713px; overflow: auto; padding-top: 1px; margin: 18px 0px !important; background-color: rgb(231, 229, 220);"><div class="bar" style="padding-left: 45px;"><div class="tools" style="padding: 3px 8px 10px 10px; font-stretch: normal; font-size: 9px; line-height: normal; font-family: Verdana, Geneva, Arial, Helvetica, sans-serif; color: silver; border-left-width: 3px; border-left-style: solid; border-left-color: rgb(108, 226, 108); background-color: rgb(248, 248, 248);"><strong>[plain]</strong> <a target=_blank href="http://blog.csdn.net/royer/article/details/11313611#" class="ViewSource" title="view plain" style="color: rgb(160, 160, 160); text-decoration: none; border: none; padding: 1px; margin: 0px 10px 0px 0px; display: inline-block; width: 16px; height: 16px; text-indent: -2000px; background-image: url(http://static.blog.csdn.net/scripts/SyntaxHighlighter/styles/images/default/ico_plain.gif); background-attachment: initial; background-color: inherit; background-size: initial; background-origin: initial; background-clip: initial; background-position: 0% 0%; background-repeat: no-repeat;">view plain</a><span class="tracking-ad" data-mod="popu_168"> <a target=_blank href="http://blog.csdn.net/royer/article/details/11313611#" class="CopyToClipboard" title="copy" style="color: rgb(160, 160, 160); text-decoration: none; border: none; padding: 1px; margin: 0px 10px 0px 0px; display: inline-block; width: 16px; height: 16px; text-indent: -2000px; background-image: url(http://static.blog.csdn.net/scripts/SyntaxHighlighter/styles/images/default/ico_copy.gif); background-attachment: initial; background-color: inherit; background-size: initial; background-origin: initial; background-clip: initial; background-position: 0% 0%; background-repeat: no-repeat;">copy</a></span><div style="position: absolute; left: 557px; top: 1906px; width: 18px; height: 18px; z-index: 99;"></div><span class="tracking-ad" data-mod="popu_169"> </span></div></div><ol start="1" style="padding: 0px; border: none; color: rgb(92, 92, 92); margin: 0px 0px 1px 45px !important; background-color: rgb(255, 255, 255);"><li class="alt" style="border-style: none none none solid; border-left-width: 3px; border-left-color: rgb(108, 226, 108); list-style: decimal-leading-zero outside; color: inherit; line-height: 18px; margin: 0px !important; padding: 0px 3px 0px 10px !important;"><span style="margin: 0px; padding: 0px; border: none; color: black; background-color: inherit;"><span style="margin: 0px; padding: 0px; border: none; background-color: inherit;">perl -e 'use Compress::Zlib; my $v; read STDIN, $v, 212295; $v = uncompress($v); print $v;' < bios440.rom.z > bios440.rom  </span></span></li></ol></div>
      这里212295 就是bios440.rom.z 的文件大小,vmware 版本不同,大小可能略有不同。
      这样的的bios440.rom 就是vmware 的 512K  的虚拟机BIOS 了。
       
       
    2. 第二步:用 rw-everything 提取 ACPI Tables
      启动虚拟机运行rw.exe . Access 菜单->ACPI Tables ,从ACPI Tables 的子窗口上选Save All 按钮(或Ctrl+F2), 保存文件名就用缺省的即可AcpiTbls.rw 。如图:
    3. 第三步:用 PhoenixTool 合并 SLIC 生成 bios
      vmware  虚拟机的BIOS 是属于Phoenix 类的。感谢PhoenixTool 的作者,有了这个工具,就不必再用Phoenix BIOS Editor 和 WinHex 繁琐无比的操作来生成Phoenix bios 了。
      1. Original 里输入从vmware-vmx 里抽出的bios440.rom 。 等待PhoenixTool 完成分析。
      2. Manufacturer 里选择厂商,这个取决于你准备好的SLIC2.1 OEM 证书文件是那个厂商的。
      3. SLIC File 里输入你的SLIC2.1 的文件。
      4. RW File 里输入刚才rw-everything 生成的AcpiTbls.rw .

      5. 点击Advanced 按钮,出现可能会刷砖的警告,点“是”,出现advanced option 对话框,确保” Only alter RSDT and XSDT tables” 选中,点Done 按钮退出设置。

         

      6. Go 按钮开始生成。
        成功生成的话,新的BIOS 文件会在bios440.rom 所在的目录里,文件名是bios440_SLIC.rom 
         
    4. 第四步:修改 .vmx 文件
       
      虚拟机关机。用文本编辑软件打开要修改的虚拟机对应的.vmx 文件,在文件尾加上:
      bios440.filename = “bios440_SLIC.rom”
      理论上bios440_SLIC.rom 可以放在任何目录,只要配置文件写上绝对路径即可。
      重新启动虚拟机。运行SLIC Toolkit V3.2 检查SLIC2.1 是否成功加入BIOS 。如下图红框中字样表示成功提取到SLIC ,厂商是LENOVO, 型号TC-5K ,版本2.1. 
BIOS下载
https://mega.nz/file/xoMXBSLC#C75NIL4pAlbrJbMZuw2QiEklESSQxNNmBUW32Lyy9nMD
https://mega.nz/file/d5EzzSpR#2qmnpFbhuf38PSoaZ_woE5ii-TqC_RqYm_0i2BuT_A0
password:mdl2021

ubuntu 查看usb设备

查看 USB 设备 使用的是哪个串口

ls -l /dev/ttyUSB*

查看 USB 设备 是不是存储设备
Linux下查看usb设备信息,常常使用lsusb命令

$lsusb

Bus 002 Device 125: ID 0781:5567 SanDisk Corp. Cruzer Blade
$lsusb -t

Port 1: Dev 125, If 0, Class=Mass Storage, Driver=usb-storage, 480M

Class=Mass Storage,说明我的设备是大容量存储设备。

我优盘的ID 是 0781:5567,如果我要查它的详细信息(包括它是否是存储设备),可以用命令:

$sudo lsusb -d 0781:5567 -v

过滤信息,用下面的命令:

$sudo lsusb -d 0781:5567 -v |grep -i storage

得到结果

bInterfaceClass 8 Mass Storage

Mass Storage,说明该设备是存储设备。

 

Extend the life of your SSD drive with fstrim

原文:https://opensource.com/article/20/2/trim-solid-state-storage-linux

 

Over the past decade, solid-state drives (SSD) have brought about a new way of managing storage. SSDs have benefits like silent and cooler operation and a faster interface spec, compared to their elder spinning ancestors. Of course, new technology brings with it new methods of maintenance and management. SSDs have a feature called TRIM. This is essentially a method for reclaiming unused blocks on the device, which may have been previously written, but no longer contain valid data and therefore, can be returned to the general storage pool for reuse. Opensource.com’s Don Watkins first wrote about TRIM in his 2017 article “Solid-state drives in Linux: Enabling TRIM for SSDs.”

 

If you have been using this feature on your Linux system, then you are probably familiar with the two methods described below.

The old ways

Discard

I initially enabled this with the discard option to the mount command. The configuration is placed into the /etc/fstab file for each file system.

# cat /etc/fstab
UUID=3453g54-6628-2346-8123435f  /home  xfs  defaults,discard   0 0

The discard option enables automatic online TRIM. There has recently been debate on whether this is the best method due to possible negative performance impacts. Using this option causes a TRIM to be initiated every time new data is written to the drive. This may introduce additional activity that interferes with storage performance.

Cron

I removed the discard option from the fstab file. Then I created a cron job to call the command on a scheduled basis.

# crontab -l
@midnight /usr/bin/trim

This is the method I used most recently on my Ubuntu Linux systems until I learned about another way.

A new TRIM service

I recently discovered that a systemd service for TRIM exists. Fedora introduced this into their distribution in version 30, and, although it is not enabled by default in versions 30 and 31, it is planned to be in version 32. If you’re working on Fedora Workstation 31 and you want to begin using this feature, you can enable it very easily. I’ll also show you how to test it below. This service is not unique to Fedora. The existence and status will depend on an individual distribution basis.

Test

I like to test first, to better understand what is happening behind the scenes. I do this by opening a terminal and issuing the command that the service is configured to call.

/usr/sbin/fstrim --fstab --verbose --quiet

The –help argument to fstrim will describe these and other arguments.

$ sudo /usr/sbin/fstrim --help

Usage:
 fstrim [options] <mount point>

Discard unused blocks on a mounted filesystem.

Options:
 -a, --all           trim all supported mounted filesystems
 -A, --fstab         trim all supported mounted filesystems from /etc/fstab
 -o, --offset <num>  the offset in bytes to start discarding from
 -l, --length <num>  the number of bytes to discard
 -m, --minimum <num> the minimum extent length to discard
 -v, --verbose       print number of discarded bytes
     --quiet         suppress error messages
 -n, --dry-run       does everything, but trim

 -h, --help          display this help
 -V, --version       display version

So, now I can see that the systemd service is configured to run the trim on all supported mounted filesystems in my /etc/fstab file –fstab and print the number of discarded bytes –verbose but suppress any error messages that might occur –quiet. Knowing these options is helpful for testing. For instance, I can start with the safest one, which is the dry run. I’ll also leave off the quiet argument so I can determine if any errors will occur with my drive setup.

$ sudo /usr/sbin/fstrim --fstab --verbose --dry-run

This will simply show what the fstrim command will do based on the file systems that it finds configured in your /etc/fstab file.

$ sudo /usr/sbin/fstrim --fstab --verbose

This will now send the TRIM operation to the drive and report on the number of discarded bytes from each file system. Below is an example after my recent fresh install of Fedora on a new NVME SSD.

/home: 291.5 GiB (313011310592 bytes) trimmed on /dev/mapper/wkst-home
/boot/efi: 579.2 MiB (607301632 bytes) trimmed on /dev/nvme0n1p1
/boot: 787.5 MiB (825778176 bytes) trimmed on /dev/nvme0n1p2
/: 60.7 GiB (65154805760 bytes) trimmed on /dev/mapper/wkst-root

Enable

Fedora Linux implements systemd timer service, scheduled to run on a weekly basis. To check the existence and current status, run systemctl status.

$ sudo systemctl status fstrim.timer

Now, enable the service.

$ sudo systemctl enable fstrim.timer

Verify

Then you can verify that the timer is enabled by listing all of the timers.

$ sudo systemctl list-timers --all

The following line referring to the fstrim.timer will appear. Notice that the timer actually activates fstrim.service. This is from where the actual fstrim is called. The time-related fields show n/a because the service has just been enabled and has not run yet.

NEXT   LEFT    LAST   PASSED   UNIT           ACTIVATES
n/a    n/a     n/a    n/a      fstrim.timer   fstrim.service

Conclusion

This service seems like the best way to run TRIM on your drives. It is much simpler than having to create your own crontab entry to call the fstrim command. It is also safer not having to edit the fstab file. It has been interesting to watch the evolution of solid-state storage technology and nice to know that it appears Linux is moving toward a standard and safe way to implement it.

grub定制

grub customizer

ppa

https://launchpad.net/~danielrichter2007/+archive/ubuntu/grub-customizer

grub显示菜单:

GRUB_TIMEOUT_STYLE设置为menu

 

Configuring On-Access Scanning in ClamAV

原文:

https://docs.clamav.net/manual/OnAccess.html

https://www.ibm.com/docs/en/ahte/4.0?topic=wf-configuring-linux-many-watch-folders

Purpose

This guide is for users interested in leveraging and understanding ClamAV’s On-Access Scanning feature. It will walk through how to set up and use the On-Access Scanner and step through some common issues and their solutions.

Requirements

On-Access is only available on Linux systems. On Linux, On-Access requires a kernel version >= 3.8. This is because it leverages a kernel api called fanotify to block processes from attempting to access malicious files. This prevention occurs in kernel-space, and thus offers stronger protection than a purely user-space solution.

For Versions >= 0.102.0

It also requires Curl version >= 7.45 to ensure support for all curl options used by clamonacc. Users on Linux operating systems that package older versions of libcurl have a number of options:

  1. Wait for your package maintainer to provide a newer version of libcurl.
  2. Install a newer version of libcurl from source.
  3. Disable installation of clamonacc and On-Access Scanning capabilities with the ./configure flag --disable-clamonacc.

General Use

To use ClamAV’s On-Access Scanner, operation will vary depending on version.

For Versions >= 0.102.0

You will need to run the clamd and clamonacc applications side by side. First, you will need to configure and run clamd. For instructions on how to do that, see the clamd configuration guide. One important thing to note while configuring clamd.conf is that–like clamdscan–the clamonacc application will connect to clamd using the clamd.conf settings for either LocalSocket or TCPAddr/TCPSocket. Another important thing to note, is that when using a clamd.conf that specifies a LocalSocket, then clamd will need to be run under a user with the right permissions to scan the files you plan on including in your watch-path.

Next, you will need to configure clamonacc. For a very simple configuration, follow these steps:

1. Open `clamd.conf` for editing
2. Specify the path(s) you would like to recursively watch by setting the `OnAccessIncludePath` option
3. Set `OnAccessPrevention` to `yes`
4. Check what username `clamd` is running under
5. Set `OnAccessExcludeUname` to `clamd`'s uname
6. Save your work and close `clamd.conf`

For slightly more nuanced configurations, which may be adapted to your use case better, please check out the recipe guide below.

Then, run clamonacc with elevated permissions:

sudo clamonacc

If all went well, the On-Access scanner will fork to the background, and will now be actively protecting the path(s) specified with OnAccessIncludePath. You can test this by dropping an eicar file into the specified path, and attempting to read/access it (e.g. cat eicar.txt). This will result in an “Operation not permitted” message, triggered by fanotify blocking the access attempt at the kernel level.

Finally, you will have to restart both clamd and clamonacc. If default clamonacc performance is not to your liking, and your system has the resources available, we reccomend increasing the values for the following clamd.conf configuration options to increase performance:

  • MaxQueue
  • MaxThreads
  • OnAccessMaxThreads

For Versions <= 0.101.x

You will only need to run the clamd application in older versions. First, we reccomend you configure clamd for your environment. For instructions on how to do that, see the clamd configuration guide.

Next, you will need to configure On Access Scanning using the clamd.conf file. For a very simple configuration follow these steps:

1. Open `clamd.conf` for editing
2. Set the `ScanOnAccess` option to `yes`
3. Specify the path(s) you would like to recursively watch by setting the `OnAccessIncludePath` option
4. Set `OnAccessPrevention` to `yes`
6. Save your work and close `clamd.conf`

For slightly more nuanced configurations, which may be adapted to your use case better, please check out the recipe guide below.

Then, run clamd with elevated permissions:

sudo clamd

If all went well, the On-Access scanner will fork to the background, and will now be actively protecting the path(s) specified with OnAccessIncludePath. You can test this by dropping an eicar file into the specified path, and attempting to read/access it (e.g. cat eicar.txt). This will result in an “Operation not permitted” message, triggered by fanotify blocking the access attempt at the kernel level.

Troubleshooting

Some OS distributors have disabled fanotify, despite kernel support. You can check for fanotify support on your kernel by running the command:

cat /boot/config-<kernel_version> | grep FANOTIFY

You should see the following:

CONFIG_FANOTIFY=y
CONFIG_FANOTIFY_ACCESS_PERMISSIONS=y

If you see this…

CONFIG_FANOTIFY_ACCESS_PERMISSIONS is not set

… then ClamAV’s On-Access Scanner will still function, scanning and alerting on files normally in real time. However, it will be unable to block access attempts on malicious files. We call this notify-only mode.

ClamAV’s On-Access Scanning system uses a scheme called Dynamic Directory Determination (DDD for short) which is a shorthand way of saying that it tracks the layout of every directory specified with OnAccessIncludePath dynamically, and recursively.

In real time. It does this by leveraging inotify which by default has a limited number of watch-points available for use by a process at any given time. Given the complexity of some directory hierarchies, ClamAV may warn you that it has exhausted its supply of inotify watch-points (8192 by default). To increase the number of inotify watch-points available for use by ClamAV (to 524288), run the following command:

echo 524288 | sudo tee -a /proc/sys/fs/inotify/max_user_watches

The OnAccessIncludePath option will not accept / as a valid path. This is because fanotify works by blocking a process’ access to a file until a access_ok or access_denied determination has been made by the original fanotify calling process. Thus, by placing fanotify watch-points on the entire filesystem, key system files may have their access blocked to key processes at the kernel level, which will result in a system lockup.

This restriction was made to prevent users from “shooting themselves in the foot.” However, clever users will find it’s possible to circumvent this restriction by using multiple OnAccessIncludePath options to recursively protect most of the filesystem anyways, or better still, simply the paths they truly care about.

The OnAccessMountPath option uses a different fanotify api configuration which makes it incompatible with OnAccessIncludePath and the DDD System. Therefore, inotify watch-point limitations will not be a concern when using this option. Unfortunately, this also means that the following options cannot be used in conjunction with OnAccessMountPath:

  • OnAccessExtraScanning – is built around catching inotify events.
  • OnAccessExcludePath – is built upon the DDD System.
  • OnAccessPrevention – would lock up the system if / was selected for OnAccessMountPath. If you need OnAccessPrevention, you should use OnAccessIncludePath instead of OnAccessMountPath.

Configuration and Recipes

More nuanced behavior can be coerced from ClamAV’s On-Access Scanner via careful modification to clamd.conf. Each option related to On-Access Scanning is easily identified by looking for the OnAccess prefix pre-pended to each option. The default clamd.conf file contains descriptions of each option, along with any documented limitations or safety features.

Below are examples of common use cases, recipes for the correct minimal configuration, and the expected behavioral result.

Use Case 0x0

  • User needs to watch the entire file system, but blocking malicious access attempts isn’t a concern
    ScanOnAccess yes ## versions <= 0.101.x
    OnAccessMountPath /
    OnAccessExcludeRootUID yes
    OnAccessExcludeUname clamav ## versions >= 0.102

This configuration will put the On-Access Scanner into notify-only mode. It will also ensure only non-root, non-clam, user processes will trigger scans against the filesystem.

Use Case 0x1

  • System Administrator needs to watch the home directory of multiple Users, but not all users. Blocking access attempts is un-needed.
    ScanOnAccess yes ## versions <= 0.101.x
    OnAccessIncludePath /home
    OnAccessExcludePath /home/user2
    OnAccessExcludePath /home/user4
    OnAccessExcludeUname clamav ## versions >= 0.102

With this configuration, the On-Access Scanner will watch the entirety of the /home directory recursively in notify-only mode. However, it will recursively exclude the /home/user2 and /home/user4 directories.

Use Case 0x2

  • The user needs to protect a single directory non-recursively and ensure all access attempts on malicious files are blocked.
    ScanOnAccess yes ## versions <= 0.101.x
    OnAccessIncludePath /home/user/Downloads
    OnAccessExcludeUname clamav ## versions >= 0.102
    OnAccessPrevention yes
    OnAccessDisableDDD yes

The configuration above will result in non-recursive real-time protection of the /home/user/Downloads directory by ClamAV’s On-Access Scanner. Any access attempts that ClamAV detects on malicious files within the top level of the directory hierarchy will be blocked by fanotify at the kernel level.

Command Line Options for Versions >= 0.102

Beyond clamd.conf configuration, you can change the behavior of the On-Access scanner by passing in a number of command line options. A list of all options can be retrieved with --help, but below is a list and explanation of some of options you might find most useful.

  • --log=FILE (-l FILE) – passing this option is important if you want a record of scan results, otherwise clamonacc will operate silently.
  • --verbose (-v) – primarily for debugging as this will increase the amount of noise in your log by quite a lot, but useful for troubleshooting potential connection problems
  • --foreground (-F) – forces clamonacc to not for the background, which is useful for debugging potential issues with during startup or runtime
  • --include-list=FILE (-e FILE) – allows users to pass a list of directories for clamonacc to watch, each directory must be a full path and separated by a newline
  • --exclude-list=FILE (-e FILE) – same as include-list option, but for excluding at startup
  • --remove – after an infected verdict, an attempt will be made to remove the infected file
  • --move=DIRECTORY – just like the remove option, but infected file will be moved to the specified quarantine location instead
  • --copy=DIRECTORY – just like the move, except infected file is also left in place

 

 

 

Configuring Linux for Many Watch Folders

Last Updated: 2021-03-01

To run many (>100) push Watch Folders on Linux computers, adjust three system settings and then reload the sysctl.conf file to activate them.

Procedure

  1. Increase the maximum number of watches allowed by the system.

    Retrieve the current value by running the following command:

    $ cat /proc/sys/fs/inotify/max_user_watches
    8192

     

    To permanently increase the number of available watches (to a value that is greater than the number of files to watch, such as 524288), add the configuration to /etc/sysctl.conf:

    $ sudo echo "fs.inotify.max_user_watches=524288" >> /etc/sysctl.conf

     

  2. Increase the maximum number of inotify instances, which correspond to the number of allowed Watch Services instances.

    Retrieve the current value by running the following command:

    $ cat /proc/sys/fs/inotify/max_user_instances
    128

     

    On many systems, the default value is 128, meaning only 128 watches can be created. To permanently increase the number available (to a value that is greater than the number of desired Watch Folder instances, such as 1024), add the configuration to /etc/sysctl.conf:

    $ sudo echo "fs.inotify.max_user_instances=1024" >> /etc/sysctl.conf

     

  3. Increase the open file limit.

    Retrieve the current value by running the following command:

    $ cat /proc/sys/fs/file-max
    794120

     

    To permanently increase the open file limit (to a value that is greater than the number of desired watches, such as 2097152), add the configuration to /etc/sysctl.conf:

    $ sudo echo "fs.file-max=2097152" >> /etc/sysctl.conf

     

  4. Reload systemd settings to activate the new settings.

    To reload systemd settings, either reboot the machine or run the following command:

    $ sudo sysctl -p /etc/sysctl.conf

How To Configure Suricata as an Intrusion Prevention System (IPS) on Ubuntu 20.04

原文:

https://www.digitalocean.com/community/tutorials/how-to-configure-suricata-as-an-intrusion-prevention-system-ips-on-ubuntu-20-04

https://suricata.readthedocs.io/en/suricata-6.0.0/setting-up-ipsinline-for-linux.html

Introduction

In this tutorial you will learn how to configure Suricata’s built-in Intrusion Prevention System (IPS) mode on Ubuntu 20.04. By default Suricata is configured to run as an Intrusion Detection System (IDS), which only generates alerts and logs suspicious traffic. When you enable IPS mode, Suricata can actively drop suspicious network traffic in addition to generating alerts for further analysis.

Before enabling IPS mode, it is important to check which signatures you have enabled, and their default actions. An incorrectly configured signature, or a signature that is overly broad may result in dropping legitimate traffic to your network, or even block you from accessing your servers over SSH and other management protocols.

In the first part of this tutorial you will check the signatures that you have installed and enabled. You will also learn how to include your own signatures. Once you know which signatures you would like to use in IPS mode, you’ll convert their default action to drop or reject traffic. With your signatures in place, you’ll learn how to send network traffic through Suricata using the netfilter NFQUEUE iptables target, and then generate some invalid network traffic to ensure that Suricata drops it as expected.

Prerequisites

If you have been following this tutorial series then you should already have Suricata running on an Ubuntu 20.04 server.

If you still need to install Suricata then you can follow How To Install Suricata on Ubuntu 20.04

You should also have the ET Open Ruleset downloaded using the suricata-update command, and included in your Suricata signatures.

The jq command line JSON processing tool. If you do not have it installed from a previous tutorial, you can do so using the apt command:

sudo apt update
sudo apt install jq

You may also have custom signatures that you would like to use from the previous Understanding Suricata Signatures tutorial.

Step 1 — Including Custom Signatures

The previous tutorials in this series explored how to install and configure Suricata, as well as how to understand signatures. If you would like to create and include your own rules then you need to edit Suricata’s /etc/suricata/suricata.yaml file to include a custom path to your signatures.

First, let’s find your server’s public IPs so that you can use them in your custom signatures. To find your IPs you can use the ip command:

ip -brief address show

You should receive output like the following:

Output
lo UNKNOWN 127.0.0.1/8 ::1/128
eth0 UP 203.0.113.5/20 10.20.0.5/16 2001:DB8::1/32 fe80::94ad:d4ff:fef9:cee0/64
eth1 UP 10.137.0.2/16 fe80::44a2:ebff:fe91:5187/64

Your public IP address(es) will be similar to the highlighted 203.0.113.5 and 2001:DB8::1/32 IPs in the output.

Now let’s create the following custom signature to scan for SSH traffic to non-SSH ports and include it in a file called /var/lib/suricata/rules/local.rules. Open the file with nano or your preferred editor:

sudo nano /var/lib/suricata/rules/local.rules

Copy and paste the following signature:

Invalid SSH Traffic Signature

alert ssh any any -> 203.0.113.5 !22 (msg:"SSH TRAFFIC on non-SSH port"; flow:to_client, not_established; classtype: misc-attack; target: dest_ip; sid:1000000;)
alert ssh any any -> 2001:DB8::1/32 !22 (msg:"SSH TRAFFIC on non-SSH port"; flow:to_client, not_established; classtype: misc-attack; target: dest_ip; sid:1000001;)

Substitute your server’s public IP address in place of the 203.0.113.5 and 2001:DB8::1/32 addresses in the rule. If you are not using IPv6 then you can skip adding that signature in this and the following rules.

You can continue adding custom signatures to this local.rules file depending on your network and applications. For example, if you wanted to alert about HTTP traffic to non-standard ports, you could use the following signatures:

HTTP traffic on non-standard port signature

alert http any any -> 203.0.113.5 !80 (msg:"HTTP REQUEST on non-HTTP port"; flow:to_client, not_established; classtype:misc-activity; sid:1000002;)
alert http any any -> 2001:DB8::1/32 !80 (msg:"HTTP REQUEST on non-HTTP port"; flow:to_client, not_established; classtype:misc-activity; sid:1000003;)

To add a signature that checks for TLS traffic to ports other than the default 443 for web servers, add the following:

TLS traffic on non-standard port signature

alert tls any any -> 203.0.113.5 !443 (msg:"TLS TRAFFIC on non-TLS HTTP port"; flow:to_client, not_established; classtype:misc-activity; sid:1000004;)
alert tls any any -> 2001:DB8::1/32 !443 (msg:"TLS TRAFFIC on non-TLS HTTP port"; flow:to_client, not_established; classtype:misc-activity; sid:1000005;)

When you are done adding signatures, save and close the file. If you are using nano, you can do so with CTRL+X, then Y and ENTER to confirm. If you are using vi, press ESC and then 😡 then ENTER to save and exit.

Now that you have some custom signatures defined, edit Suricata’s /etc/suricata/suricata.yaml configuration file using nano or your preferred editor to include them:

sudo nano /etc/suricata/suricata.yaml

Find the rule-files: portion of the configuration. If you are using nano use CTRL+_ and then enter the line number 1879. If you are using vi enter 1879gg to go to the line. The exact location in your file may be different, but you should be in the correct general region of the file.

Edit the section and add the following highlighted – local.rules line:

/etc/suricata/suricata.yaml

. . .
rule-files:
- suricata.rules
- local.rules
. . .

Save and exit the file. Be sure to validate Suricata’s configuration after adding your rules. To do so run the following command:

sudo suricata -T -c /etc/suricata/suricata.yaml -v

The test can take some time depending on how many rules you have loaded in the default suricata.rules file. If you find the test takes too long, you can comment out the – suricata.rules line in the configuration by adding a # to the beginning of the line and then run your configuration test again. Be sure to remove the # comment if you plan to use the suricata.rules signature in your final running configuration.

Once you are satisfied with the signatures that you have created or included using the suricata-update tool, you can proceed to the next step, where you’ll switch the default action for your signatures from alert or log to actively dropping traffic.

Step 2 — Configuring Signature Actions

Now that you have your custom signatures tested and working with Suricata, you can change the action to drop or reject. When Suricata is operating in IPS mode, these actions will actively block invalid traffic for any matching signature.

These two actions are described in the previous tutorial in this series, Understanding Suricata Signatures. The choice of which action to use is up to you. A drop action will immediately discard a packet and any subsequent packets that belong to the network flow. A reject action will send both the client and server a reset packet if the traffic is TCP-based, and an ICMP error packet for any other protocol.

Let’s use the custom rules from the previous section and convert them to use the drop action, since the traffic that they match is likely to be a network scan, or some other invalid connection.

Open your /var/lib/suricata/rules/local.rules file using nano or your preferred editor and change the alert action at the beginning of each line in the file to drop:

sudo nano /var/lib/suricata/rules/local.rules

/var/lib/suricata/rules/local.rules

drop ssh any any -> 203.0.113.5 !22 (msg:"SSH TRAFFIC on non-SSH port"; classtype: misc-attack; target: dest_ip; sid:1000000;)
drop ssh any any -> 2001:DB8::1/32 !22 (msg:"SSH TRAFFIC on non-SSH port"; classtype: misc-attack; target: dest_ip; sid:1000001;)
. . .

Repeat the step above for any signatures in /var/lib/suricata/rules/suricata.rules that you would like to convert to drop or reject mode.

Note: If you ran suricata-update in the prerequisite tutorial, you may have more than 30,000 signatures included in your suricata.rules file.

If you convert every signature to drop or reject you risk blocking legitimate access to your network or servers. Instead, leave the rules in suricata.rules for the time being, and add your custom signatures to local.rules. Suricata will continue to generate alerts for suspicious traffic that is described by the signatures in suricata.rules while it is running in IPS mode.

After you have a few days or weeks of alerts collected, you can analyze them and choose the relevant signatures to convert to drop or reject based on their sid.

Once you have all the signatures configured with the action that you would like them to take, the next step is to reconfigure and then restart Suricata in IPS mode.

Step 3 — Enabling nfqueue Mode

Suricata runs in IDS mode by default, which means it will not actively block network traffic. To switch to IPS mode, you’ll need to edit Suricata’s /etc/default/suricata configuration file.

Open the file in nano or your preferred editor:

sudo nano /etc/default/suricata

Find the LISTENMODE=af-packet line and comment it out by adding a # to the beginning of the line. Then add a new line LISTENMODE=nfqueue line that tells Suricata to run in IPS mode.

Your file should have the following highlighted lines in it when you are done editing:

/etc/default/suricata

. . .
# LISTENMODE=af-packet
LISTENMODE=nfqueue
. . .

Save and close the file. Now you can restart Suricata using systemctl:

sudo systemctl restart suricata.service

Check Suricata’s status using systemctl:

sudo systemctl status suricata.service

You should receive output like the following:

 

Output
● suricata.service - LSB: Next Generation IDS/IPS
Loaded: loaded (/etc/init.d/suricata; generated)
Active: active (running) since Wed 2021-12-01 15:54:28 UTC; 2s ago
Docs: man:systemd-sysv-generator(8)
Process: 1452 ExecStart=/etc/init.d/suricata start (code=exited, status=0/SUCCESS)
Tasks: 12 (limit: 9513)
Memory: 63.6M
CGroup: /system.slice/suricata.service
└─1472 /usr/bin/suricata -c /etc/suricata/suricata.yaml --pidfile /var/run/suricata.pid -q 0 -D -vvv

Dec 01 15:54:28 suricata systemd[1]: Starting LSB: Next Generation IDS/IPS...
Dec 01 15:54:28 suricata suricata[1452]: Starting suricata in IPS (nfqueue) mode... done.
Dec 01 15:54:28 suricata systemd[1]: Started LSB: Next Generation IDS/IPS.

Note the highlighted active (running) line that indicates Suricata restarted successfully. Also note the Starting suricata in IPS (nfqueue) mode… done. line, which confirms Suricata is now running in IPS mode.

With this change you are now ready to send traffic to Suricata using the UFW firewall in the next step.

Step 4 — Configuring UFW To Send Traffic to Suricata

Now that you have configured Suricata to process traffic in IPS mode, the next step is to direct incoming packets to Suricata. If you followed the prerequisite tutorials for this series and are using an Ubuntu 20.04 system, you should have the Uncomplicated Firewall (UFW) installed and enabled.

To add the required rules for Suricata to UFW, you will need to edit the firewall files in the /etc/ufw/before.rules (IPv4 rules) and /etc/ufw/before6.rules (IPv6) directly.

Open the first file for IPv4 rules using nano or your preferred editor:

sudo nano /etc/ufw/before.rules

Near the beginning of the file, insert the following highlighted lines:

/etc/ufw/before.rules

(此处参考https://suricata.readthedocs.io/en/suricata-6.0.0/setting-up-ipsinline-for-linux.html,hosts规则)

. . .
# Don't delete these required lines, otherwise there will be errors
*filter
:ufw-before-input - [0:0]
:ufw-before-output - [0:0]
:ufw-before-forward - [0:0]
:ufw-not-local - [0:0]
# End required lines

## Start Suricata NFQUEUE rules
-I FORWARD -j NFQUEUE
-I OUTPUT -j NFQUEUE
## End Suricata NFQUEUE rules

# allow all on loopback
-A ufw-before-input -i lo -j ACCEPT
-A ufw-before-output -o lo -j ACCEPT
. . .

Save and exit the file when you are done editing it. Now add the same highlighted lines to the same section in the /etc/ufw/before6.rules file:

sudo nano /etc/ufw/before.rules

Ensure that both files have the same contents. Save and exit the file when you are done editing it.

The first two INPUT and OUTPUT rules are used to bypass Suricata so that you can connect to your server using SSH, even when Suricata is not running. Without these rules, an incorrect or overly broad signature could block your SSH access. Additionally, if Suricata is stopped, all traffic will be sent to the NFQUEUE target and then dropped since Suricata is not running.

The next FORWARD rule ensures that if your server is acting as a gateway for other systems, all that traffic will also go to Suricata for processing.

The final two INPUT and OUTPUT rules send all remaining traffic that is not SSH traffic to Suricata for processing.

Restart UFW to load the new rules:

sudo systemctl restart ufw.service

Note: If you are using another firewall you will need to modify these rules to match the format your firewall expects.

If you are using iptables, then you can insert these rules directly using the iptables and ip6tables commands. However, you will need to ensure that the rules are persistent across reboots with a tool like iptables-persistent.

If you are using firewalld, then the following rules will direct traffic to Suricata:

firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 0 -p tcp --dport 22 -j NFQUEUE --queue-bypass
firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 1 -j NFQUEUE
firewall-cmd --permanent --direct --add-rule ipv6 filter INPUT 0 -p tcp --dport 22 -j NFQUEUE --queue-bypass
firewall-cmd --permanent --direct --add-rule ipv6 filter INPUT 1 -j NFQUEUE

firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD 0 -j NFQUEUE
firewall-cmd --permanent --direct --add-rule ipv6 filter FORWARD 0 -j NFQUEUE

firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 0 -p tcp --sport 22 -j NFQUEUE --queue-bypass
firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 1 -j NFQUEUE
firewall-cmd --permanent --direct --add-rule ipv6 filter OUTPUT 0 -p tcp --sport 22 -j NFQUEUE --queue-bypass
firewall-cmd --permanent --direct --add-rule ipv6 filter OUTPUT 1 -j NFQUEUE

At this point in the tutorial you have Suricata configured to run in IPS mode, and your network traffic is being sent to Suricata by default. You will be able to restart your server at any time and your Suricata and firewall rules will be persistent.

The last step in this tutorial is to verify Suricata is dropping traffic correctly.

Step 5 — Testing Invalid Traffic

Now that you have Suricata and your firewall configured to process network traffic, you can test whether Suricata will drop packets that match your custom and other included signatures.

Recall signature sid:2100498 from the previous tutorial, which is modified in this example to drop matching packets:

sid:2100498

drop ip any any -> any any (msg:"GPL ATTACK_RESPONSE id check returned root"; content:"uid=0|28|root|29|"; classtype:bad-unknown; sid:2100498; rev:7; metadata:created_at 2010_09_23, updated_at 2010_09_23;)

Find and edit the rule in your /var/lib/suricata/rules/suricata.rules file to use the drop action if you have the signature included there. Otherwise, add the rule to your /var/lib/suricata/rules/local.rules file.

Send Suricata the SIGUSR2 signal to get it to reload its signatures:

sudo kill -usr2 $(pidof suricata)

Now test the rule using curl:

curl --max-time 5 http://testmynids.org/uid/index.html

You should receive an error stating that the request timed out, which indicates Suricata blocked the HTTP response:

Output
curl: (28) Operation timed out after 5000 milliseconds with 0 out of 39 bytes received

You can confirm that Suricata dropped the HTTP response using jq to examine the eve.log file:

jq 'select(.alert .signature_id==2100498)' /var/log/suricata/eve.json

You should receive output like the following:

Output
{
. . .
"community_id": "1:tw19kjR2LeWacglA094gRfEEuDU=",
"alert": {
"action": "blocked",
"gid": 1,
"signature_id": 2100498,
"rev": 7,
"signature": "GPL ATTACK_RESPONSE id check returned root",
"category": "Potentially Bad Traffic",
"severity": 2,
"metadata": {
"created_at": [
"2010_09_23"
],
"updated_at": [
"2010_09_23"
]
}
},
"http": {
"hostname": "testmynids.org",
"url": "/uid/index.html",
"http_user_agent": "curl/7.68.0",
"http_content_type": "text/html",
"http_method": "GET",
"protocol": "HTTP/1.1",
"status": 200,
"length": 39
},
. . .

The highlighted “action”: “blocked” line confirms that the signature matched, and Suricata dropped or rejected the test HTTP request.

Conclusion

In this tutorial you configured Suricata to block suspicious network traffic using its built-in IPS mode. You also added custom signatures to examine and block SSH, HTTP, and TLS traffic on non-standard ports. To tie everything together, you also added firewall rules to direct traffic through Suricata for processing.

Now that you have Suricata installed and configured in IPS mode, and can write your own signatures that either alert on or drop suspicious traffic, you can continue monitoring your servers and networks, and refining your signatures.

Once you are satisfied with your Suricata signatures and configuration, you can continue with the last tutorial in this series, which will guide you through sending logs from Suricata to a Security and Information Event Management (SIEM) system built using the Elastic Stack.

Virtualbox 安装Bliss OS

1.下载

https://sourceforge.net/projects/blissos-dev/files/Android-Generic/PC/aosp/gapps/12L/android_x86_64-a12.1_r1-03.16.22-01-mesa22-ksu-gapps-libndk-sd.iso/download

2、新建vbox虚拟机,系统选uefi,半虚拟化选kvm,显示设置禁用3D加速。

3、启动安装,硬盘大小8-16G,新建gpt分区,第一个分区为fat32 100m,剩下的为ex4分区。

4、编辑fat32分区/efi/boot/android.cfg,修改虚拟机屏幕分辨率

set gfxpayload=2560x1600

 

 

asus路由器ipv6设置

原文:https://rog.asus.com.cn/support/FAQ/113990

 

如何在路由器中设置IPv6?

请与您的ISP网络运营商确认IPv6信息 (例如:联机类型、IPv6地址和DSN设置等)

1. 请用浏览器输入  http://router.asus.com ,输入登录路由器的账号和密码。

2. 点击[高级设置]>[IPv6],[联机类型]请按照ISP网络运营商提供的信息进行设置。

  • 当您的外部网络(WAN) > 互联网连接 > WAN联机类型为 [PPPoE], 在IPv6联机类型请选择 [Native]
  • 当您的外部网络(WAN) > 互联网连接 > WAN联机类型为 [动态IP], 在IPv6联机类型请选择 [Passthrough]
  • 当您的外部网络(WAN) > 互联网连接 > WAN联机类型为 [静态IP], 在IPv6联机类型请选择 [静态 IPv6]
  • 其他IPv6类型,请与您的ISP确认需要填写的信息。

注意: 外部网络(WAN) > 互联网连接 > WAN联机类型一定要先设置。

Native 
3. 若选择IPv6联机类型为 [Native],建议设置方式为直接点击[应用本页面设置]。

保存设置后再回到IPv6的页面,当[IPv6内部网络设置]出现IPv6信息,即[Native]的设置就完成了。

静态IPv6 

4. 若选择IPv6联机类型为 [静态 IPv6] 请按照ISP网络运营商提供的信息进行设置,输入完成后点击[应用本页面设置] 保存设置即可。

举例如下(不同运营商,及不同地区会有差异)

栏位 IPv6
外部网络IPv6地址 2001:B030:2309:FF00::0001/64
外部网络IPv6网关 2001:B030:2309:FF00::FFFF/64
内部网络IPv6地址 2001:B030:2309:0000::/56

 

Passthrough

5. 若选择IPv6联机类型为 [Passthrough] ,点击[应用本页面设置] 保存设置即可。

 

注意:您可以通过以下网址确认IPv6连接情况  http://flets-v6.jp/

 

注意:

电信拨号获得的ipv6为动态ip,openwrt使用relay,asus路由器使用passthrough