系统使用一段时间后，莫名其妙出现卡顿现象。发现硬盘灯闪个不停。
经查，是snapd进程持续不停的往硬盘写入数据，同时也会占用CPU。
写入量不大，但是磁盘占用率出奇的高。
导致系统出现卡顿，这个问题从ubuntu18.04到20.04实测都有，更老的版本没有实测不妄加批评。
解决办法网上找了N圈也没有找到解决办法。所以，只好……
干掉它！
|
1 |
$ sudo apt purge snapd |
卸载后系统丝般顺滑。。
因为我暂时snap用的不多，加上也没别的办法，毕竟已经影响到系统的正常使用了，只好选择卸载。
有人说不能卸载，可以试试下面的命令：
|
1 |
$ sudo apt autoremove --purge snapd |
卸载之后，继续重装一下，貌似也不再出现问题。
以前通过 家里ADSL上网无固定外网IP的群晖NAS安全实现与公网MySQL服务器主从同步 配置之后，群晖自带的 MariaDB 10.3.21 可以非常流畅的与服务器上的 MySQL 7.x 版本进行主从同步。
前两天系统从 ubuntu 18.04 升级到 ubuntu 20.04 (MySQL 8.x)之后，发现已经无法进行主从同步。
报告如下错误：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 |
$ mysql -u root -p -e "show slave status\G;" Enter password: *************************** 1. row *************************** Slave_IO_State: Master_Host: 10.8.0.1 Master_User: repl1 Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.001242 Read_Master_Log_Pos: 8350259 Relay_Log_File: mysqld10-relay-bin.000510 Relay_Log_Pos: 424 Relay_Master_Log_File: mysql-bin.001222 Slave_IO_Running: No Slave_SQL_Running: No Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 22 Last_Error: Error 'Character set '#255' is not a compiled character set and is not specified in the '/usr/local/mariadb10/share/mysql/charsets/Index.xml' file' on query. Default database: 'wordpress'. Query: 'BEGIN' Skip_Counter: 0 Exec_Master_Log_Pos: 125 Relay_Log_Space: 137841279 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: Yes Master_SSL_CA_File: /var/packages/MariaDB10/etc/ssl/ca.pem Master_SSL_CA_Path: /var/packages/MariaDB10/etc/ssl Master_SSL_Cert: /var/packages/MariaDB10/etc/ssl/client-cert.pem Master_SSL_Cipher: Master_SSL_Key: /var/packages/MariaDB10/etc/ssl/client-key.pem Seconds_Behind_Master: NULL Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 22 Last_SQL_Error: Error 'Character set '#255' is not a compiled character set and is not specified in the '/usr/local/mariadb10/share/mysql/charsets/Index.xml' file' on query. Default database: 'wordpress'. Query: 'BEGIN' Replicate_Ignore_Server_Ids: Master_Server_Id: 1 Master_SSL_Crl: /var/packages/MariaDB10/etc/ssl/ca.pem Master_SSL_Crlpath: /var/packages/MariaDB10/etc/ssl Using_Gtid: No Gtid_IO_Pos: Replicate_Do_Domain_Ids: Replicate_Ignore_Domain_Ids: Parallel_Mode: conservative SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Slave_DDL_Groups: 0 Slave_Non_Transactional_Groups: 0 Slave_Transactional_Groups: 0 |
网上查询很久，找到原因 MySQL 8.016 master with MariaDB 10.2 slave on AWS RDS, Character set '#255' is not a compiled character set
This could be a serious problem when replicating between MySQL 8.0 and MariaDB 10.x.
The default (for good technical reasons) COLLATION for the 8.0 is utf8mb4_0900_ai_ci. Note the "255" associated with it. MariaDB has not yet adopted the Unicode 9.0 collations.
Furthermore, Oracle (MySQL 8.0) did a major rewrite of the collation code, thereby possibly making collation tables incompatible.
A probable fix is to switch to the next best general-purpose collation, utf8mb4_unicode_520_ci (246) (based on Unicode 5.20). This would require ALTERing all the columns' collations. ALTER TABLE .. CONVERT TO .. might be the fastest way. Those could be generated via a SELECT .. information_schema.tables ....
8.0.17:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 |
mysql> show collation like 'utf8mb4%'; +----------------------------+---------+-----+---------+----------+---------+---------------+ | Collation | Charset | Id | Default | Compiled | Sortlen | Pad_attribute | +----------------------------+---------+-----+---------+----------+---------+---------------+ | utf8mb4_0900_ai_ci | utf8mb4 | 255 | Yes | Yes | 0 | NO PAD | | utf8mb4_0900_as_ci | utf8mb4 | 305 | | Yes | 0 | NO PAD | | utf8mb4_0900_as_cs | utf8mb4 | 278 | | Yes | 0 | NO PAD | | utf8mb4_0900_bin | utf8mb4 | 309 | | Yes | 1 | NO PAD | | utf8mb4_bin | utf8mb4 | 46 | | Yes | 1 | PAD SPACE | | utf8mb4_croatian_ci | utf8mb4 | 245 | | Yes | 8 | PAD SPACE | | utf8mb4_cs_0900_ai_ci | utf8mb4 | 266 | | Yes | 0 | NO PAD | | utf8mb4_cs_0900_as_cs | utf8mb4 | 289 | | Yes | 0 | NO PAD | | utf8mb4_czech_ci | utf8mb4 | 234 | | Yes | 8 | PAD SPACE | | utf8mb4_danish_ci | utf8mb4 | 235 | | Yes | 8 | PAD SPACE | | utf8mb4_da_0900_ai_ci | utf8mb4 | 267 | | Yes | 0 | NO PAD | | utf8mb4_da_0900_as_cs | utf8mb4 | 290 | | Yes | 0 | NO PAD | | utf8mb4_de_pb_0900_ai_ci | utf8mb4 | 256 | | Yes | 0 | NO PAD | | utf8mb4_de_pb_0900_as_cs | utf8mb4 | 279 | | Yes | 0 | NO PAD | | utf8mb4_eo_0900_ai_ci | utf8mb4 | 273 | | Yes | 0 | NO PAD | | utf8mb4_eo_0900_as_cs | utf8mb4 | 296 | | Yes | 0 | NO PAD | | utf8mb4_esperanto_ci | utf8mb4 | 241 | | Yes | 8 | PAD SPACE | | utf8mb4_estonian_ci | utf8mb4 | 230 | | Yes | 8 | PAD SPACE | | utf8mb4_es_0900_ai_ci | utf8mb4 | 263 | | Yes | 0 | NO PAD | | utf8mb4_es_0900_as_cs | utf8mb4 | 286 | | Yes | 0 | NO PAD | | utf8mb4_es_trad_0900_ai_ci | utf8mb4 | 270 | | Yes | 0 | NO PAD | | utf8mb4_es_trad_0900_as_cs | utf8mb4 | 293 | | Yes | 0 | NO PAD | | utf8mb4_et_0900_ai_ci | utf8mb4 | 262 | | Yes | 0 | NO PAD | | utf8mb4_et_0900_as_cs | utf8mb4 | 285 | | Yes | 0 | NO PAD | | utf8mb4_general_ci | utf8mb4 | 45 | | Yes | 1 | PAD SPACE | | utf8mb4_german2_ci | utf8mb4 | 244 | | Yes | 8 | PAD SPACE | | utf8mb4_hr_0900_ai_ci | utf8mb4 | 275 | | Yes | 0 | NO PAD | | utf8mb4_hr_0900_as_cs | utf8mb4 | 298 | | Yes | 0 | NO PAD | | utf8mb4_hungarian_ci | utf8mb4 | 242 | | Yes | 8 | PAD SPACE | | utf8mb4_hu_0900_ai_ci | utf8mb4 | 274 | | Yes | 0 | NO PAD | | utf8mb4_hu_0900_as_cs | utf8mb4 | 297 | | Yes | 0 | NO PAD | | utf8mb4_icelandic_ci | utf8mb4 | 225 | | Yes | 8 | PAD SPACE | | utf8mb4_is_0900_ai_ci | utf8mb4 | 257 | | Yes | 0 | NO PAD | | utf8mb4_is_0900_as_cs | utf8mb4 | 280 | | Yes | 0 | NO PAD | | utf8mb4_ja_0900_as_cs | utf8mb4 | 303 | | Yes | 0 | NO PAD | | utf8mb4_ja_0900_as_cs_ks | utf8mb4 | 304 | | Yes | 24 | NO PAD | | utf8mb4_latvian_ci | utf8mb4 | 226 | | Yes | 8 | PAD SPACE | | utf8mb4_la_0900_ai_ci | utf8mb4 | 271 | | Yes | 0 | NO PAD | | utf8mb4_la_0900_as_cs | utf8mb4 | 294 | | Yes | 0 | NO PAD | | utf8mb4_lithuanian_ci | utf8mb4 | 236 | | Yes | 8 | PAD SPACE | | utf8mb4_lt_0900_ai_ci | utf8mb4 | 268 | | Yes | 0 | NO PAD | | utf8mb4_lt_0900_as_cs | utf8mb4 | 291 | | Yes | 0 | NO PAD | | utf8mb4_lv_0900_ai_ci | utf8mb4 | 258 | | Yes | 0 | NO PAD | | utf8mb4_lv_0900_as_cs | utf8mb4 | 281 | | Yes | 0 | NO PAD | | utf8mb4_persian_ci | utf8mb4 | 240 | | Yes | 8 | PAD SPACE | | utf8mb4_pl_0900_ai_ci | utf8mb4 | 261 | | Yes | 0 | NO PAD | | utf8mb4_pl_0900_as_cs | utf8mb4 | 284 | | Yes | 0 | NO PAD | | utf8mb4_polish_ci | utf8mb4 | 229 | | Yes | 8 | PAD SPACE | | utf8mb4_romanian_ci | utf8mb4 | 227 | | Yes | 8 | PAD SPACE | | utf8mb4_roman_ci | utf8mb4 | 239 | | Yes | 8 | PAD SPACE | | utf8mb4_ro_0900_ai_ci | utf8mb4 | 259 | | Yes | 0 | NO PAD | | utf8mb4_ro_0900_as_cs | utf8mb4 | 282 | | Yes | 0 | NO PAD | | utf8mb4_ru_0900_ai_ci | utf8mb4 | 306 | | Yes | 0 | NO PAD | | utf8mb4_ru_0900_as_cs | utf8mb4 | 307 | | Yes | 0 | NO PAD | | utf8mb4_sinhala_ci | utf8mb4 | 243 | | Yes | 8 | PAD SPACE | | utf8mb4_sk_0900_ai_ci | utf8mb4 | 269 | | Yes | 0 | NO PAD | | utf8mb4_sk_0900_as_cs | utf8mb4 | 292 | | Yes | 0 | NO PAD | | utf8mb4_slovak_ci | utf8mb4 | 237 | | Yes | 8 | PAD SPACE | | utf8mb4_slovenian_ci | utf8mb4 | 228 | | Yes | 8 | PAD SPACE | | utf8mb4_sl_0900_ai_ci | utf8mb4 | 260 | | Yes | 0 | NO PAD | | utf8mb4_sl_0900_as_cs | utf8mb4 | 283 | | Yes | 0 | NO PAD | | utf8mb4_spanish2_ci | utf8mb4 | 238 | | Yes | 8 | PAD SPACE | | utf8mb4_spanish_ci | utf8mb4 | 231 | | Yes | 8 | PAD SPACE | | utf8mb4_sv_0900_ai_ci | utf8mb4 | 264 | | Yes | 0 | NO PAD | | utf8mb4_sv_0900_as_cs | utf8mb4 | 287 | | Yes | 0 | NO PAD | | utf8mb4_swedish_ci | utf8mb4 | 232 | | Yes | 8 | PAD SPACE | | utf8mb4_tr_0900_ai_ci | utf8mb4 | 265 | | Yes | 0 | NO PAD | | utf8mb4_tr_0900_as_cs | utf8mb4 | 288 | | Yes | 0 | NO PAD | | utf8mb4_turkish_ci | utf8mb4 | 233 | | Yes | 8 | PAD SPACE | | utf8mb4_unicode_520_ci | utf8mb4 | 246 | | Yes | 8 | PAD SPACE | | utf8mb4_unicode_ci | utf8mb4 | 224 | | Yes | 8 | PAD SPACE | | utf8mb4_vietnamese_ci | utf8mb4 | 247 | | Yes | 8 | PAD SPACE | | utf8mb4_vi_0900_ai_ci | utf8mb4 | 277 | | Yes | 0 | NO PAD | | utf8mb4_vi_0900_as_cs | utf8mb4 | 300 | | Yes | 0 | NO PAD | | utf8mb4_zh_0900_as_cs | utf8mb4 | 308 | | Yes | 0 | NO PAD | +----------------------------+---------+-----+---------+----------+---------+---------------+ 75 rows in set (0.01 sec) |
MariaDB 10.2.30:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 |
mysql> SHOW COLLATION LIKE 'utf8mb4%'; +------------------------------+---------+------+---------+----------+---------+ | Collation | Charset | Id | Default | Compiled | Sortlen | +------------------------------+---------+------+---------+----------+---------+ | utf8mb4_general_ci | utf8mb4 | 45 | Yes | Yes | 1 | | utf8mb4_bin | utf8mb4 | 46 | | Yes | 1 | | utf8mb4_unicode_ci | utf8mb4 | 224 | | Yes | 8 | | utf8mb4_icelandic_ci | utf8mb4 | 225 | | Yes | 8 | | utf8mb4_latvian_ci | utf8mb4 | 226 | | Yes | 8 | | utf8mb4_romanian_ci | utf8mb4 | 227 | | Yes | 8 | | utf8mb4_slovenian_ci | utf8mb4 | 228 | | Yes | 8 | | utf8mb4_polish_ci | utf8mb4 | 229 | | Yes | 8 | | utf8mb4_estonian_ci | utf8mb4 | 230 | | Yes | 8 | | utf8mb4_spanish_ci | utf8mb4 | 231 | | Yes | 8 | | utf8mb4_swedish_ci | utf8mb4 | 232 | | Yes | 8 | | utf8mb4_turkish_ci | utf8mb4 | 233 | | Yes | 8 | | utf8mb4_czech_ci | utf8mb4 | 234 | | Yes | 8 | | utf8mb4_danish_ci | utf8mb4 | 235 | | Yes | 8 | | utf8mb4_lithuanian_ci | utf8mb4 | 236 | | Yes | 8 | | utf8mb4_slovak_ci | utf8mb4 | 237 | | Yes | 8 | | utf8mb4_spanish2_ci | utf8mb4 | 238 | | Yes | 8 | | utf8mb4_roman_ci | utf8mb4 | 239 | | Yes | 8 | | utf8mb4_persian_ci | utf8mb4 | 240 | | Yes | 8 | | utf8mb4_esperanto_ci | utf8mb4 | 241 | | Yes | 8 | | utf8mb4_hungarian_ci | utf8mb4 | 242 | | Yes | 8 | | utf8mb4_sinhala_ci | utf8mb4 | 243 | | Yes | 8 | | utf8mb4_german2_ci | utf8mb4 | 244 | | Yes | 8 | | utf8mb4_croatian_mysql561_ci | utf8mb4 | 245 | | Yes | 8 | | utf8mb4_unicode_520_ci | utf8mb4 | 246 | | Yes | 8 | <-- | utf8mb4_vietnamese_ci | utf8mb4 | 247 | | Yes | 8 | | utf8mb4_croatian_ci | utf8mb4 | 608 | | Yes | 8 | | utf8mb4_myanmar_ci | utf8mb4 | 609 | | Yes | 8 | | utf8mb4_thai_520_w2 | utf8mb4 | 610 | | Yes | 4 | | utf8mb4_general_nopad_ci | utf8mb4 | 1069 | | Yes | 1 | | utf8mb4_nopad_bin | utf8mb4 | 1070 | | Yes | 1 | | utf8mb4_unicode_nopad_ci | utf8mb4 | 1248 | | Yes | 8 | | utf8mb4_unicode_520_nopad_ci | utf8mb4 | 1270 | | Yes | 8 | +------------------------------+---------+------+---------+----------+---------+ 33 rows in set (0.00 sec) |
目前暂时没打算修改主服务器上的数据库，暂时等 MariaDB 更新吧。
笛卡尔乘积是指在数学中，两个集合X和Y的笛卡尔积（Cartesian product），又称直积，表示为X×Y，第一个对象是X的成员而第二个对象是Y的所有可能有序对的其中一个成员。
假设集合A={a, b}，集合B={0, 1, 2}，则两个集合的笛卡尔积为{(a, 0), (a, 1), (a, 2), (b, 0), (b, 1), (b, 2)}。
Iptables的recent模块用于限制一段时间内的连接数, 是谨防大量请求攻击的必杀绝技! 善加利用该模块可充分保证服务器安全。
recent常用参数
recent模块需要注意的地方
recent命令大体有如下三个排列组合
基本是上面这三项的排列组合;
下面通过几个案例进行说明
1) 利用iptables的recent模块来抵御简单的DOS攻击, 下面以限制ssh远程连接为例
|
1 2 3 4 5 |
$ iptables -I INPUT -p tcp --dport 22 -m connlimit --connlimit-above 3 -j DROP $ iptables -I INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH $ iptables -I INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 300 --hitcount 3 --name SSH -j DROP |
以上三条规则的解释如下：
|
1 |
$ iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --name SSH --second 300 --hitcount 3 -j LOG --log-prefix "SSH Attack" |
recent模块可以看作iptables里面维护了一个地址列表，这个地址列表可以通过"--set"、"--update"、"--rcheck"、"--remove"四种方法来修改列表，每次使用时只能选用一种。 还可附带"--name"参数来指 定列表的名字（默认为DEFAULT），"--rsource"、"--rdest"指示当前方法应用到数据包的源地址还是目的地址（默认是前者）。recent语句都带有布尔型返回值，每次执行若结果为真，则会执行后续的语句，比如"-j ACCEPT"之类的。"--seconds"参数表示限制包地址被记录进列表的时间要小于等于后面的时间。
基于上面的说明，现在来看四个基本方法的作用：
例1：限制无法ssh直接连接服务器，需先用较大包ping一下，此时在15秒内才可以连接上
|
1 2 3 4 5 6 7 8 9 10 11 |
$ iptables -P INPUT DROP $ iptables -A INPUT -s 127.0.0.1/32 -j ACCEPT $ iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT $ iptables -A INPUT -p icmp --icmp-type 8 -m length --length 128 -m recent --set --name SSHOPEN --rsource -j ACCEPT $ iptables -A INPUT -p icmp --icmp-type 8 -j ACCEPT $ iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --rcheck --seconds 15 --name SSHOPEN --rsource -j ACCEPT |
以上命令解说
例2: 限制每ip在一分钟内最多对服务器只能有8个http连接
|
1 2 3 4 5 |
$ iptables -I INPUT -p tcp --dport 80 -d 192.168.10.10 -m state --state NEW -m recent --name httpuser --set $ iptables -A INPUT -m recent --update --name httpuser --seconds 60 --hitcount 9 -j LOG --log-prefix 'HTTP attack: ' $ iptables -A INPUT -m recent --update --name httpuser --seconds 60 --hitcount 9 -j DROP |
以上命令解说
2) 对连接到服务器B的SSH连接进行限制，每个IP每小时只限连接5次
|
1 2 |
-A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name SSHPOOL --rcheck --seconds 3600 --hitcount 5 -j DROP -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name SSHPOOL --set -j ACCEPT |
服务器A连接服务器B的SSH服务的数据包流程，假设以下数据包是在一小时(3600秒)内到达服务器B(iptables配置如上)的：
实际上recent的处理更为复杂, 从上面的流程可以看出，--set的功能在于计录数据包，将源IP加入列表。--rcheck（update）的功能在于判定数据包在seconds和hitcount条件下是否要DROP。
如果采用下面的配置, 则必须在INPUT链的默认策略为ACCEPT的情况下才能生效并使用, 否则(即INPUT链的默认策略为DROP)所有的SSH包都被丢弃了!!!!
|
1 2 3 |
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT //必须添加这个前提条件才能生效! -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name SSHPOOL --set -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name SSHPOOL --rcheck --seconds 3600 --hitcount 5 -j DROP |
这个命令与上面命令的区别在于：set句在前，且set句不带-j ACCEPT。这导致数据包的流程也不同。
从上面可以看出，在使用recent模块的命令的时候，一定要先确认iptables的INPUT链的默认策略是什么。
接着说下--rcheck 和 --update的区别 --rcheck从第1个包开始计算时间，--update是在rcheck的基础上增加了从最近的DROP包开始计算阻断时间，具有准许时间和阻断时间，update会更新last-seen时间戳。
就拿上面那个配置案例来说, rcheck是接收到第1个数据包时开始计时，一个小时内仅限5次连接，后续的包丢弃，直到一小时过后又可以继续连接。update则是接收到第1个数据包时计算准许时间，在一个小时的准许时间内仅限5次连接，当有包被丢弃时，从最近的丢弃包开始计算阻断时间，在一个小时的阻断时间内没有接收到包，才可以继续连接。所以rcheck类似令牌桶，一小时给你5次，用完了抱歉等下个小时吧。update类似网银，连续输错5次密码，停止一小时，只不过update更严格，阻断时间是从最近的一次输错时间开始算，比如输错了5次，过了半个小时又输错一次，这时阻断时间不是剩半小时，而是从第6次重新计算，剩一小时.
可以拿下面这个命令进行测试, 自行替换rcheck、update，然后ping一下就明白了：
|
1 2 3 4 5 |
-A INPUT -p icmp -m recent --name PINGPOOL --rcheck --seconds 30 --hitcount 5 -j DROP -A INPUT -p icmp -m recent --name PINGPOOL --set -j ACCEPT -A INPUT -p icmp -m recent --name PINGPOOL --update --seconds 30 --hitcount 5 -j DROP -A INPUT -p icmp -m recent --name PINGPOOL --set -j ACCEPT |
温馨提示: ICMP包和UDP包在iptables中的state情况是一样的，因为是无状态的，不同于TCP，iptables可以靠SYN等flags确定state，而iptables是基于ICMP包/UDP包到达服务器的间隔时间来确定state的。比如在做上面测试的时候，使用ping 192.168.10.10 -t时，除了第一个ICMP包state是NEW，后续的包state都是ESTABLISHED，结果因为前面有一句:
|
1 |
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT |
结果测试ping一直是通的，这个一定要弄明白!
3) 限制80端口60秒内每个IP只能发起10个新连接，超过记录日记及丢失数据包，可防CC及非伪造IP的syn flood
|
1 2 3 4 5 |
$ iptables -A INPUT -p tcp --dport 80 --syn -m recent --name webpool --rcheck --seconds 60 --hitcount 10 -j LOG --log-prefix 'DDOS:' --log-ip-options $ iptables -A INPUT -p tcp --dport 80 --syn -m recent --name webpool --rcheck --seconds 60 --hitcount 10 -j DROP $ iptables -A INPUT -p tcp --dport 80 --syn -m recent --name webpool --set -j ACCEPT |
以上命令解说
发送特定指定执行相应操作，按上面设置, 如果自己IP被阻止了，可设置解锁。
|
1 2 3 4 5 |
$ iptables -A INPUT -p tcp --dport 5000 --syn -j LOG --log-prefix "WEBOPEN: " #记录日志，前缀WEBOPEN: $ iptables -A INPUT -p tcp --dport 5000 --syn -m recent --remove --name webpool --rsource -j REJECT --reject-with tcp-reset #符合规则即删除webpool列表内的本IP记录 |
4) 默认封闭SSH端口，为您的SSH服务器设置开门暗语
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
$ iptables -A INPUT -p tcp --dport 50001 --syn -j LOG --log-prefix "SSHOPEN: " #记录日志，前缀SSHOPEN: $ iptables -A INPUT -p tcp --dport 50001 --syn -m recent --set --name sshopen --rsource -j REJECT --reject-with tcp-reset #目标端口tcp 50001的新数据设定列表为sshopen返回TCP重置，并记录源地址。 $ iptables -A INPUT -p tcp --dport 22 --syn -m recent --rcheck --seconds 15 --name sshopen --rsource -j ACCEPT #开启SSH端口，15秒内允许记录的源地址登录SSH。 #开门钥匙 nc host 50001 telnet host 50001 nmap -sS host 50001 |
5) 指定端口容易被破解密钥，可以使用ping指定数据包大小为开门钥匙
|
1 2 3 4 5 6 7 |
$ iptables -A INPUT -p icmp --icmp-type 8 -m length --length 78 -j LOG --log-prefix "SSHOPEN: " #记录日志，前缀SSHOPEN: $ iptables -A INPUT -p icmp --icmp-type 8 -m length --length 78 -m recent --set --name sshopen --rsource -j ACCEPT #指定数据包78字节，包含IP头部20字节，ICMP头部8字节。 $ iptables -A INPUT -p tcp --dport 22 --syn -m recent --rcheck --seconds 15 --name sshopen --rsource -j ACCEPT |
按照上面配置后, 依然无法ssh登录到指定主机, 因为没有添加"INPUT链的默认策略为ACCEPT"的前提, 即需要下面这个前提条件!
|
1 |
$ iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT |
整理后的配置规则
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
$ iptables -F $ iptables -X $ iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT $ iptables -A INPUT -p icmp --icmp-type 8 -m length --length 78 -j LOG --log-prefix 'SSH_OPEN_KEY' $ iptables -A INPUT -p icmp --icmp-type 8 -m length --length 78 -m recent --name openssh --set --rsource -j ACCEPT $ iptables -A INPUT -p tcp --dport 22 --syn -m state --name openssh --rcheck --seconds 60 --rsource -j ACCEPT $ iptables -P INPUT DROP |
针对上面整理后的配置规则说明
调试过程：
在客户机上，如果需要ssh到主机，需要先ping主机进行解锁
|
1 2 |
$ ping -s 50 ip #linux主机的ip $ ping -l 50 ip #windows主机的ip |
并在一分钟之内ssh到主机，这样在/proc/net/xt_recent/目录下生成openssh文件, 内容如下:
|
1 2 3 4 |
src=192.168.10.10 ttl: 53 last_seen: 42963x6778 oldest_pkt: 1 4296376778, 4295806644, 4295806895, 4295807146, 4295826619, 4295826870, 4295827122, 4295827372, 4295833120, 4295833369, 4295834525, 4295834777, 4295872016, 4295872267, 4295872519, 4295872769, 4295889154, 4295889406, 4295889658, 4295889910 |
最近一直在做前端js错误监控的工作，在不断的打磨和完善中，发现里面还是知识点不少，现在就前端js错误监控做一些笔记和总结
我们知道前端js错误监控主要是利用了window.onerror函数来实现，onerror函数会在页面发生js错误时被调用。
|
1 |
window.onerror = function(message, source, lineno, colno, error) { ... } |
我们可以看到函数正常是可以收集到错误字符串信息、发生错误的js文件，错误所在的行数、列数、和Error对象（里面会有调用堆栈信息等）。
我们只需要把这些信息回传到server端即可，再配合sourcemap的话我们就可以知道是源码中的哪一行出错了，从而实现完美的错误实时监控系统了。然而要完美还是需要做很多工作的。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
$ sudo apt-get install rsync # ubuntu 16.04/18.04默认源中都存在rssh ,但是 ubuntu 20.04开始，已经没办法从系统源中安装了。 # 原因在于 rssh 存在安全漏洞，并且长时间没有修复，并且已经没人维护了，我们使用rrsync替代 $ export RSH_RSYNC_USER=rsh_backup $ export RSH_RSYNC_USER_PASSWORD=rsh_password # 如果需要备份/var/log 目录，建议把用户组设置成 adm 用户组，否则很多日志没办法读取 # sudo useradd -s "" $RSH_RSYNC_USER -g users -G adm # 后期也可以通过 sudo usermod -g users -G adm $RSH_RSYNC_USER 更改用户组 # 不配置任何登陆默认shell，以便于 rrsync 接管 $ sudo useradd -s "" $RSH_RSYNC_USER $ echo $RSH_RSYNC_USER:$RSH_RSYNC_USER_PASSWORD | sudo chpasswd # 创建配置文件目录，增加配置信息 $ sudo mkdir /home/$RSH_RSYNC_USER $ sudo chown -R $RSH_RSYNC_USER /home/$RSH_RSYNC_USER $ sudo mkdir /home/$RSH_RSYNC_USER/.ssh $ sudo chown -R $RSH_RSYNC_USER /home/$RSH_RSYNC_USER/.ssh $ sudo touch /home/$RSH_RSYNC_USER/.ssh/authorized_keys $ sudo chown -R $RSH_RSYNC_USER /home/$RSH_RSYNC_USER/.ssh/authorized_keys # 配置许可访问的目录 $ echo 'command="/usr/bin/rrsync -ro /var/www /data/",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding' | sudo tee /home/$RSH_RSYNC_USER/.ssh/authorized_keys |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
$ export RSH_RSYNC_USER=rsh_backup $ export RSH_RSYNC_USER_PASSWORD=rsh_password $ export RSH_RSYNC_PORT=22 $ export REMOTE_SERVER=www.mobibrw.com $ export SYNC_DIR=/var/www # 测试是否可以正常工作，另一个方面是许可ssh的登录key否则我们后续没办法使用sshpass # 可以使用 --exclude 参数忽略指定的目录,相对路径，不是绝对路径 $ sudo rsync -avzP --delete -e 'ssh -p $RSH_RSYNC_PORT' $RSH_RSYNC_USER@$REMOTE_SERVER:$SYNC_DIR $SYNC_DIR |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 |
# 安装密码自动填写软件 $ sudo apt-get install sshpass $ cd ~ $ touch backup_rsync.sh $ chmod +x backup_rsync.sh $ echo -e '#!'"/bin/bash\n" >> backup_rsync.sh $ sed -i '$a\export RSH_RSYNC_USER=rsh_backup' backup_rsync.sh $ sed -i '$a\export RSH_RSYNC_USER_PASSWORD=rsh_password' backup_rsync.sh $ sed -i '$a\export RSH_RSYNC_PORT=22' backup_rsync.sh $ sed -i '$a\export REMOTE_SERVER=www.mobibrw.com' backup_rsync.sh # 此处注意最后的分隔符/如果没有这个分隔符，会导致目标目录多一个名为www的父目录 $ sed -i '$a\export SYNC_DIR=/var/www/' backup_rsync.sh # 可以使用 --exclude 参数忽略指定的目录，相对路径，不是绝对路径 $ sed -i '$a\sshpass -p $RSH_RSYNC_USER_PASSWORD rsync -avzP --delete -e \"ssh -p $RSH_RSYNC_PORT\" $RSH_RSYNC_USER@$REMOTE_SERVER:$SYNC_DIR $SYNC_DIR' backup_rsync.sh # 打开计划任务的日志，默认不开 $ sudo sed -i -r "s/#cron\.\*[ \t]*\/var\/log\/cron.log/cron.* \/var\/log\/cron.log/g" /etc/rsyslog.d/50-default.conf #write out current crontab $ sudo crontab -l > addcron #echo new cron into cron file ,每隔30分钟我们调度一次任务,前面是文件锁，防止并发冲突 #如果需要每小时执行一次，则修改为 "* */1 * * * flock ...." #如果需要凌晨2点执行，则修改为 "* 2 * * * flock ...." $ echo "30 * * * * flock -x -w 10 /dev/shm/backup_rsync_corn.lock -c \"bash `echo ~`/backup_rsync.sh\"" >> addcron #install new cron file $ sudo crontab addcron $ rm addcron $ sudo service cron restart |
目前我的阿里云，腾讯云服务器之间的同步脚本如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
#!/bin/bash export RSH_RSYNC_USER=user export RSH_RSYNC_USER_PASSWORD=password export RSH_RSYNC_PORT=22 export REMOTE_SERVER=121.199.27.227 export SYNC_WWW_DIR=/var/www/ sshpass -p $RSH_RSYNC_USER_PASSWORD rsync -avzP --delete -e "ssh -p $RSH_RSYNC_PORT" $RSH_RSYNC_USER@$REMOTE_SERVER:$SYNC_WWW_DIR $SYNC_WWW_DIR --exclude "wordpress/wp-content/cache/" --exclude "wordpress/wp-content/plugins/crayon-syntax-highlighter/log.txt" export SYNC_DATA_DIR=/data/ # 此处注意，如果使用 --exclude "/root/" 则忽略最顶部的root目录 # 如果使用 --exclude "root/" 则忽略所有路径中包含 root 的目录 # 主要 rsync 的 top-directroty 部分的规则 sshpass -p $RSH_RSYNC_USER_PASSWORD rsync -avzP --delete -e "ssh -p $RSH_RSYNC_PORT" $RSH_RSYNC_USER@$REMOTE_SERVER:$SYNC_DATA_DIR $RSYNC_DATA_DIR --exclude "/root/" |
I have a Ubuntu 18.04/20.04 server running ufw (Uncomplicated Firewall) and Docker. Docker relies on iptables-persistent, which is an interface to a much more powerful and complicated firewall that many people would rather avoid.
The problem here is that ufw and iptables-persistent are both ways for creating the same firewall. On my server, only one service would ever run at startup negating the other.
After a reboot ufw would always be disabled.
|
1 2 3 |
$ sudo ufw status Status: inactive |
Even though the ufw service is enabled, if you look closely, the active service has exited.
|
1 2 3 4 5 |
$ sudo systemctl status ufw ● ufw.service - Uncomplicated firewall Loaded: loaded (/lib/systemd/system/ufw.service; enabled; vendor preset: enabled) Active: active (exited) |
If I check the server services, both ufw and netfilter-persistent are enabled. netfilter-persistent is a means for managing iptables on Debian and Ubuntu systems.
|
1 2 3 4 |
$ sudo service --status-all [ + ] netfilter-persistent [ + ] ufw |
The fix is simple; we need to tell the operating system to load ufw after the netfilter-persistent.
Find and backup the ufw service.
|
1 2 3 |
$ ls -l /lib/systemd/system/ufw.service -rw-r--r-- 1 root root 266 Aug 15 2017 ufw.service |
|
1 2 3 |
$ cd /lib/systemd/system/ $ sudo cp ufw.service ufw.service.original |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
$ cat /lib/systemd/system/ufw.service [Unit] Description=Uncomplicated firewall Documentation=man:ufw(8) DefaultDependencies=no Before=network.target [Service] Type=oneshot RemainAfterExit=yes ExecStart=/lib/ufw/ufw-init start quiet ExecStop=/lib/ufw/ufw-init stop [Install] WantedBy=multi-user.target |
Update and save the modified service by appending After=netfilter-persistent.service to the [Unit] block.
|
1 |
$ sudo nano /lib/systemd/system/ufw.service |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
[Unit] Description=Uncomplicated firewall Documentation=man:ufw(8) DefaultDependencies=no Before=network.target After=netfilter-persistent.service [Service] Type=oneshot RemainAfterExit=yes ExecStart=/lib/ufw/ufw-init start quiet ExecStop=/lib/ufw/ufw-init stop [Install] WantedBy=multi-user.target |
Reboot and test.
|
1 |
$ sudo reboot |
|
1 2 3 4 5 6 7 |
$ sudo ufw status Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere Nginx Full ALLOW Anywhere |
Any service that is exposed to the Internet is at risk of malware attacks. For example, if you are running a service on a publicly available network, attackers can use brute-force attempts to sign in to your account.
Fail2ban is a tool that helps protect your Linux machine from brute-force and other automated attacks by monitoring the services logs for malicious activity. It uses regular expressions to scan log files. All entries matching the patterns are counted, and when their number reaches a certain predefined threshold, Fail2ban bans the offending IP using the system firewall for a specific length of time. When the ban period expires, the IP address is removed from the ban list.
This article describes how to install and configure Fail2ban on Ubuntu 20.04.
低于 ubuntu 20.04 的系统，可以参考 ubuntu 16.04防止SSH暴力登录攻击 。
The Fail2ban package is included in the default Ubuntu 20.04 repositories. To install it, enter the following command as root or user with sudo privileges :
|
1 2 3 |
$ sudo apt update $ sudo apt install fail2ban |
Once the installation is completed, the Fail2ban service will start automatically. You can verify it by checking the status of the service:
|
1 |
$ sudo systemctl status fail2ban |
The output will look like this:
|
1 2 3 4 5 6 7 8 9 |
● fail2ban.service - Fail2Ban Service Loaded: loaded (/lib/systemd/system/fail2ban.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2020-08-19 06:16:29 UTC; 27s ago Docs: man:fail2ban(1) Main PID: 1251 (f2b/server) Tasks: 5 (limit: 1079) Memory: 13.8M CGroup: /system.slice/fail2ban.service └─1251 /usr/bin/python3 /usr/bin/fail2ban-server -xf start |
That’s it. At this point, you have Fail2Ban running on your Ubuntu server.
The default Fail2ban installation comes with two configuration files, /etc/fail2ban/jail.conf and /etc/fail2ban/jail.d/defaults-debian.conf. It is not recommended to modify these files as they may be overwritten when the package is updated.
Fail2ban reads the configuration files in the following order. Each .local file overrides the settings from the .conf file:
/etc/fail2ban/jail.conf/etc/fail2ban/jail.d/*.conf/etc/fail2ban/jail.local/etc/fail2ban/jail.d/*.localFor most users, the easiest way to configure Fail2ban is to copy the jail.conf to jail.local and modify the .local file. More advanced users can build a .localconfiguration file from scratch. The .local file doesn’t have to include all settings from the corresponding .conf file, only those you want to override.
Create a .local configuration file from the default jail.conf file:
|
1 |
$ sudo cp /etc/fail2ban/jail.{conf,local} |
To start configuring the Fail2ban server open, the jail.local file with your text editor :
|
1 |
$ sudo nano /etc/fail2ban/jail.local |
The file includes comments describing what each configuration option does. In this example, we’ll change the basic settings.
IP addresses, IP ranges, or hosts that you want to exclude from banning can be added to the ignoreip directive. Here you should add your local PC IP address and all other machines that you want to whitelist.
Uncomment the line starting with ignoreip and add your IP addresses separated by space:
/etc/fail2ban/jail.local
|
1 |
ignoreip = 127.0.0.1/8 ::1 123.123.123.123 192.168.1.0/24 |
The values of bantime, findtime, and maxretry options define the ban time and ban conditions.
bantime is the duration for which the IP is banned. When no suffix is specified, it defaults to seconds. By default, the bantime value is set to 10 minutes. Generally, most users will want to set a longer ban time. Change the value to your liking:
/etc/fail2ban/jail.local
|
1 |
bantime = 1d |
To permanently ban the IP use a negative number.
findtime is the duration between the number of failures before a ban is set. For example, if Fail2ban is set to ban an IP after five failures (maxretry, see below), those failures must occur within the findtime duration.
/etc/fail2ban/jail.local
|
1 2 |
# 这个时间段内超过规定次数会被ban掉 findtime = 10m |
maxretry is the number of failures before an IP is banned. The default value is set to five, which should be fine for most users.
/etc/fail2ban/jail.local
|
1 |
maxretry = 5 |
Fail2ban can send email alerts when an IP has been banned. To receive emails, you need to have an SMTP installed on your server and change the default action, which only bans the IP to %(action_mw)s, as shown below:
/etc/fail2ban/jail.local
|
1 |
action = %(action_mw)s |
%(action_mw)s bans the offending IP and sends an email with a whois report. If you want to include the relevant logs in the email, set the action to %(action_mwl)s.
You can also adjust the sending and receiving email addresses:
/etc/fail2ban/jail.local
|
1 2 |
destemail = admin@linuxize.com sender = root@linuxize.com |
Fail2ban uses a concept of jails. A jail describes a service and includes filters and actions. Log entries matching the search pattern are counted, and when a predefined condition is met, the corresponding actions are executed.
Fail2ban ships with a number of jail for different services. You can also create your own jail configurations.
By default, only the ssh jail is enabled. To enable a jail, you need to add enabled = true after the jail title. The following example shows how to enable the proftpd jail:
/etc/fail2ban/jail.local
|
1 2 3 4 5 |
[proftpd] port = ftp,ftp-data,ftps,ftps-data logpath = %(proftpd_log)s backend = %(proftpd_backend)s |
The settings we discussed in the previous section, can be set per jail. Here is an example:
/etc/fail2ban/jail.local
|
1 2 3 4 5 6 |
[sshd] enabled = true maxretry = 3 findtime = 1d bantime = 4w ignoreip = 127.0.0.1/8 23.34.45.56 |
The filters are located in the /etc/fail2ban/filter.d directory, stored in a file with same name as the jail. If you have custom setup and experience with regular expressions you can fine tune the filters.
Each time you edit a configuration file, you need to restart the Fail2ban service for changes to take effect:
|
1 |
$ sudo systemctl restart fail2ban |
Fail2ban ships with a command-line tool named fail2ban-client that you can use to interact with the Fail2ban service.
To view all available options, invoke the command with the -h option:
|
1 |
$ fail2ban-client -h |
This tool can be used to ban/unban IP addresses, change settings, restart the service, and more. Here are a few examples:
Check the jail status:
|
1 |
$ sudo fail2ban-client status sshd |
Unban an IP:
|
1 |
$ sudo fail2ban-client set sshd unbanip 23.34.45.56 |
Ban an IP:
|
1 |
$ sudo fail2ban-client set sshd banip 23.34.45.56 |
We’ve shown you how to install and configure Fail2ban on Ubuntu 20.04.
For more information on this topic, visit the Fail2ban documentation .
If you have questions, feel free to leave a comment below.
注意：如果服务器上启用了 UFW 防火墙，则几乎必然出现 Fail2ban 无法阻止攻击者 IP 的情况。
尽管 Fail2ban 已经提示阻止用户访问。但是由于 iptables 的顺序问题，根本不起作用，依旧在 /var/log/auth.log 中观察到不断的访问尝试。
解决方法如下：
|
1 |
$ sudo vim /etc/fail2ban/jail.local |
将
|
1 2 |
banaction = iptables-multiport banaction_allports = iptables-allports |
更改为
|
1 2 |
banaction = ufw banaction_allports = ufw |
防火墙规则要求通过 UFW 进行设置。
重新载修改后的配置信息
|
1 |
$ sudo fail2ban-client reload |
默认情况下，执行如下命令后：
|
1 2 3 |
$ sudo systemctl enable ufw $ sudo ufw enable |
UFW 服务器应该随着服务器重启自动启动，但是却经常没有启动，尤其是 ubuntu 20.04 。
参考 Fix ufw service not loading after a reboot 调整。
默认情况下，Fail2ban的配置是没办法阻止用户名尝试的，因此，我们需要新增如下配置才能解决问题。
First, define the filter for invalid users in /etc/fail2ban/filter.d/sshd-invaliduser.conf:
|
1 2 3 4 5 6 7 8 9 10 11 |
[INCLUDES] before = common.conf [Definition] _daemon = sshd failregex = ^%(__prefix_line)s[iI](?:llegal|nvalid) user .*? from <HOST>(?: port \d+)?\s*$ ignoreregex = [Init] journalmatch = _SYSTEMD_UNIT=sshd.service + _COMM=sshd |
Then enable it in /etc/fail2ban/jail.local:
|
1 2 3 4 5 6 |
[sshd-invaliduser] enabled = true maxretry = 1 port = ssh logpath = %(sshd_log)s backend = %(sshd_backend)s |
默认情况下，Fail2ban的配置是没办法阻止root登陆尝试的，因此，我们需要新增如下配置才能解决问题。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
[INCLUDES] before = common.conf [Definition] _daemon = sshd failregex = ^%(__prefix_line)spam_unix\(sshd:auth\):\s+authentication failure;\s*logname=\S*\s*uid=\d*\s*euid=\d*\s*tty=\S*\s*ruser=\S*\s*rhost=<HOST>\S*\s*user=(root|admin)\s.*$ ignoreregex = [Init] maxlines = 10 journalmatch = _SYSTEMD_UNIT=sshd.service + _COMM=sshd |
Then enable it in /etc/fail2ban/jail.local:
|
1 2 3 4 5 6 |
[sshd-ban-root] enabled = true maxretry = 1 port = ssh logpath = %(sshd_log)s backend = %(sshd_backend)s |
Android 从诞生之日起就高举着开源的大旗，这也是它成功的原因之一。而它的开放性也成功的吸引到了一大批爱折腾的人，从而诞生出了 root（此处特制 Android 中的 root）。
根据 Wikipedia 的释义，root 指的是使用户取得 Android 操作系统的超级用户（Super User）许可权的技术。用户通过 root，可以越过手机制造商的限制，卸载手机制造商预装在手机中某些应用，以及运行一些需要超级用户权限的应用程序。同时,root 也可能会让手机变得“不安全”（并不是说 root 使手机变得不安全，而是一些用户的使用习惯会使 root 后的手机变得危险）。
但是从棉花糖（Android 6.0）开始，Google 基本阻止了以前版本中最流行的 root 方法 —— 即，将 su守护程序 放置到 /system 分区，并在启动时取得所需的权限。道高一尺，魔高一丈，于是就出现了 systemless 的 root 方式，因为它不采取任何方式修改 /system 分区。
出于增加安全性的考虑，Google 推出了 SafetyNet 这样的检测，以确保 Android Pay 等一些 App 的安全运行，玩家不得不在 root 权限和一些有价值的 App 之间作出选择。
这个时候 Magisk 诞生了。
Magisk 是出自一位台湾学生 @topjohnwu 开发的 Android 框架，是一个通用的第三方 systemless 接口，通过这样的方式实现一些较强大的功能。
看似很简单的一个框架，甚至与大名鼎鼎的 Xposed 框架在功能性上有点重复。很多人批评 Magisk的模块太少了，想替代 Xposed 根本不可能（在那个 Xposed Framework for Android 7.0 难产的时代，很多人将 Magisk 看是做是 Xposed 的替代品）。这是不正确的，因为 Magisk 从来没有想过要代替 Xposed ，Magisk 与 Xposed 是可以互相兼容的，你甚至可以通过 Magisk 来安装 Xposed（安装 Xposed 后就不能绕过 SafetyNet 了）。
Magisk 的厉害之处在于它实现了一种绕过 SafetyNet 使用 root 的方法。
实现原理：由于它是通过启动时在 boot 中创建钩子，把 /data/magisk.img 挂载到 /magisk，构建出一个在 system 基础上能够自定义替换，增加以及删除的文件系统，所有操作都在启动的时候完成，实际上并没有对 /system 分区进行修改（即 systemless 接口，以不触动 /system 的方式修改 /system）。
截至目前版本（v14.0），Magisk 可以实现的功能包括：
支持的版本：Android 5.0+
安装 Magisk 需要解锁 Bootloader 并刷入第三方 Recovery。所以每个品牌的手机都或多或少的有点不一样，这里只介绍一个标准的流程，具体操作方法请自行 Google（只需要 Google 你使用的手机解锁 Bootloader 和刷入第三方 Recovery 的方法就可以了，其他的安我说的做）。
Magisk-uninstaller.zip 的刷机包，方法和刷 Magisk 一样。两种方法我都没试过。App Systemizer
这是一个能把用户 App 挂载为系统 App 的模块，如 Google Play 服务、绿色守护、蟒蛇音效等。
Magisk SELinux Permissive Script
使 Android 的 SELinux 默认以 Permissive 运行，关于 SELinux 模式的介绍，请点击这里。
ViPER4Android FX
大名鼎鼎的蝰蛇音效的 Magisk 模块，需要配合 VIPERFX 的管理器使用，请在 XDA 论坛搜索下载。关于ViPER4Android。
强大的 Xposed 框架的 systemless 实现，关于 Xposed 的介绍点击这里。
待续...
如果你不知道这么找 Magisk 或者 VIPERFX。我这里提供了一些资源。不能保证是最新的。
Magisk 卡刷包，版本：17.1
ViPER4Android FX 的管理程器，版本：2.5.0.5
我收集的蝰蛇音效的音效配置、脉冲反馈 和 DDC。完整版，质量良莠不齐
还是音效配置、脉冲反馈 和 DDC。但这是我精选过的版本，也是目前再用的版本
ubuntu 18.04 .5 升级到 ubuntu 20.04.2 之后，发现 Tomcat 9.0.31 长时间没办法启动，观察日志，发现如下错误信息：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
08-Feb-2021 22:09:23.792 SEVERE [main] org.apache.catalina.util.LifecycleBase.handleSubClassException Failed to start component [Connector[AJP/1.3-8009]] org.apache.catalina.LifecycleException: Protocol handler start failed at org.apache.catalina.connector.Connector.startInternal(Connector.java:1038) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.StandardService.startInternal(StandardService.java:438) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:930) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.startup.Catalina.start(Catalina.java:633) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:343) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:478) Caused by: java.lang.IllegalArgumentException: The AJP Connector is configured with secretRequired="true" but the secret attribute is either null or "". This combination is not valid. at org.apache.coyote.ajp.AbstractAjpProtocol.start(AbstractAjpProtocol.java:264) at org.apache.catalina.connector.Connector.startInternal(Connector.java:1035) ... 12 more |
这个是由于在升级系统的时候，选择保留老版本的配置文件，这样就导致，如果 Tomcat 配置了通过 AJP 方式与Apache通信的情况下，会报告上面的错误信息。
新增 secretRequired 的目的是为了解决 AJP 端口暴露在公网的情况下，存在 AJP File Read/Inclusion in Apache Tomcat (CVE-2020-1938) and Undertow (CVE-2020-1745) 漏洞，由于 Tomcat AJP 协议设计上存在缺陷，攻击者通过 Tomcat AJP Connector 可以读取或包含 Tomcat 上所有 webapp 目录下的任意文件，例如可以读取 webapp 配置文件或源代码。此外在目标应用有文件上传功能的情况下，配合文件包含的利用还可以达到远程代码执行的危害。
连接方必须在连接的时候，传入正确的 secretRequired 才能与 Tomcat 通信，相当于通信需要的密码了。
网上很多人都是直接设置
|
1 |
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" secretRequired="" /> |
来解决问题的，也就是设置 secretRequired 为空字符，但是这样会导致攻击方不需要传递密码就可以通信了，因此诱发远程攻击漏洞。
正确的做法其实是不允许远程用户直接通过 Tomcat AJP 协议通信，也就是在设置绑定的 IP 地址为本地地址 127.0.0.1。如下：
|
1 |
<Connector port="8009" protocol="AJP/1.3" address="127.0.0.1" redirectPort="8443" secretRequired=""/> |