Security on Kang's Blog

Complete Guide to Blocking Foreign IP Access to Servers

Wed, 01 Jan 2025 00:00:00 +0000

Why Block Foreign IP Addresses

Servers on public networks face severe security threats:

Numerous scanners on the internet continuously probe servers 24/7, attempting to gain unauthorized access and control
Server log analysis reveals that most attacks originate from foreign servers in countries like the Netherlands, United States, Singapore, and Japan
Whether using cloud servers or IDC-hosted servers, exposing service ports increases vulnerability whenever public services are offered

Solution Overview

For services primarily targeting domestic users, blocking foreign IP access can significantly enhance security.

Technical Foundation

Iptables: Linux firewall tool used to filter and block requests
Ipset module: Iptables extension that efficiently handles large IP address ranges
IPdeny: Provides regularly updated global IP address allocation data

Implementation Approach

Collect and organize domestic IP ranges into Ipset
Configure Iptables to use Ipset for checking source IPs
Allow domestic IP access while blocking foreign IP connections

Complete Implementation Steps

This guide is based on CentOS 7.6; commands may vary across different Linux distributions

Install Required Tools

1
2

# If ipset is not already installed
yum install -y ipset

Create IP Address Set

Download Domestic IP Ranges

`1`	`wget http://www.ipdeny.com/ipblocks/data/countries/cn.zone`

Convert to Ipset Commands

1
2

for i in `cat cn.zone`; do echo "ipset add china $i" >>ipset_result.sh; done
chmod +x ipset_result.sh

Create and Populate Ipset Collection

# Create the china set
ipset create china hash:net hashsize 10000 maxelem 1000000

# Add private network IP ranges
echo "ipset add china 10.0.0.0/8" >> ipset_result.sh
echo "ipset add china 172.0.0.0/8" >> ipset_result.sh
echo "ipset add china 192.0.0.0/8" >> ipset_result.sh

# Execute script to add IP ranges
bash ipset_result.sh

Verify IP Collection

1
2

ipset list china
ipset list china | wc -l  # Should contain approximately 8000+ entries

Configure Iptables Rules

# Clear existing rules (if necessary)
iptables -F
iptables -X

# Create basic rules
cat > /etc/sysconfig/iptables << EOF
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
# Add rules for other required ports below
# Example: -A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A INPUT -m set ! --match-set china src -j DROP
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT
EOF

# Apply rules
iptables-restore < /etc/sysconfig/iptables

Ensure Configuration Persistence

To prevent configuration loss after server restart, set up persistence:

Persist Ipset Data

# Save Ipset data
ipset save china > /etc/ipset.conf

# Configure loading at startup
chmod +x /etc/rc.d/rc.local
echo "ipset restore < /etc/ipset.conf" >> /etc/rc.d/rc.local

Persist Iptables Rules

1
2

# Configure loading at startup
echo "/usr/sbin/iptables-restore < /etc/sysconfig/iptables" >> /etc/rc.d/rc.local

Automate IP Range Updates

To ensure IP ranges stay current, set up periodic updates:

# Create weekly update script
cat > /usr/local/bin/update_cn_ip.sh << EOF
#!/bin/bash
wget -O /tmp/cn.zone http://www.ipdeny.com/ipblocks/data/countries/cn.zone
ipset flush china
for ip in \$(cat /tmp/cn.zone); do ipset add china \$ip; done
# Add private network IP ranges
ipset add china 10.0.0.0/8
ipset add china 172.0.0.0/8
ipset add china 192.0.0.0/8
# Update persistence file
ipset save china > /etc/ipset.conf
EOF

chmod +x /usr/local/bin/update_cn_ip.sh

# Add weekly scheduled task
echo "0 0 * * 1 /usr/local/bin/update_cn_ip.sh" > /etc/cron.d/update_cn_ip

Verification and Troubleshooting

Testing Configuration

# Check Ipset collection
ipset list china

# Check Iptables rules
iptables -L -n

# Test domestic IP access (should be allowed)
# Test foreign IP access (should be blocked)

Common Issues and Solutions

Unable to SSH connect: Ensure SSH port rules are added before blocking rules
Local network access restricted: Verify private IP ranges are added to the china set
Configuration not persisting: Check rc.local file permissions and script content

Conclusion

By blocking foreign IP access, we can significantly reduce the risk of server attacks, particularly suitable for services primarily targeting domestic users. Note that this method may affect legitimate access from overseas users - adjust according to your specific business requirements.

Kubernetes Ingress-NGINX Service Certificate Configuration

Mon, 16 Dec 2024 00:00:00 +0000

Using Ingress | Kubernetes as the application traffic proxy for K8s, and configuring certificates

Service Deployment

Since the K8S cluster used is not provided by a cloud provider, deploying metallb is required when using LoadBalancer-type services for ingress-nginx. MetalLB is a load balancer implementation for bare-metal Kubernetes clusters, using standard routing protocols.

Deploy MetalLB

# Preview configuration changes (returns non-zero if changes detected)  
kubectl get configmap kube-proxy -n kube-system -o yaml | \  
sed -e "s/strictARP: false/strictARP: true/" | \  
kubectl diff -f - -n kube-system  

# Apply ARP configuration changes (returns non-zero only on errors)  
kubectl get configmap kube-proxy -n kube-system -o yaml | \  
sed -e "s/strictARP: false/strictARP: true/" | \  
kubectl apply -f - -n kube-system

1
2

# Install MetalLB components  
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.14.8/config/manifests/metallb-native.yaml

Create ip-pool.yaml to define the IP address pool:

apiVersion: metallb.io/v1beta1  
kind: IPAddressPool  
metadata:  
  name: default  
  namespace: metallb-system  
spec:  
  addresses:  
  - 172.16.0.90/32  # Manual IP assignment required for bare-metal clusters  
  autoAssign: true  
---  
apiVersion: metallb.io/v1beta1  
kind: L2Advertisement  
metadata:  
  name: default  
  namespace: metallb-system  
spec:  
  ipAddressPools:  
  - default

Deploy ingress-nginx

`1`	`kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.11.2/deploy/static/provider/cloud/deploy.yaml`

Configuring Certificates

Here we introduce 3 certificate configuration methods: manually generating self-signed certificates, manually obtaining trusted certificates, and using cert-manager to acquire certificates.

Manual Self-Signed Certificate

You can use OpenSSL or other tools to apply for certificates. The tls.crt certificate file and tls.key private key file, the base64 encoded content of the certificate and private key, can customize the relevant information of the certificate: country, province, city, company, department, domain name, validity period, etc.

# Generate private key
openssl genrsa -out tls.key 2048 # Generate private key file tls.key

# Generate certificate request
openssl req -new -key tls.key -out tls.csr -subj "/C=CN/ST=<state>/L=<city>/O=<company>/OU=<department>/CN=<domain>" # Generate certificate request file tls.csr

# Generate certificate
openssl x509 -req -in tls.csr -signkey tls.key -out tls.crt -days 3650 # Generate certificate file tls.crt

# View certificate information
openssl x509 -in tls.crt -text -noout

test-ingress.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: test-ingress


---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: service1
  namespace: test-ingress
spec:
  replicas: 1
  selector:
    matchLabels:
      app: service1
  template:
    metadata:
      labels:
        app: service1
    spec:
      containers:
      - name: service1
        image: nginx:alpine


---
apiVersion: v1
kind: Service
metadata:
  name: service1
  namespace: test-ingress
spec:
  selector:
    app: service1
  ports:
  - name: http
    protocol: TCP
    port: 80
    targetPort: 80


# letsencrypt certificate (manually created)
---
apiVersion: v1
kind: Secret
metadata:
  name: example-com
  namespace: test-ingress
data:
  tls.crt: <base64 encoded cert>
  tls.key: <base64 encoded key>
type: kubernetes.io/tls


---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
  namespace: test-ingress
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - test.example.com
      secretName: example-com
  rules:
    - host: test.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: service1
                port:
                  number: 80

`1`	`kubectl apply -f test-ingress.yaml`

Manual Trusted Certificate Application

To apply for a certificate, you can use Let’s Encrypt or other Certificate Authorities (CAs).
The TLS certificate file (tls.crt) and private key file (tls.key) must be Base64-encoded. The default validity period is 90 days.

test-ingress.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: test-ingress

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: service1
  namespace: test-ingress
spec:
  replicas: 1
  selector:
    matchLabels:
      app: service1
  template:
    metadata:
      labels:
        app: service1
    spec:
      containers:
      - name: service1
        image: nginx:alpine

---
apiVersion: v1
kind: Service
metadata:
  name: service1
  namespace: test-ingress
spec:
  selector:
    app: service1
  ports:
  - name: http
    protocol: TCP
    port: 80
    targetPort: 80

# letsencrypt certificate (manually created)
---
apiVersion: v1
kind: Secret
metadata:
  name: example-com
  namespace: test-ingress
data:
  tls.crt: <base64 encoded cert>
  tls.key: <base64 encoded key>
type: kubernetes.io/tls

---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
  namespace: test-ingress
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - test.example.com
      secretName: example-com
  rules:
    - host: test.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: service1
                port:
                  number: 80

`1`	`kubectl apply -f test-ingress.yaml`

Using cert-manager to Obtain Certificates

cert-manager is a Kubernetes certificate management controller that utilizes CustomResourceDefinitions (CRDs), offering features such as certificate application, issuance, renewal, and deletion. Below are three methods for obtaining certificates using cert-manager: SelfSigned Issuer-type certificates, ACME Issuer-type certificates, and CA Issuer-type certificates.

Installing cert-manager

`1`	`kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.15.3/cert-manager.yaml`

By default, cert-manager will be installed in the cert-manager namespace. Although it can be deployed in a different namespace, this requires modifications to the deployment manifests.

After installation, verify the deployment by checking the pods in the cert-manager namespace:

$ kubectl get pods --namespace cert-manager

NAME                                       READY   STATUS    RESTARTS   AGE
cert-manager-cainjector-5fd6444f95-kmbmd   1/1     Running   0          60m
cert-manager-d894bbbd4-lrwp5               1/1     Running   0          60m
cert-manager-webhook-869674f96f-ljffr      1/1     Running   0          60m

Configuring SelfSigned Issuer Type Certificates

test-ingress.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: test-ingress


---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: service1
  namespace: test-ingress
spec:
  replicas: 1
  selector:
    matchLabels:
      app: service1
  template:
    metadata:
      labels:
        app: service1
    spec:
      containers:
      - name: service1
        image: nginx:alpine


---
apiVersion: v1
kind: Service
metadata:
  name: service1
  namespace: test-ingress
spec:
  selector:
    app: service1
  ports:
  - name: http
    protocol: TCP
    port: 80
    targetPort: 80


# SelfSigned Issuer: 100 years, automatically created
---
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: selfsigned-issuer
  namespace: test-ingress
spec:
  selfSigned: {}

# SelfSigned Issuer: 100 years, automatically created
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: example-com
  namespace: test-ingress
spec:
  secretName: example-com
  duration: 876000h  # 100 years
  renewBefore: 720h  # The certificate will be renewed 30 days before expiration
  issuerRef:
    name: selfsigned-issuer
    kind: ClusterIssuer
  commonName: test.example.com
  subject:
    organizations:
      - '*** Technology Co., Ltd.'
    organizationalUnits:
      - '*** Technology Co., Ltd. Operations Department'
  isCA: true
  privateKey:
    algorithm: RSA
    encoding: PKCS1
    size: 2048


---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
  namespace: test-ingress
  annotations:
    cert-manager.io/cluster-issuer: selfsigned-issuer
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - test.example.com
      secretName: example-com
  rules:
    - host: test.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: service1
                port:
                  number: 80

`1`	`kubectl apply -f test-ingress.yaml`

ACME (Automated Certificate Management Environment) is a protocol used for automated certificate issuance and renewal. The ACME protocol is standardized by the IETF, with the most common current implementation being Let’s Encrypt. A key feature of the ACME protocol is that it allows Certificate Authorities (CAs) to verify the identity of certificate requesters without requiring human intervention. Another critical feature of the ACME protocol is its ability to enable automatic certificate renewal by CAs without manual involvement. The Issuer type represents an individual account registered with an ACME certificate authority server. When creating a new ACME Issuer, the Certificate Manager will generate a private key used for identification on the ACME server. By default, certificates issued by public ACME servers are typically trusted by client computers. This means that, for example, websites secured by ACME certificates issued for specific URLs will be automatically trusted by most web browsers. ACME certificates are generally free.

Configuring ACME Issuer with HTTP01 Certificate Type

The HTTP01 challenge is completed by exposing a computed secret key at a publicly accessible HTTP URL endpoint. This URL will use the domain name for which the certificate is being requested. Once the ACME server can retrieve this secret key from the URL via the internet, it verifies your ownership of the domain.

When creating an HTTP01 challenge, cert-manager will automatically configure your cluster ingress to route traffic accessing this URL to a small web server that presents the secret key. In simpler terms, cert-manager automatically creates an ingress route to a lightweight web server responsible for displaying the verification key, thereby proving domain ownership.

Note:

Fake certificate (1-year validity, auto-created): kubernetes ingress controller fake cert
Example file: test-ingress.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: test-ingress

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: service1
  namespace: test-ingress
spec:
  replicas: 1
  selector:
    matchLabels:
      app: service1
  template:
    metadata:
      labels:
        app: service1
    spec:
      containers:
      - name: service1
        image: nginx:alpine

---
apiVersion: v1
kind: Service
metadata:
  name: service1
  namespace: test-ingress
spec:
  selector:
    app: service1
  ports:
  - name: http
    protocol: TCP
    port: 80
    targetPort: 80

# ACME certificate, automatically created
---
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: sencrypt-prod
  namespace: test-ingress
spec:
  acme:
    email: CoderKang@hotmail.com
    privateKeySecretRef:
      name: sencrypt-prod
    server: https://acme-v02.api.letsencrypt.org/directory
    solvers:
      - http01:
          ingress:
            class: nginx

---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
  namespace: test-ingress
  annotations:
    cert-manager.io/cluster-issuer: sencrypt-prod
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - test.example.com
      secretName: example-com
  rules:
    - host: test.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: service1
                port:
                  number: 80

`1`	`kubectl apply -f test-ingress.yaml`

Configuring ACME Issuer dns01-type Certificates

The DNS01 challenge is completed by providing a cryptographic key that exists in a DNS TXT record. Once this TXT record propagates across the internet, the ACME server can retrieve the key via DNS queries and verify that the client requesting the certificate is the domain owner.
If proper permissions are granted, cert-manager will automatically add this TXT record to your specified DNS provider.

However, since Tencent Cloud DNS is used here, and cert-manager does not natively support Tencent Cloud DNS, a custom resolver (cert-manager webhook) is required.

DNS01 - cert-manager Documentation

`1`	`kubectl apply -f https://raw.githubusercontent.com/imroc/cert-manager-webhook-dnspod/master/bundle.yaml`

test-ingress.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: test-ingress


---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: service1
  namespace: test-ingress
spec:
  replicas: 1
  selector:
    matchLabels:
      app: service1
  template:
    metadata:
      labels:
        app: service1
    spec:
      containers:
      - name: service1
        image: nginx:alpine


---
apiVersion: v1
kind: Service
metadata:
  name: service1
  namespace: test-ingress
spec:
  selector:
    app: service1
  ports:
  - name: http
    protocol: TCP
    port: 80
    targetPort: 80


# letsencrypt automatically created, valid for 90 days
# Configure the SecretId and SecretKey of the Tencent Cloud DNS provider
# https://console.dnspod.cn/account/token/apikey
---
apiVersion: v1
stringData:
  secret-key: <tencent cloud secret key>  # Tencent Cloud SecretKey
kind: Secret
metadata:
  name: dnspod-secret
  namespace: cert-manager
type: Opaque

---
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: sencrypt-prod
  namespace: test-ingress
spec:
  acme:
    email: CoderKang@hotmail.com
    preferredChain: ""
    privateKeySecretRef:
      name: dnspod-letsencrypt
    server: https://acme-v02.api.letsencrypt.org/directory
    solvers:
      - dns01:
          webhook:
            config:
              secretId: <tencent cloud secret id>  # Tencent Cloud SecretId
              secretKeyRef:
                key: secret-key
                name: dnspod-secret
              ttl: 600
            groupName: acme.imroc.cc
            solverName: dnspod

---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: example-com
  namespace: test-ingress
spec:
  dnsNames:
    - test.example.com
  issuerRef:
    kind: ClusterIssuer
    name: sencrypt-prod
  secretName: example-com

---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
  namespace: test-ingress
  annotations:
    cert-manager.io/cluster-issuer: sencrypt-prod
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - test.example.com
      secretName: example-com
  rules:
    - host: test.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: service1
                port:
                  number: 80

`1`	`kubectl apply -f test-ingress.yaml`

Deploying JumpServer on Kubernetes with DingTalk Alert Integration

Tue, 19 Nov 2024 00:00:00 +0000

Ingress Configuration

Requires setting up ingress (see 13-K8s ingress-nginx Service Certificate) and enabling TCP forwarding (see 23-K8s ingress TCP Forwarding).

JumpServer Deployment

“Installation”

`1`	`helm install jms-k8s ./jumpserver-v4.6.0 -n jumpserver --create-namespace -f values.yaml`

“Upgrade”

`1`	`helm upgrade jms-k8s ./jumpserver-v4.6.0 -n jumpserver --create-namespace -f values.yaml`

“Uninstallation”

`1`	`helm -n jumpserver delete jms-k8s`

Core Component Image

Modified core component to support DingTalk alerts.

docker pull docker.1ms.run/jumpserver/core:v4.6.0-ce

cd core
docker build -t jumpserver/core:v4.6.1-ce .

“Dockerfile”

1
2
3

    FROM docker.1ms.run/jumpserver/core:v4.6.0-ce

    COPY ./notifications.py /opt/jumpserver/apps/notifications/notifications.py

“notifications.py”

import textwrap
import time
import traceback
from itertools import chain

from celery import shared_task
from django.utils.translation import gettext_lazy as _
from html2text import HTML2Text

from common.utils import lazyproperty
from common.utils.timezone import local_now
from notifications.backends import BACKEND
from settings.utils import get_login_title
from terminal.const import RiskLevelChoices
from users.models import User
from .models import SystemMsgSubscription, UserMsgSubscription

__all__ = ('SystemMessage', 'UserMessage', 'system_msgs', 'Message')

system_msgs = []
user_msgs = []


class MessageType(type):
    def __new__(cls, name, bases, attrs: dict):
        clz = type.__new__(cls, name, bases, attrs)

        if 'message_type_label' in attrs \
                and 'category' in attrs \
                and 'category_label' in attrs:
            message_type = clz.get_message_type()

            msg = {
                'message_type': message_type,
                'message_type_label': attrs['message_type_label'],
                'category': attrs['category'],
                'category_label': attrs['category_label'],
            }
            if issubclass(clz, SystemMessage):
                system_msgs.append(msg)
            elif issubclass(clz, UserMessage):
                user_msgs.append(msg)

        return clz


@shared_task(
    verbose_name=_('Publish the station message'),
    description=_(
        """This task needs to be executed for sending internal messages for system alerts, 
        work orders, and other notifications"""
    )
)
def publish_task(receive_user_ids, backends_msg_mapper):
    Message.send_msg(receive_user_ids, backends_msg_mapper)


def send_dingtalk_task(message):
    # Send to custom webhook
    import hmac, hashlib, base64, urllib.parse
    timestamp = str(round(time.time() * 1000))
    # JumpServer credentials
    access_token = '<access token>'
    secret = '<secret>'

    secret_enc = secret.encode('utf-8')
    string_to_sign = f'{timestamp}\n{secret}'
    string_to_sign_enc = string_to_sign.encode('utf-8')
    hmac_code = hmac.new(secret_enc, string_to_sign_enc, digestmod=hashlib.sha256).digest()
    sign = urllib.parse.quote_plus(base64.b64encode(hmac_code))
    form_data = {
        "msgtype": "markdown",
        "markdown": {
            "title": "JumpServer Monitoring Alert",
            "text": message
        },
        "at": {
            "atMobiles": [
                "<mobile>"
            ],
            "isAtAll": False
        }
    }
    import requests
    try:
        res = requests.post(
            url=f'https://oapi.dingtalk.com/robot/send?access_token={access_token}&timestamp={timestamp}&sign={sign}',
            json=form_data)
    except Exception as e:
        with open('/opt/error.log', 'a+') as f:
            f.write(str(e))


class Message(metaclass=MessageType):
    """
    What's encapsulated here?
        Templates for different messages with a unified sending interface
        - publish: Implementation relates to message subscription table structure
        - send_msg
    """
    message_type_label: str
    category: str
    category_label: str
    text_msg_ignore_links = True
    command = None

    @classmethod
    def get_message_type(cls):
        return cls.__name__

    def publish_async(self):
        self.publish(is_async=True)

    @classmethod
    def gen_test_msg(cls):
        raise NotImplementedError

    def publish(self, is_async=False):
        raise NotImplementedError

    def get_backend_msg_mapper(self, backends):
        backends = set(backends)
        backends.add(BACKEND.SITE_MSG)  # Site message is mandatory
        backends_msg_mapper = {}
        for backend in backends:
            backend = BACKEND(backend)
            if not backend.is_enable:
                continue
            get_msg_method = getattr(self, f'get_{backend}_msg', self.get_common_msg)
            msg = get_msg_method()
            backends_msg_mapper[backend] = msg
        return backends_msg_mapper

    @staticmethod
    def send_msg(receive_user_ids, backends_msg_mapper):
        for backend, msg in backends_msg_mapper.items():
            try:
                backend = BACKEND(backend)
                client = backend.client()
                users = User.objects.filter(id__in=receive_user_ids).all()
                client.send_msg(users, **msg)
            except NotImplementedError:
                continue
            except:
                traceback.print_exc()

    @classmethod
    def send_test_msg(cls, ding=True, wecom=False):
        msg = cls.gen_test_msg()
        if not msg:
            return

        from users.models import User
        users = User.objects.filter(username='admin')
        backends = []
        if ding:
            backends.append(BACKEND.DINGTALK)
        if wecom:
            backends.append(BACKEND.WECOM)
        msg.send_msg(users, backends)

    @staticmethod
    def get_common_msg() -> dict:
        return {'subject': '', 'message': ''}

    def get_html_msg(self) -> dict:
        return self.get_common_msg()

    @staticmethod
    def html_to_markdown(html_msg):
        h = HTML2Text()
        h.body_width = 0
        content = html_msg['message']
        html_msg['message'] = h.handle(content)
        return html_msg

    def get_markdown_msg(self) -> dict:
        return self.html_to_markdown(self.get_html_msg())

    def get_text_msg(self) -> dict:
        h = HTML2Text()
        h.body_width = 90
        msg = self.get_html_msg()
        content = msg['message']
        h.ignore_links = self.text_msg_ignore_links
        msg['message'] = h.handle(content)
        return msg

    @lazyproperty
    def common_msg(self) -> dict:
        return self.get_common_msg()

    @lazyproperty
    def text_msg(self) -> dict:
        msg = self.get_text_msg()
        return msg

    @lazyproperty
    def markdown_msg(self):
        return self.get_markdown_msg()

    @lazyproperty
    def get_jumpserver_dingtalk_msg(self) -> str:
        date_str = time.strftime("%Y-%m-%d %H:%M:%S", time.localtime())
        msg = f"""## <font color="#FF0000">[JumpServer Monitoring Alert](https://jumpserver.example.com/)</font>🔥
### <font color="#FF0000">Alert Status</font>: {RiskLevelChoices.get_label(self.command['risk_level'])}
### <font color="#FF0000">Target Host</font>: {self.command['asset']}
### <font color="#FF0000">Target User</font>: {self.command['user']}
### <font color="#FF0000">Executed Command</font>: `{self.command['input']}`
### <font color="#FF0000">Alert Details</font>: User {self.command['user']} executed a risky command `{self.command['input']}` on {self.command['asset']}, please handle promptly!
### <font color="#FF0000">Trigger Time</font>: {date_str}"""
        return msg

    @lazyproperty
    def html_msg(self) -> dict:
        msg = self.get_html_msg()
        return msg

    @lazyproperty
    def html_msg_with_sign(self):
        msg = self.get_html_msg()
        msg['message'] = textwrap.dedent("""
        {}
        <small>
        <br />
        —
        <br />
        {}
        </small>
        """).format(msg['message'], self.signature)
        return msg

    @lazyproperty
    def text_msg_with_sign(self):
        msg = self.get_text_msg()
        msg['message'] = textwrap.dedent("""
        {}
        —
        {}
        """).format(msg['message'], self.signature)
        return msg

    @lazyproperty
    def signature(self):
        return get_login_title()

    # --------------------------------------------------------------
    # Support different messaging formats
    def get_dingtalk_msg(self) -> dict:
        # DingTalk restricts identical messages within a day, add timestamp suffix
        message = self.markdown_msg['message']
        time = local_now().strftime('%Y-%m-%d %H:%M:%S')
        suffix = '\n{}: {}'.format(_('Time'), time)

        return {
            'subject': self.markdown_msg['subject'],
            'message': message + suffix
        }

    def get_wecom_msg(self) -> dict:
        return self.markdown_msg

    def get_feishu_msg(self) -> dict:
        return self.markdown_msg

    def get_lark_msg(self) -> dict:
        return self.markdown_msg

    def get_email_msg(self) -> dict:
        return self.html_msg_with_sign

    def get_site_msg_msg(self) -> dict:
        return self.html_msg

    def get_slack_msg(self) -> dict:
        return self.markdown_msg

    def get_sms_msg(self) -> dict:
        return self.text_msg_with_sign

    @classmethod
    def get_all_sub_messages(cls):
        def get_subclasses(cls):
            """Returns all subclasses of argument, cls"""
            if issubclass(cls, type):
                subclasses = cls.__subclasses__(cls)
            else:
                subclasses = cls.__subclasses__()
            for subclass in subclasses:
                subclasses.extend(get_subclasses(subclass))
            return subclasses

        messages_cls = get_subclasses(cls)
        return messages_cls

    @classmethod
    def test_all_messages(cls, ding=True, wecom=False):
        messages_cls = cls.get_all_sub_messages()

        for _cls in messages_cls:
            try:
                _cls.send_test_msg(ding=ding, wecom=wecom)
            except NotImplementedError:
                continue


class SystemMessage(Message):
    def publish(self, is_async=False):
        subscription = SystemMsgSubscription.objects.get(
            message_type=self.get_message_type()
        )

        # Only send through enabled backends
        receive_backends = subscription.receive_backends
        receive_backends = BACKEND.filter_enable_backends(receive_backends)

        users = [
            *subscription.users.all(),
            *chain(*[g.users.all() for g in subscription.groups.all()])
        ]

        receive_user_ids = [u.id for u in users]
        backends_msg_mapper = self.get_backend_msg_mapper(receive_backends)
        if is_async:
            send_dingtalk_task(self.get_jumpserver_dingtalk_msg)
            # publish_task.delay(receive_user_ids, backends_msg_mapper)
        else:
            self.send_msg(receive_user_ids, backends_msg_mapper)

    @classmethod
    def post_insert_to_db(cls, subscription: SystemMsgSubscription):
        pass

    @classmethod
    def gen_test_msg(cls):
        raise NotImplementedError


class UserMessage(Message):
    user: User

    def __init__(self, user):
        self.user = user

    def publish(self, is_async=False):
        """
        Send messages through user-configured channels
        """
        sub = UserMsgSubscription.objects.get(user=self.user)
        backends_msg_mapper = self.get_backend_msg_mapper(sub.receive_backends)
        receive_user_ids = [self.user.id]
        if is_async:
            send_dingtalk_task(self.get_jumpserver_dingtalk_msg)
            # publish_task.delay(receive_user_ids, backends_msg_mapper)
        else:
            self.send_msg(receive_user_ids, backends_msg_mapper)

    @classmethod
    def get_test_user(cls):
        from users.models import User
        return User.objects.all().first()

    @classmethod
    def gen_test_msg(cls):
        raise NotImplementedError

Translated text here

values.yaml

    replicaCount: 1
    
    image:
      repository: nginx
      pullPolicy: IfNotPresent
      tag: ""
    
    imagePullSecrets: []
    nameOverride: ""
    fullnameOverride: ""
    
    serviceAccount:
      create: true
      annotations: {}
      name: ""
    
    podAnnotations: {}
    
    podSecurityContext: {}
    
    securityContext: {}
    
    service:
      type: ClusterIP
      port: 80
    
    ingress:
      enabled: false
    
    resources: {}
    
    autoscaling:
      enabled: false
    
    nodeSelector: {}
    
    tolerations: []
    
    affinity: {}

Modify the Image Version of the Jumpserver Core Module

To modify the image version of the Jumpserver core module, follow these steps:

# Step 1: Edit the core module deployment
kubectl -n jumpserver edit deployments.apps jms-k8s-jumpserver-jms-core

# Step 2: Locate the image field in the container configuration
# Find the containers section and modify the image version to:
# - name: jms-core
#   image: jumpserver/core:v4.6.1-ce

Comprehensive Guide to Linux Firewall Tool iptables: Configuration and Usage

Tue, 03 Oct 2023 00:00:00 +0000

In Linux system security maintenance, the firewall is an important tool for protecting servers from unauthorized access. iptables, as a Linux kernel firewall tool, provides powerful and flexible network traffic control mechanisms. This article will delve into the core concepts, configuration methods, and common implementation scenarios of iptables, helping system administrators build a more secure server environment.

What is iptables?

iptables is a firewall tool in the Linux kernel, directly interacting with the netfilter module, responsible for filtering, modifying, and forwarding network data packets. As a complete firewall framework, iptables provides fine-grained network traffic control capabilities, allowing complex network access policies to be formulated based on multiple conditions (such as source IP address, destination port, protocol type, etc.).

Core Components of iptables

The structure of iptables is based on the concepts of “tables” and “chains”:

Tables：Organize rules with specific functionalities
- filter：Default table, used for packet filtering
- nat：Used for network address translation
- mangle：Used for special packet modifications
- raw：Used for configuring exempted connection tracking
- security：Used for enforcing access control network rules
Chains：Each table contains multiple chains, defining when rules are applied
- INPUT：Processes incoming packets
- OUTPUT：Processes outgoing packets
- FORWARD：Processes forwarded packets
- PREROUTING：Pre-routing processing
- POSTROUTING：Post-routing processing

Basic Operations of iptables

Viewing Current Rules

# View all rules in the filter table
sudo iptables -L -v

# View all rules in the nat table
sudo iptables -t nat -L -v

Adding Rules

# Allow SSH connections (22 port)
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# Allow established connections
sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow local loopback interface
sudo iptables -A INPUT -i lo -j ACCEPT

Deleting Rules

# Delete the first rule
sudo iptables -D INPUT 1

# Delete a specific rule
sudo iptables -D INPUT -p tcp --dport 80 -j ACCEPT

Setting Default Policies

# Set default INPUT policy to reject
sudo iptables -P INPUT DROP

# Set default OUTPUT policy to accept
sudo iptables -P OUTPUT ACCEPT

Common Implementation Scenarios and Configuration Examples

Basic Server Protection Configuration

A basic server protection configuration example that allows common services and defaults to rejecting other connections:

# Clear existing rules
sudo iptables -F
sudo iptables -X

# Set default policies
sudo iptables -P INPUT DROP
sudo iptables -P FORWARD DROP
sudo iptables -P OUTPUT ACCEPT

# Allow local loopback
sudo iptables -A INPUT -i lo -j ACCEPT

# Allow established connections
sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow SSH (22 port)
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# Allow HTTP/HTTPS (80/443 ports)
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Allow ICMP (ping)
sudo iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT

Port Forwarding Configuration

Forward external 80 port requests to internal 8080 port:

`1`	`sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080`

Limiting Connection Rate

Simple configuration to prevent DoS attacks:

`1`	`sudo iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP`

Blocking Specific IP Addresses

1
2

# Block a specific IP
sudo iptables -A INPUT -s 192.168.1.0/24 -j DROP

Rule Persistence

iptables rules are lost after system restart, so persistence configuration is needed:

Debian/Ubuntu System

# Install iptables-persistent
sudo apt-get install iptables-persistent

# Save current rules
sudo netfilter-persistent save

CentOS/RHEL System

1
2

# Save current rules
sudo iptables-save > /etc/sysconfig/iptables

Common Issues and Troubleshooting

Rule Ordering：iptables matches rules in order, stopping at the first match. Therefore, rule ordering is critical.
Locking Risk：Adding DROP rules requires caution, as incorrect configuration can lead to inability to remotely connect to the server. It is recommended to test new rules with physical access when possible.
Performance Considerations：Too many rules can affect network performance, so it is recommended to regularly clean up unnecessary rules.
Logging and Monitoring：Use the LOG target to record rejected connections for troubleshooting:

`1`	`sudo iptables -A INPUT -j LOG --log-prefix "iptables denied: " --log-level 7`

Advanced Features

Network Address Translation (NAT)

Configure simple NAT to share an Internet connection:

# Enable IP forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward

# Allow forwarding
sudo iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT

Traffic Control and QoS

Use iptables’s mangle table to mark traffic, combined with tc (Traffic Control) for QoS:

`1`	`sudo iptables -t mangle -A PREROUTING -p tcp --dport 22 -j MARK --set-mark 1`

Conclusion

iptables is a powerful firewall tool in the Linux kernel, mastering its use is crucial for server security. By properly configuring iptables rules, you can effectively control network traffic, protect servers from unauthorized access, and implement advanced features such as network address translation.

For more complex scenarios, consider using higher-level tools like ufw (Uncomplicated Firewall) or firewalld, which still use iptables but provide a more user-friendly interface.

Regardless of the tool used, understanding the core concepts and working principles of iptables is essential for building a secure Linux network environment.

Guide to Automatically Configure SSL Certificates with ACME on DNSPod

Mon, 18 Sep 2023 00:00:00 +0000

Deploy acme.sh with Docker

docker-compose.yml, replace the actual values of DNSPod API ID and Key.

services:
  acme-sh:
    image: neilpang/acme.sh:latest
    container_name: acme
    restart: always
    command: daemon
    environment:
      - TZ=Asia/Shanghai
      - DP_Id=******            # DNSPod API ID
      - DP_Key=**************** # DNSPod API Key
    volumes:
      - ./certs/:/acme.sh/

Configure acme.sh

1
2
3

docker compose up -d
docker compose exec -it acme sh
acme.sh --set-default-ca --server letsencrypt

Apply for a certificate

Generate a certificate, replace www.example.com with the actual domain name. The certificate will be mounted to the ./certs/ directory.

`1`	`acme.sh --issue --dns dns_dp -d www.example.com`

Dockerized OpenVPN Client with Proxy Integration

Tue, 14 Jun 2022 00:00:00 +0000

To resolve conflicts between OpenVPN and proxy software

wfg/docker-openvpn-client: OpenVPN client with killswitch and proxy servers; built on Alpine (github.com)

Build Files

Dockerfile

FROM alpine:3.17

RUN apk add --no-cache \
    bash \
    bind-tools \
    iptables \
    ip6tables \
    openvpn

COPY . /usr/local/bin

ENV KILL_SWITCH=on

ENTRYPOINT [ "entry.sh" ]

killswitch

#!/usr/bin/env bash

set -o errexit
set -o nounset
set -o pipefail

# Block all traffic not going through tun0 interface
iptables --insert OUTPUT \
    ! --out-interface tun0 \
    --match addrtype ! --dst-type LOCAL \
    ! --destination "$(ip -4 -oneline addr show dev eth0 | awk 'NR == 1 { print $4 }')" \
    --jump REJECT

# Create static routes for allowed subnets
default_gateway=$(ip -4 route | awk '$1 == "default" { print $3 }')
for subnet in ${1//,/ }; do
    ip route add "$subnet" via "$default_gateway"
    iptables --insert OUTPUT --destination "$subnet" --jump ACCEPT
done

# Whitelist OpenVPN server addresses
global_port=$(awk '$1 == "port" { print $2 }' "${config:?"config file not found by kill switch"}")
global_protocol=$(awk '$1 == "proto" { print $2 }' "${config:?"config file not found by kill switch"}")
remotes=$(awk '$1 == "remote" { print $2, $3, $4 }' "${config:?"config file not found by kill switch"}")
ip_regex='^(([1-9]?[0-9]|1[0-9][0-9]|2([0-4][0-9]|5[0-5]))\.){3}([1-9]?[0-9]|1[0-9][0-9]|2([0-4][0-9]|5[0-5]))$'
while IFS= read -r line; do
    # Process each remote entry
    IFS=" " read -ra remote <<< "${line%%\#*}"
    address=${remote[0]}
    port=${remote[1]:-${global_port:-1194}}
    protocol=${remote[2]:-${global_protocol:-udp}}

    # Allow IP addresses and handle domain resolution
    if [[ $address =~ $ip_regex ]]; then
        iptables --insert OUTPUT --destination "$address" --protocol "$protocol" --destination-port "$port" --jump ACCEPT
    else
        for ip in $(dig -4 +short "$address"); do
            iptables --insert OUTPUT --destination "$ip" --protocol "$protocol" --destination-port "$port" --jump ACCEPT
            echo "$ip $address" >> /etc/hosts
        done
    fi
done <<< "$remotes"

entry.sh

#!/usr/bin/env bash

set -o errexit
set -o nounset
set -o pipefail

cleanup() {
    kill TERM "$openvpn_pid"
    exit 0
}

is_enabled() {
    [[ ${1,,} =~ ^(true|t|yes|y|1|on|enable|enabled)$ ]]
}

# Either a specific file name or a pattern.
if [[ $CONFIG_FILE ]]; then
    config_file=$(find /config -name "$CONFIG_FILE" 2> /dev/null | sort | shuf -n 1)
else
    config_file=$(find /config -name '*.conf' -o -name '*.ovpn' 2> /dev/null | sort | shuf -n 1)
fi

if [[ -z $config_file ]]; then
    echo "no openvpn configuration file found" >&2
    exit 1
fi

echo "using openvpn configuration file: $config_file"

openvpn_args=(
    "--config" "$config_file"
    "--cd" "/config"
)

if is_enabled "$KILL_SWITCH"; then
    openvpn_args+=("--route-up" "/usr/local/bin/killswitch.sh $ALLOWED_SUBNETS")
fi

# Docker secret that contains the credentials for accessing the VPN.
if [[ $AUTH_SECRET ]]; then
    openvpn_args+=("--auth-user-pass" "/run/secrets/$AUTH_SECRET")
fi

openvpn "${openvpn_args[@]}" &
openvpn_pid=$!

trap cleanup TERM

wait $openvpn_pid

Build and Start

docker-compose.yaml

Public image: ghcr.io/wfg/openvpn-client
Build image:

`1`	`docker compose build`

Start:

`1`	`docker compose up -d`

services:
  openvpn-client:
    image: openvpn-client:latest  # ghcr.io/wfg/openvpn-client
    build:
      context: ./
      dockerfile: Dockerfile
    container_name: openvpn-client
    cap_add:
      - NET_ADMIN
    environment:
      # - HTTP_PROXY=on
      - SOCKS_PROXY=on
    devices:
      - /dev/net/tun:/dev/net/tun
    volumes:
      - ./local:/config
      - ./local:/data/vpn
    ports:
      # - 8080:8080  # HTTP_PROXY port
      - 1080:1080  # SOCKS_PROXY port
    restart: unless-stopped

Using with Proxy Software

Utilizing the Rule Configuration routing policy in Clash software

proxies:
	- { name: OpenVPN, server: 127.0.0.1, port: 1080, type: socks5 }

rules:
	- IP-CIDR,192.168.142.0/24,OpenVPN
	- IP-CIDR,10.10.10.0/24,OpenVPN
	- IP-CIDR,172.16.0.0/24,OpenVPN

One More Thing

In addition to OpenVPN, other campus VPN clients like EasyConnect (used for free CNKI access) can be deployed in Docker containers. Expose HTTP/SOCKS proxies and configure routing rules to achieve elegant cross-network environment access.

1
2

    - { name: 'CNKI', type: socks5, server: 10.10.10.45, port: 57080}
    - 'DOMAIN-SUFFIX,cnki.net,CNKI'