分类：Sec

1.创建一个与旧系统同样系统的虚拟机，选择最小化配置省钱。

2.停止新虚机，把磁盘解除挂载。

3.将磁盘挂载到老虚机上

4.建立挂载点，挂载磁盘：

4.删除/new/中除了”/dev/*”,”/proc/*”,”/sys/*”,”/tmp/*”,”/run/*”,”/mnt/*”,”/media/*”,”/lost+found”,”/new”,”/var/lock/*”,”/boot/*”, “/etc/fstab” 之外的所有文件、目录。

5.拷贝所有内容到新磁盘：

6.将新磁盘挂回新虚机，更新重新安装内核。

1.拉镜像

2.建立目录，auth放账户认证信息，home用来映射到容器内存放仓库内镜像文件

3.建立认证文件

4.启动仓库

5.本地docker服务配置文件里添加

 

https://www.maketecheasier.com/see-pc-startup-and-shutdown-history-in-windows/

https://serverfault.com/questions/702828/windows-server-restart-shutdown-history

继续阅读通过windows日志系统查找服务器重启、关闭原因

https://www.bantrain.com/how-to-install-haproxy-2-0-in-amazon-linux-2-centos-rhel/

First, Install dependencies needed to build HAProxy

Download Lua source code and then Install Lua

Download OpenSSL source code and then Install OpenSSL

Download HAProxy source code and then Install HAProxy

Add Service for HAProxy

Then paste in the following

Then finish HAProxy Installation Process by running

Optional remove build dependencies for haproxy

如果haproxy -V报错：openssl: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory

 

https://segmentfault.com/a/1190000005797776

前言

自己做了一个iOS App，需要访问自己的网站获取数据，但是系统默认只能直接访问https的网站。不想让应用改用http的服务。因此，研究如何启用https，本文即是介绍如何在CentOS上配合Nginx使用CertBot。

环境

• CentOS（CentOS Linux release 7.2.1511）
• Nginx（nginx version: nginx/1.6.3）
• ExpressJS应用

安装CertBot

命令行，键入：

配置Nginx

这里我不想使用CertBot的standalone模式，这个模式虽然可以配置好服务器，但是以后Renew的时候，需要让服务停止一下，再启动。因此抛弃这个模式，我们使用Webroot配置模式。

因为，CertBot在验证服务器域名的时候，会生成一个随机文件，然后CertBot的服务器会通过HTTP访问你的这个文件，因此要确保你的Nginx配置好，以便可以访问到这个文件。

修改你的服务器配置，在server模块添加：

可以看到，上面的root，我们让他指向了/usr/share/nginx/html，因为我的应用是通过NodeJS的ExpressJS写的，如果修改源代码的话，比较麻烦。因此我就让检验的链接指向了nginx默认的文件夹下。

接着重新加载Nginx配置：

然后在命令行输入：

上面记得替换your.domain.com为你自己的域名。

如果提示：

证书生成成功！

启用443端口

同样，修改Nginx的虚拟主机配置文件，新建一个443端口的server配置：

上面记得替换your.domain.com为你自己的域名。

接着重新加载Nginx配置：

现在通过浏览器访问你的网站：https://your.domain.com试试，如果看到浏览器的绿色标志，恭喜你设置成功！

不过由于这个证书的时效只有90天，我们需要设置自动更新的功能，帮我们自动更新证书的时效。

自动更新证书

先在命令行模拟证书更新：

模拟更新成功的效果如下：

既然模拟成功，我们就使用crontab -e的命令来启用自动任务，命令行：

添加配置：

上面的执行时间为：每周一半夜2点30分执行renew任务。

你可以在命令行执行/usr/bin/certbot renew >> /var/log/le-renew.log看看是否执行正常，如果一切OK，那么我们的配置到此结束！

https://www.cyberciti.biz/faq/linux-add-a-swap-file-howto/

Procedure To Add a Swap File Under Linux

You need to use the dd command to create swap file. The mkswap command is used to set up a Linux swap area on a device or in a file.

Step #1: Login as the Root User

Open a terminal window (select Applications > Accessories > Terminal) or login to remote server using the ssh client. Switch to the root user by typing su - (or sudo -s) and entering the root password, when prompted:
$ su -
OR
$ sudo -s

Step #2: Create Storage File

Type the following command to create 512MB swap file (1024 * 512MB = 524288 block size):
# dd if=/dev/zero of=/swapfile1 bs=1024 count=524288
Sample outputs:

Where,

1. if=/dev/zero : Read from /dev/zero file. /dev/zero is a special file in that provides as many null characters to build storage file called /swapfile1.
2. of=/swapfile1 : Read from /dev/zero write storage file to /swapfile1.
3. bs=1024 : Read and write 1024 BYTES bytes at a time.
4. count=524288 : Copy only 523288 BLOCKS input blocks.

Step #3: Secure swap file

Setup correct file permission for security reasons, enter:
# chown root:root /swapfile1
# chmod 0600 /swapfile1
A world-readable swap file is a huge local vulnerability. The above commands make sure only root user can read and write to the file.

Step #4: Set up a Linux swap area

Type the following command to set up a Linux swap area in a file:
# mkswap /swapfile1
Sample outputs:

Step #5: Enabling the swap file

Finally, activate /swapfile1 swap space immediately, enter:
# swapon /swapfile1

Step #6: Update /etc/fstab file

To activate /swapfile1 after Linux system reboot, add entry to /etc/fstab file. Open this file using a text editor such as vi:
# vi /etc/fstab
Append the following line:
/swapfile1 none swap sw 0 0
Save and close the file. Next time Linux comes up after reboot, it enables the new swap file for you automatically.

How do I verify swap is activated or not?

Simply use the free command:
$ free -m

How can I display swap usage summary on Linux?

Type the following swapon command:
# swapon -s
Sample outputs:

Another option is to view /proc/meminfo file:
$ less /proc/meminfo
$ grep -i --color swap /proc/meminfo
Sample outputs:

You can also use top command, atop command, and/or htop command to display information about swap usage:
# top
# atop
# htop
Sample outputs from a database server running on a CentOS Linux server:

How can I disable devices and files for paging and swapping on Linux?

You need to use the swapoff command:
# swapoff /swapfile1
# swapon -s

How do I set swappiness on a Linux server?

The syntax is:
# sysctl vm.swappiness=VALUE
# sysctl vm.swappiness=20
OR
# echo VALUE > /proc/sys/vm/swappiness
# echo 30 > /proc/sys/vm/swappiness

The value in /proc/sys/vm/swappiness file controls how aggressively the kernel will swap memory pages. Higher values increase agressiveness, lower values descrease aggressiveness. The default value is 60. To make changes permanent add the following line to /etc/sysctl.conf:

 

https://coffieldweb.com/weblog/2019/09/04/install-webmin-aws-amazon-linux-2/

Today we’re going to install one of our favorite Linux management tools. Webmin has been around for a very long time and is great if you’re not a command-line guru. Or perhaps you just prefer a nice GUI to look at. Webmin has a great documentation wiki here.

So let’s get started.

First, we’re going to install the repository so Yum can find it. We’re going to create a .repo file and fill it using vim.

Now lets add the Webmin settings in the file.

Save the file. Now Let’s go get the GPG key so Yum can validate the authenticity of the package.

OK now that we can the reference to the repo installed and the GPG key imported, we’ll simply use Yum to install Webmin. It’ll take care of all the dependencies.

Once that’s done, Webmin will be running and serving on port 10000. You’ll want to adjust your security group in EC2 to make sure port 10000 is open. Also by default, Webmin serves secure pages using https. Most servers don’t have a domain-specific SSL cert installed at this point, so it’ll default to a self-signed certificate. Chrome and other browsers will complain about this. We’ll go over installing SSL certificates another day. For now, just accept the warning and continue to https://you_ip_address:10000/.

The last thing you’ll need to do is set the Webmin root password. By default, it tries to use the system root password which you don’t have access to. But no worries. We can force a password for the Webmin root user only. We can set up other users in Webmin btw. Let’s change the password for root now

We’re all set and can now use Webmin in EC2 on Amazon Linux 2.

https://download.configserver.com/csf/install.txt

https://www.liquidweb.com/kb/basic-dosddos-mitigation-with-the-csf-firewall/

Denial of Service (DoS) and Distributed Denial of Service (DDoS) attacks are common threats that every publicly accessible web server faces. The purpose of such attacks, in simplest terms, is to flood a server with connections, overloading it and preventing from accepting legitimate traffic.

Attacks increasingly have become automated instead of directly targeted and botnets (networks of infected computers that can be remotely controlled) continue to grow at a rapid pace, making DoS and DDoS attacks much more common.

Fortunately, CSF can be used to help mitigate small attacks.

Before proceeding, it is important to understand the following points:

1. There is no way to prevent a DoS/DDoS attack against any server connected to the Internet; once in progress, the only thing that can be done is to try to mitigate its effects.
2. There is no way to make a server respond normally when it is under attack; the most that can be done is to try to keep it online during the attack by reducing the impact of the incoming traffic.
3. In some cases, the best way to deal with a large-volume attack is to null-route the server’s IP address. Effectively, that means temporarily taking it offline until the incoming traffic subsides.
4. Any measures employed within CSF will be effective only against small attacks, and measures should be implemented in CSF only while the server is under attack. The firewall settings always should be restored afterward to minimize disruption of legitimate traffic, as the measures outlined below will slow incoming packets.
5. CSF is not the only way to mitigate small-scale attacks. Services such as those offered by CloudFlare’s network also may help because they are external, buffering traffic to the server. And for maximum protection against large attacks (millions of incoming packets per second), a specialized DoS mitigation service may be necessary. You can read more about such protection at https://www.liquidweb.com/services/network/ddos.html.

Pre-Flight Check

• This series assumes you have the ConfigServer Firewall (CSF) installed on your cPanel server, and you have access to WebHost Manager (WHM).
• If your managed cPanel server currently uses APF but you’d prefer CSF, contact Heroic Support® and request a switch. There is no charge, it typically takes only a few minutes, and the only service that needs to be restarted as a result is the firewall itself. Our support technicians also can port your existing APF rules to CSF. If requesting an upgrade, please be sure to indicate whether your server uses the Guardian backup service so that its rules also can be configured.

If you have not already done so, be sure to first back up the current firewall configuration (Part One: How to Back up and Restore the Firewall Configuration) before making any changes. After the attack has subsided, you will want to restore the current firewall configuration using the instructions in that article.

Step #1: Open the Firewall Configuration

1. In WebHost Manager, locate and select ConfigServer Security & Firewall under the Plugins section in the left menu. You also can begin typing “fire” into the search field at the top left to narrow down the options.
2. Click on the Firewall Configuration button to open the configuration file.

Step #2: Rate Limit Incoming Traffic

The first thing that can be done to mitigate the effects of an incoming attack is to limit the number of connections per IP address.

When properly configured, CSF will track the number of connections from IP address hitting the server and block IP addresses at the firewall level should they exceed a defined limit.

It’s important not to set the limit too low, as protocols such as FTP, IMAP, and even HTTP all legitimately make multiple connections. Also, remember that most companies as well as homes and public hotspots may have many different computers on their internal network which all share a single public IP address.

1. To set the limit on connections per IP address, scroll down to the Connection Tracking section of the Firewall Configuration page and set CT_LIMIT to the desired value.
   
   For the purposes of this tutorial, we’ll be using 150 connections per IP address as an upper limit. You may find that you need to lower or raise that number but, generally, you should never attempt to set it below about 100.
2. Assuming the server is under attack, you also will want to disable email alerts by setting CT_EMAIL_ALERT to “0”. Otherwise, the server will send an email every time it blocks an IP address, which will only add to load on the server.
   
3. You also may wish to restrict rate limiting to specific ports, which can be done using the CT_PORTS setting. Multiple ports can be added in comma-separated format (with no space in between). In this example, we’re applying rate limiting only to HTTP ports:
   

With these settings, any IP address that makes more than 150 connections to the web site on the standard and/or secure ports will be blocked in the firewall. By default, that will be a temporary block for 30 minutes. The CT_BLOCK_TIME setting can extend the block period, and by toggling the CT_PERMANENT setting you can arrange for the IP addresses to be blocked permanently.

Step #3: SYNflood Protection

A SYNflood attack is a DoS attack exploiting the TCP (Transmission Control Protocol) connection process itself.

In basic terms, a TCP connection is established using a three-way handshake:

• The client (incoming connection) sends a synchronization packet (SYN) to the server.
• The server responds with a synchronization acknowledgement (SYN/ACK) to the client.
• The client then responds with an acknowledgement (ACK) back to the server.

A SYNflood attack manipulates that three-way handshake by initiating multiple synchronization requests and then refusing to respond with any final acknowledgements. That causes the server, which is keeping a spot open waiting on the client’s final reply to complete their incoming connection, to eventually run out of available connections for the targeted service and appear to be offline.

On a Linux server, you can quickly check for SYN packets by running this command over SSH:
netstat -nap | grep SYN -c
It’s important to note that the presence of SYN packets does not necessarily mean that a server actually is under SYNflood attack. For instance, if load on the server already is high or there is a great deal of incoming traffic, an elevated level is to be expected. Only the presence of a large number (in the hundreds) is likely to be indicative of a possible SYNflood attack.

If you know that the server is under attack, you can configure CSF to help mitigate this type of attack. Otherwise, skip to Step Three and restart the firewall to apply the rate limits you enabled in Step One.

1. To enable SYNflood protection, locate the Port Flood Settings section of the Firewall Configuration page.
   
2. You can enable SYNflood protection by setting SYNFLOOD to “1” and setting the maximum rate and burst:
   • SYNFLOOD_RATE is the number of SYN packets to accept per IP, per second. For the purposes of this tutorial, we’ll be using a value of “75/s” on the assumption that a DoS attack is in progress.
   • SYNFLOOD_BURST is the number of times the IP can hit the rate limit before being blocked in the firewall. A setting of 25 works for our purposes.

You likely will need to raise or lower these settings based on your circumstances. However, a setting above about 100/s for the rate (or 150 for the burst) could be too generous to be effective; Likewise, lowering the rate below about 50/s (or the burst below about 50) could prevent legitimate access to services.

Step #3: Save Your Changes and Restart the Firewall

1. Scroll to the bottom of the Firewall Configuration page and click on the Change button.
2. On the next screen, click the Restart csf+lfd button to restart the firewall with the new settings.

Next Steps

1. Once the attack has subsided, you will need to restore the firewall’s previous configuration to avoid disruption of legitimate incoming traffic. If these “under attack” rules are left in place, the added packet scrutiny at the firewall level will slow traffic considerably and can lead to noticeably diminished web server performance.
2. If you followed the instructions in Part One: How to Back up and Restore the Firewall Configuration to back up the previous configuration, you can easily use the same process to restore those saved settings. You also may wish to save these DoS/DDoS protection settings before restoring the original configuration so that they can be quickly employed in the future if necessary.