One place for hosting & domains

      How To Set Up the Eclipse Theia Cloud IDE Platform on DigitalOcean Kubernetes


      The author selected the Free and Open Source Fund to receive a donation as part of the Write for DOnations program.

      Introduction

      With developer tools moving to the cloud, creation and adoption of cloud IDE (Integrated Development Environment) platforms is growing. Cloud IDEs are accessible from every type of modern device through web browsers, and they offer numerous advantages for real-time collaboration scenarios. Working in a cloud IDE provides a unified development and testing environment for you and your team, while minimizing platform incompatibilities. Because they are natively based on cloud technologies, they are able to make use of the cluster to achieve tasks, which can greatly exceed the power and reliability of a single development computer.

      Eclipse Theia is an extensible cloud IDE running on a remote server and accessible from a web browser. Visually, it’s designed to look and behave similarly to Microsoft Visual Studio Code, which means that it supports many programming languages, has a flexible layout, and has an integrated terminal. What separates Eclipse Theia from other cloud IDE software is its extensibility; it can be modified using custom extensions, which allow you to craft a cloud IDE suited to your needs.

      In this tutorial, you will set up the default version of the Eclipse Theia cloud IDE platform on your DigitalOcean Kubernetes cluster and expose it at your domain, secured with Let’s Encrypt certificates and requiring the visitor to authenticate. In the end, you’ll have Eclipse Theia running on your Kubernetes cluster available via HTTPS and requiring the visitor to log in.

      Prerequisites

      • A DigitalOcean Kubernetes cluster with your connection configured as the kubectl default. Instructions on how to configure kubectl are shown in the Connect to your Cluster step when you create your cluster. To create a Kubernetes cluster on DigitalOcean, see Kubernetes Quickstart.

      • The Helm package manager installed on your local machine, and Tiller installed on your cluster. To do this, complete Steps 1 and 2 of the How To Install Software on Kubernetes Clusters with the Helm Package Manager tutorial.

      • The Nginx Ingress Controller and Cert Manager installed on your cluster using Helm in order to expose Eclipse Theia using Ingress Resources. To do this, follow How to Set Up an Nginx Ingress on DigitalOcean Kubernetes Using Helm.

      • A fully registered domain name to host Eclipse Theia. This tutorial will use theia.your_domain throughout. You can purchase a domain name on Namecheap, get one for free on Freenom, or use the domain registrar of your choice.

      Step 1 — Installing and Exposing Eclipse Theia

      To begin you’ll install Eclipse Theia to your DigitalOcean Kubernetes cluster. Then, you will expose it at your desired domain using an Nginx Ingress.

      Since you created two example deployments and a resource as part of the prerequisites, you can freely delete them by running the following commands:

      • kubectl delete -f hello-kubernetes-ingress.yaml
      • kubectl delete -f hello-kubernetes-first.yaml
      • kubectl delete -f hello-kubernetes-second.yaml

      For this tutorial, you’ll store the deployment configuration on your local machine, in a file named eclipse-theia.yaml. Create it using the following command:

      Add the following lines to the file:

      eclipse-theia.yaml

      apiVersion: v1
      kind: Namespace
      metadata:
        name: theia
      ---
      apiVersion: networking.k8s.io/v1beta1
      kind: Ingress
      metadata:
        name: theia-next
        namespace: theia
        annotations:
          kubernetes.io/ingress.class: nginx
      spec:
        rules:
        - host: theia.your_domain
          http:
            paths:
            - backend:
                serviceName: theia-next
                servicePort: 80
      ---
      apiVersion: v1
      kind: Service
      metadata:
       name: theia-next
       namespace: theia
      spec:
       ports:
       - port: 80
         targetPort: 3000
       selector:
         app: theia-next
      ---
      apiVersion: apps/v1
      kind: Deployment
      metadata:
        labels:
          app: theia-next
        name: theia-next
        namespace: theia
      spec:
        selector:
          matchLabels:
            app: theia-next
        replicas: 1
        template:
          metadata:
            labels:
              app: theia-next
          spec:
            containers:
            - image: theiaide/theia:next
              imagePullPolicy: Always
              name: theia-next
              ports:
              - containerPort: 3000
      

      This configuration defines a Namespace, a Deployment, a Service, and an Ingress. The Namespace is called theia and will contain all Kubernetes objects related to Eclipse Theia, separated from the rest of the cluster. The Deployment consists of one instance of the theiaide/theia:next Docker image with the port 3000 exposed on the container. The Service looks for the Deployment and remaps the container port to the usual HTTP port, 80, allowing in-cluster access to Eclipse Theia.

      The Ingress contains a rule to serve the Service at port 80 externally at your desired domain. In its annotations, you specify that the Nginx Ingress Controller should be used for request processing. Remember to replace theia.your_domain with your desired domain that you’ve pointed to your cluster’s Load Balancer, then save and close the file.

      Save and exit the file.

      Then, create the configuration in Kubernetes by running the following command:

      • kubectl create -f eclipse-theia.yaml

      You’ll see the following output:

      Output

      namespace/theia created ingress.networking.k8s.io/theia-next created service/theia-next created deployment.apps/theia-next created

      You can watch the Eclipse Theia pod creation by running:

      • kubectl get pods -w -n theia

      The output will look like this:

      Output

      NAME READY STATUS RESTARTS AGE theia-next-847d8c8b49-jt9bc 0/1 ContainerCreating 0 22s

      After some time, the status will turn to RUNNING, which means you’ve successfully installed Eclipse Theia to your cluster.

      Navigate to your domain in your browser. You’ll see the default Eclipse Theia editor GUI.

      The default Eclipse Theia editor GUI

      You’ve deployed Eclipse Theia to your DigitalOcean Kubernetes cluster and exposed it at your desired domain with an Ingress. Next, you’ll secure access to your Eclipse Theia deployment by enabling login authentication.

      Step 2 — Enabling Login Authentication For Your Domain

      In this step, you’ll enable username and password authentication for your Eclipse Theia deployment. You’ll achieve this by first curating a list of valid login combinations using the htpasswd utility. Then, you’ll create a Kubernetes secret containing that list and configure the Ingress to authenticate visitors according to it. In the end, your domain will only be accessible when the visitor inputs a valid username and password combination. This will prevent guests and other unwanted visitors from accessing Eclipse Theia.

      The htpasswd utility comes from the Apache web server and is used for creating files that store lists of login combinations. The format of htpasswd files is one username:hashed_password combination per line, which is the format the Nginx Ingress Controller expects the list to conform to.

      Start by installing htpasswd on your system by running the following command:

      • sudo apt install apache2-utils -y

      You’ll store the list in a file called auth. Create it by running:

      This file needs to be named auth because the Nginx Ingress Controller expects the secret to contain a key called data.auth. If it’s missing, the controller will return HTTP 503 Service Unavailable status.

      Add a username and password combination to auth by running the following command:

      Remember to replace username with your desired username. You’ll be asked for an accompanying password and the combination will be added into the auth file. You can repeat this command for as many users as you wish to add.

      Note: If the system you are working on does not have htpasswd installed, you can use a Dockerized version instead.

      You’ll need to have Docker installed on your machine. For instructions on how to do so, visit the official docs.

      Run the following command to run a dockerized version:

      • docker run --rm -it httpd htpasswd -n <username>

      Remember to replace <username> with the username you want to use. You’ll be asked for a password. The hashed login combination will be written out on the console, and you’ll need to manually add it to the end of the auth file. Repeat this process for as many logins as you wish to add.

      When you are done, create a new secret in Kubernetes with the contents of the file by running the following command:

      • kubectl create secret generic theia-basic-auth --from-file=auth -n theia

      You can see the secret with:

      • kubectl get secret theia-basic-auth -o yaml -n theia

      The output will look like:

      Output

      apiVersion: v1 data: auth: c2FtbXk6JGFwcjEkVFMuSDdyRWwkaFNSNWxPbkc0OEhncmpGZVFyMzEyLgo= kind: Secret metadata: creationTimestamp: "..." name: theia-basic-auth namespace: default resourceVersion: "10900" selfLink: /api/v1/namespaces/default/secrets/theia-basic-auth uid: 050767b9-8823-4fd3-b498-5f11074f768b type: Opaque

      Next, you’ll need to edit the Ingress to make it use the secret. Open the deployment configuration for editing:

      Add the highlighted lines to your file:

      eclipse-theia.yaml

      apiVersion: v1
      kind: Namespace
      metadata:
        name: theia
      ---
      apiVersion: networking.k8s.io/v1beta1
      kind: Ingress
      metadata:
        name: theia-next
        namespace: theia
        annotations:
          kubernetes.io/ingress.class: nginx
          nginx.ingress.kubernetes.io/auth-type: basic
          nginx.ingress.kubernetes.io/auth-secret: theia-basic-auth
          nginx.ingress.kubernetes.io/auth-realm: 'Authentication Required - Eclipse Theia'
      spec:
        rules:
        - host: theia.your_domain
          http:
            paths:
            - backend:
                serviceName: theia-next
                servicePort: 80
      ...
      

      First, in the auth-type annotation, you specify that the authentication type is basic. This means that Nginx will require the user to type in a username and password. Then, in auth-secret, you specify that the secret that contains the list of valid combinations is theia-basic-auth, which you’ve just created. The remaining auth-realm annotation specifies a message that will be shown to the user as an explanation of why authentication is required. You can change the message contained in this field to your liking.

      Save and close the file.

      To propagate the changes to your cluster, run the following command:

      • kubectl apply -f eclipse-theia.yaml

      You’ll see the output:

      Output

      namespace/theia unchanged ingress.networking.k8s.io/theia-next configured service/theia-next unchanged deployment.apps/theia-next unchanged

      Navigate to your domain in your browser, where you’ll now be asked to log in.

      You’ve enabled basic login authentication on your Ingress by configuring it to use the secret containing the hashed username and password combinations. In the next step, you’ll secure access further by adding TLS certificates, so that the traffic between you and your Eclipse Theia deployment stays encrypted.

      Step 3 — Applying Let’s Encrypt HTTPS Certificates

      Next you will secure your Eclipse Theia installation by applying Let’s Encrypt certificates to your Ingress, which Cert-Manager will automatically provision. After completing this step, your Eclipse Theia installation will be accessible via HTTPS.

      Open eclipse-theia.yaml for editing:

      Add the highlighted lines to your file, making sure to replace the placeholder domain with your own:

      eclipse-theia.yaml

      apiVersion: v1
      kind: Namespace
      metadata:
        name: theia
      ---
      apiVersion: networking.k8s.io/v1beta1
      kind: Ingress
      metadata:
        name: theia-next
        namespace: theia
        annotations:
          kubernetes.io/ingress.class: nginx
          nginx.ingress.kubernetes.io/auth-type: basic
          nginx.ingress.kubernetes.io/auth-secret: theia-basic-auth
          nginx.ingress.kubernetes.io/auth-realm: 'Authentication Required - Eclipse Theia'
          cert-manager.io/cluster-issuer: letsencrypt-prod
      spec:
        tls:
        - hosts:
          - theia.your_domain
          secretName: theia-prod
        rules:
        - host: theia.your_domain
          http:
            paths:
            - backend:
                serviceName: theia-next
                servicePort: 80
      ...
      

      First, you specify the letsencrypt-prod ClusterIssuer you created as part of the prerequisites as the issuer that will be used to provision certificates for this Ingress. Then, in the tls section, you specify the exact domain that should be secured, as well as a name for a secret that will be holding those certificates.

      Save and exit the file.

      Apply the changes to your cluster by running the following command:

      • kubectl apply -f eclipse-theia.yaml

      The output will look like:

      Output

      namespace/theia unchanged ingress.networking.k8s.io/theia-next configured service/theia-next unchanged deployment.apps/theia-next unchanged

      It will take a few minutes for the certificates to be provisioned and fully applied. You can track the progress by observing the output of the following command:

      • kubectl describe certificate theia-prod -n theia

      When it finishes, the end of the output will look similar to this:

      Output

      ... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal GeneratedKey 42m cert-manager Generated a new private key Normal Requested 42m cert-manager Created new CertificateRequest resource "theia-prod-3785736528" Normal Issued 42m cert-manager Certificate issued successfully

      Refresh your domain in your browser. You’ll see a green padlock shown on the leftmost side of the address bar signifying that the connection is secure.

      You’ve configured the Ingress to use Let’s Encrypt certificates thus making your Eclipse Theia deployment more secure. Now you can review the default Eclipse Theia user interface.

      Step 4 — Using the Eclipse Theia Interface

      In this section, you’ll explore some of the features of the Eclipse Theia interface.

      On the left-hand side of the IDE, there is a vertical row of four buttons opening the most commonly used features in a side panel.

      Eclipse Theia GUI - Sidepanel

      This bar is customizable so you can move these views to a different order or remove them from the bar. By default, the first view opens the Explorer panel that provides tree-like navigation of the project’s structure. You can manage your folders and files here—creating, deleting, moving, and renaming them as necessary.

      After creating a new file through the File menu, you’ll see an empty file open in a new tab. Once saved, you can view the file’s name in Explorer side panel. To create folders right click on the Explorer sidebar and click on New Folder. You can expand a folder by clicking on its name as well as dragging and dropping files and folders to upper parts of the hierarchy to move them to a new location.

      Eclipse Theia GUI - New Folder

      The next two options provide access to search and replace functionality. Following it, the next one provides a view of source control systems that you may be using, such as Git.

      The final view is the debugger option, which provides all the common actions for debugging in the panel. You can save debugging configurations in the launch.json file.

      Debugger View with launch.json open

      The central part of the GUI is your editor, which you can separate by tabs for your code editing. You can change your editing view to a grid system or to side-by-side files. Like all modern IDEs, Eclipse Theia supports syntax highlighting for your code.

      Editor Grid View

      You can gain access to a terminal by typing CTRL+SHIFT+`, or by clicking on Terminal in the upper menu, and selecting New Terminal. The terminal will open in a lower panel and its working directory will be set to the project’s workspace, which contains the files and folders shown in the Explorer side panel.

      Terminal open

      You’ve explored a high-level overview of the Eclipse Theia interface and reviewed some of the most commonly used features.

      Conclusion

      You now have Eclipse Theia, a versatile cloud IDE, installed on your DigitalOcean Kubernetes cluster. You’ve secured it with a free Let’s Encrypt TLS certificate and set up the instance to require a login from the visitor. You can work on your source code and documents with it individually or collaborate with your team. You can also try building your own version of Eclipse Theia if you need additional functionality. For further information on how to do that, visit the Theia docs.



      Source link

      How To Set Up a Firewall with UFW on Debian 9


      Introdução

      O UFW, ou Uncomplicated Firewall (Firewall Descomplicado), é uma interface para iptables desenvolvida para simplificar o processo de configuração de um firewall. Apesar da iptables ser uma ferramenta sólida e flexível, pode ser difícil para os iniciantes aprender como usá-la para configurar corretamente um firewall. Se você deseja começar a proteger sua rede, mas não tem certeza sobre qual ferramenta usar, o UFW pode ser a escolha certa para você.

      Este tutorial mostrará como configurar um firewall com o UFW no Debian 9.

      Pré-requisitos

      Para seguir este tutorial, você precisará de um servidor Debian 9 com um usuário sudo não raiz, que pode ser configurado seguindo os Passos 1–3 na Configuração Inicial do Servidor com o Debian 9.

      Passo 1 – Instalando o UFW

      O Debian não instala o UFW por padrão. Se você seguiu todo o tutorial de Configuração Inicial do Servidor, você já terá instalado e habilitado o UFW. Caso contrário, instale-o agora usando o apt:

      Vamos configurar o UFW e habilitá-lo nos passos a seguir.

      Este tutorial foi escrito tendo o IPv4 em mente, mas funcionará também com o IPv6, contanto que você o habilite. Se seu servidor Debian tiver o IPv6 habilitado, certifique-se de que o UFW esteja configurado para dar suporte ao IPv6, para que ele gerencie as regras de firewall do IPv6, além das regras do IPv4. Para fazer isso, abra a configuração do UFW com o nano ou seu editor favorito.

      • sudo nano /etc/default/ufw

      Então, certifique-se de que o valor IPV6 seja yes. Deve se parecer com isto:

      /etc/default/ufw excerpt

      IPV6=yes
      

      Salve e feche o arquivo. Agora, quando o UFW estiver habilitado, ele será configurado para escrever regras de firewall para ambos IPv4 e IPv6. No entanto, antes de habilitar o UFW, nós vamos querer garantir que seu firewall esteja configurado para permitir que você se conecte via SSH. Vamos começar configurando as políticas padrão.

      Passo 3 — Configurando as políticas padrão

      Se você estiver apenas começando com seu firewall, as primeiras regras a definir são suas políticas padrão. Essas regras controlam a maneira de lidar com tráfego que não seja claramente compatível com quaisquer outras regras. Por padrão, o UFW é configurado para negar todas as conexões de entrada e permitir todas as conexões de saída. Isso significa que qualquer um que tentasse acessar o seu servidor não conseguiria conectar-se, ao passo que os aplicativos dentro do servidor conseguiriam alcançar o mundo exterior.

      Vamos retornar as regras do seu UFW para as configurações padrão, para que possamos ter certeza de que você conseguirá acompanhar este tutorial. Para definir os padrões usados pelo UFW, utilize estes comandos:

      • sudo ufw default deny incoming
      • sudo ufw default allow outgoing

      Esses comandos configuram os padrões para negar as conexões de entrada e permitir as conexões de saída. Esses padrões do firewall poderiam suprir as necessidades de um computador pessoal Porém, os servidores normalmente precisam responder às solicitações que chegam de usuários externos. Vamos verificar isso a seguir.

      Passo 4 — Permitindo as conexões via protocolo SSH

      Se nós habilitássemos nosso firewall UFW agora, ele negaria todas as conexões de entrada. Isso significa que precisaremos criar regras que permitam de maneira explícita as conexões de entrada legítimas — conexões SSH ou HTTP, por exemplo — se quisermos que nosso servidor responda a esses tipos de pedidos. Se você estiver usando um servidor na nuvem, você provavelmente irá querer permitir conexões de entrada via protocolo SSH para que você consiga se conectar e gerenciar o seu servidor.

      Para configurar seu servidor para permitir as conexões de entrada via SSH, você pode utilizar este comando:

      Esse procedimento criará regras do firewall que permitirão todas as conexões na porta 22, que é a porta na qual o SSH daemon escuta por padrão. O UFW sabe o que a porta allow ssh significa porque ela está listada como um serviço no arquivo /etc/services.

      No entanto, podemos realmente escrever a regra equivalente, especificando a porta em vez do nome do serviço. Por exemplo, este comando funciona de forma semelhante ao anterior:

      Se você configurou seu SSH daemon para usar uma porta diferente, você terá que especificar a porta apropriada. Por exemplo, se seu servidor SSH estiver escutando na porta 2222, você pode usar este comando para permitir as conexões naquela porta:

      Agora que seu firewall está configurado para permitir as conexões de entrada via SSH, podemos habilitá-lo.

      Passo 5 — Habilitando o UFW

      Para habilitar o UFW, utilize este comando:

      Você receberá um aviso que diz que o comando pode interromper conexões via SSH existentes. Nós já configuramos uma regra de firewall que permite conexões via SSH, então tudo bem continuar. Responda ao prompt com y e tecle ENTER.

      O firewall agora está ativo. Execute o comando sudo ufw status verbose para ver as regras que foram definidas. O resto deste tutorial tratará de como usar o UFW em mais detalhes, como, por exemplo, permitir ou negar diferentes tipos de conexões.

      Passo 6 — Permitindo outras conexões

      Neste ponto, você deve permitir todas as outras conexões às quais seu servidor precisa responder. As conexões que você deve permitir dependem das suas necessidades específicas. Felizmente, você já sabe escrever regras que permitem conexões baseadas em um nome de serviço ou porta; já fizemos isso para o SSH na porta 22. Você também pode fazer isso para:

      • O HTTP na porta 80, que é a porta que os servidores Web não criptografados utilizam, usando sudo ufw allow http ou sudo ufw allow 80
      • O HTTPS na porta 443, que é a porta que os servidores Web criptografados utilizam, usando sudo ufw allow https ou sudo ufw allow 443

      Há várias outras maneiras de permitir outras conexões, além de especificar uma porta ou serviço conhecido.

      Faixas de portas específicas

      Você pode especificar faixas de portas com o UFW. Alguns aplicativos usam várias portas, em vez de uma única porta.

      Por exemplo, para permitir conexões via protocolo X11, que usam as portas 6000-6007, utilize esses comandos:

      • sudo ufw allow 6000:6007/tcp
      • sudo ufw allow 6000:6007/udp

      Ao especificar as faixas de porta com o UFW, você deve especificar o protocolo (tcp ou udp) para o qual as regras devem aplicar-se. Nós não mencionamos isso antes porque não especificar o protocolo automaticamente permite ambos os protocolos, o que é OK na maioria dos casos.

      Endereços IP específicos

      Ao trabalhar com o UFW, você também pode especificar endereços IP. Por exemplo, se quiser permitir conexões de um endereço IP específico, como um endereço IP de trabalho ou domicílio de 203.0.113.4, você precisa especificar from, então o endereço IP:

      • sudo ufw allow from 203.0.113.4

      Você também pode especificar uma porta específica na qual o endereço IP tem permissão para se conectar, adicionando to any port seguido do número da porta. Por exemplo, se quiser permitir que o endereço 203.0.113.4 se conecte à porta 22 (SSH), utilize este comando:

      • sudo ufw allow from 203.0.113.4 to any port 22

      Sub-redes

      Se você quiser permitir uma sub-rede de endereços IP, você pode fazer isso usando uma notação CIDR para especificar uma máscara de rede. Por exemplo, se você quiser permitir todos os endereços IP na faixa de 203.0.113.1 a 203.0.113.254, você pode usar este comando:

      • sudo ufw allow from 203.0.113.0/24

      De maneira similar, você também pode especificar a porta de destino na qual a sub-rede 203.0.113.0/24 tem permissão para se conectar. Novamente, nós vamos usar a porta 22 (SSH) como um exemplo:

      • sudo ufw allow from 203.0.113.0/24 to any port 22

      Conexões a uma Interface de Rede Específica

      Se você quiser criar uma regra de firewall que se aplique apenas a uma interface de rede específica, você pode fazer isso especificando “allow in on” seguido do nome da interface de rede.

      Você pode querer verificar suas interfaces de rede antes de continuar. Para fazer isso, utilize este comando:

      Output Excerpt

      2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state . . . 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default . . .

      O resultado destacado indica os nomes de interfaces de rede. Normalmente, elas recebem nomes como eth0 ou enp3s2.

      Então, se o seu servidor tiver uma interface de rede pública chamada eth0, você pode permitir o tráfego HTTP (porta 80) nela, usando este comando:

      • sudo ufw allow in on eth0 to any port 80

      Fazer isso permitiria que seu servidor recebesse pedidos HTTP da internet pública.

      Ou, se você quiser que seu servidor de banco de dados MySQL (porta 3306) escute conexões na interface de rede privada eth1, por exemplo, você pode usar este comando:

      • sudo ufw allow in on eth1 to any port 3306

      Isso permitiria que outros servidores na sua rede privada se conectassem ao seu banco de dados MySQL.

      Passo 7 — Negando conexões

      Se você não tiver mudado a política padrão das conexões de entrada, o UFW está configurado para negar todas as conexões de entrada. Geralmente, isso simplifica o processo de criação de uma política de firewall segura ao exigir que você crie regras que permitam explicitamente portas e endereços IP específicos.

      No entanto, algumas vezes você irá querer negar conexões específicas baseadas no endereço IP ou na sub-rede da origem, talvez porque você saiba que seu servidor está sendo atacado a partir daí. Além disso, se você quisesse alterar sua política de entrada padrão para permitir (allow) (o que não é recomendado), você precisaria criar regras para negar (deny) quaisquer serviços ou endereços IP para os quais você não quisesse permitir conexões.

      Para escrever regras de deny, você pode usar os comandos descritos acima, substituindo allow por deny.

      Por exemplo, para negar conexões HTTP, você pode usar este comando:

      Ou se você quiser negar todas as conexões do endereço 203.0.113.4 você pode usar este comando:

      • sudo ufw deny from 203.0.113.4

      Agora, vamos ver como excluir regras.

      Passo 8 — Excluindo regras

      Saber como excluir regras do firewall é tão importante quanto saber como criá-las. Há duas maneiras diferentes para especificar quais regras excluir: pelo número da regra ou pela regra em si (semelhante ao modo como as regras foram especificadas quando foram criadas). Vamos começar com o método *excluir pelo número *da regra porque é mais fácil.

      Pelo número da regra

      Se você estiver usando o número da regra para excluir regras do firewall, a primeira coisa que você vai querer fazer é obter uma lista das regras do seu firewall. O comando status do UFW tem uma opção para mostrar números ao lado de cada regra, como demonstrado aqui:

      Numbered Output:

      Status: active To Action From -- ------ ---- [ 1] 22 ALLOW IN 15.15.15.0/24 [ 2] 80 ALLOW IN Anywhere

      Se decidirmos que queremos excluir a regra 2, aquela que permite conexões na porta 80 (HTTP), podemos especificar isso em um comando delete do UFW desta forma:

      Isso mostraria um prompt de confirmação e então excluiria a regra 2, que permite conexões HTTP. Note que se você tivesse o IPv6 habilitado, você iria querer excluir a regra correspondente ao IPv6 também.

      Pela regra

      A alternativa para os números das regras é especificar a regra propriamente dita a ser excluída. Por exemplo, se quiser remover a regra allow http, você pode escrever desta forma:

      • sudo ufw delete allow http

      Você também poderia especificar a regra por allow 80, em vez de pelo nome do serviço:

      Esse método irá excluir as regras do IPv4 e do IPv6, se houver.

      Passo 9 — Verificando o status e as regras do UFW

      A qualquer momento, você pode verificar o status do UFW com este comando:

      Se o UFW estiver desabilitado - o que acontece por padrão, você verá algo como isso:

      Output

      Status: inactive

      Se o UFW estiver ativo - o que deve ser o caso se você tiver seguido o Passo 3 - o resultado dirá que ele está ativo e listará quaisquer regras que estejam definidas. Por exemplo, se o firewall estiver configurado para permitir conexões via SSH (porta 22) de qualquer lugar, o resultado poderia parecer com este:

      Output

      Status: active Logging: on (low) Default: deny (incoming), allow (outgoing), disabled (routed) New profiles: skip To Action From -- ------ ---- 22/tcp ALLOW IN Anywhere

      Use o comando status, se quiser verificar como o UFW configurou o firewall.

      Passo 10 — Desabilitando ou redefinindo o UFW (opcional)

      Se você decidir que não quer usar o UFW, você pode desabilitá-lo com este comando:

      Quaisquer regras que você tenha criado com o UFW já não estarão mais ativas. Você sempre poderá executar sudo ufw enable se precisar ativá-lo mais tarde.

      Se você já tiver regras do UFW configuradas, mas decidir que quer começar novamente, você pode usar o comando de redefinição:

      Isso irá desabilitar o UFW e excluir quaisquer regras que tiverem sido definidas anteriormente. Lembre-se de que as políticas padrão não irão voltar para suas configurações originais se, em algum momento, você as tiver alterado. Isso deve dar a você um novo começo com o UFW.

      Conclusão

      Seu firewall agora está configurado para permitir (pelo menos) conexões via SSH. Certifique-se de permitir outras conexões de entrada que seu servidor, ao mesmo tempo em que limita quaisquer conexões desnecessárias, para que seu servidor seja funcional e seguro.

      Para aprender sobre mais configurações comuns do UFW, verifique o tutorial Fundamentos do UFW: regras comuns de firewall e comandos.



      Source link

      How To Set Up a Firewall with UFW on Ubuntu 18.04


      Uma versão anterior deste tutorial foi escrita por Hazel Virdó

      Introdução

      O UFW, ou Uncomplicated Firewall (Firewall Descomplicado), é uma interface para iptables desenvolvida para simplificar o processo de configuração de um firewall. Apesar da iptables ser uma ferramenta sólida e flexível, pode ser difícil para os iniciantes aprender como usá-la para configurar corretamente um firewall. Se você deseja começar a proteger sua rede, mas não tem certeza sobre qual ferramenta usar, o UFW pode ser a escolha certa para você.

      Este tutorial mostrará como configurar um firewall com o UFW no Ubuntu 18.04.

      Pré-requisitos

      Para seguir este tutorial, será necessário:

      O UFW vem instalado por padrão no Ubuntu. Se ele tiver sido desinstalado por algum motivo, você pode instalá-lo com sudo apt install ufw.

      Este tutorial foi escrito tendo o IPv4 em mente, mas funcionará também com o IPv6, contanto que você o habilite. Se seu servidor Ubuntu tiver o IPv6 habilitado, certifique-se de que o UFW esteja configurado para dar suporte ao IPv6, para que ele gerencie as regras de firewall do IPv6, além das regras do IPv4. Para fazer isso, abra a configuração UFW com o nano ou seu editor favorito.

      • sudo nano /etc/default/ufw

      Então, certifique-se de que o valor IPV6 seja yes. Deve se parecer com isto:

      /etc/default/ufw excerpt

      IPV6=yes
      

      Salve e feche o arquivo. Agora, quando o UFW estiver habilitado, ele será configurado para escrever regras de firewall para ambos IPv4 e IPv6. No entanto, antes de habilitar o UFW, nós vamos querer garantir que seu firewall esteja configurado para permitir que você se conecte via SSH. Vamos começar configurando as políticas padrão.

      Passo 2 — Configurando as políticas padrão

      Se você estiver apenas começando com seu firewall, as primeiras regras a definir são suas políticas padrão. Essas regras controlam a maneira de lidar com tráfego que não seja claramente compatível com quaisquer outras regras. Por padrão, o UFW é configurado para negar todas as conexões de entrada e permitir todas as conexões de saída. Isso significa que qualquer um que tentasse acessar o seu servidor não conseguiria conectar-se, ao passo que os aplicativos dentro do servidor conseguiriam alcançar o mundo exterior.

      Vamos retornar as regras do seu UFW para as configurações padrão, para que possamos ter certeza de que você conseguirá acompanhar este tutorial. Para definir os padrões usados pelo UFW, utilize estes comandos:

      • sudo ufw default deny incoming
      • sudo ufw default allow outgoing

      Esses comandos configuram os padrões para negar as conexões de entrada e permitir as conexões de saída. Esses padrões do firewall poderiam suprir as necessidades de um computador pessoal Porém, os servidores normalmente precisam responder às solicitações que chegam de usuários externos. Vamos verificar isso a seguir.

      Passo 3 — Permitindo as conexões via protocolo SSH

      Se nós habilitássemos nosso firewall UFW agora, ele negaria todas as conexões de entrada. Isso significa que precisaremos criar regras que permitam de maneira explícita as conexões de entrada legítimas — conexões SSH ou HTTP, por exemplo — se quisermos que nosso servidor responda a esses tipos de pedidos. Se você estiver usando um servidor na nuvem, você provavelmente irá querer permitir conexões de entrada via protocolo SSH para que você consiga se conectar e gerenciar o seu servidor.

      Para configurar seu servidor para permitir as conexões de entrada via SSH, você pode utilizar este comando:

      Esse procedimento criará regras do firewall que permitirão todas as conexões na porta 22, que é a porta na qual o SSH daemon escuta por padrão. O UFW sabe o que a porta allow ssh significa porque ela está listada como um serviço no arquivo /etc/services.

      No entanto, podemos realmente escrever a regra equivalente, especificando a porta em vez do nome do serviço. Por exemplo, este comando funciona de forma semelhante ao anterior:

      Se você configurou seu SSH daemon para usar uma porta diferente, você terá que especificar a porta apropriada. Por exemplo, se seu servidor SSH estiver escutando na porta 2222, você pode usar este comando para permitir as conexões naquela porta:

      Agora que seu firewall está configurado para permitir as conexões de entrada via SSH, podemos habilitá-lo.

      Passo 4 — Habilitando o UFW

      Para habilitar o UFW, utilize este comando:

      Você receberá um aviso que diz que o comando pode interromper conexões via SSH existentes. Nós já configuramos uma regra de firewall que permite conexões via SSH, então tudo bem continuar. Responda ao prompt com y e tecle ENTER.

      O firewall agora está ativo. Execute o comando sudo ufw status verbose para ver as regras que foram definidas. O resto deste tutorial tratará de como usar o UFW em mais detalhes, como, por exemplo, permitir ou negar diferentes tipos de conexões.

      Passo 5 — Permitindo outras conexões

      Neste ponto, você deve permitir todas as outras conexões às quais seu servidor precisa responder. As conexões que você deve permitir dependem das suas necessidades específicas. Felizmente, você já sabe escrever regras que permitem conexões baseadas em um nome de serviço ou porta; já fizemos isso para o SSH na porta 22. Você também pode fazer isso para:

      • O HTTP na porta 80, que é a porta que os servidores Web não criptografados utilizam, usando sudo ufw allow http ou sudo ufw allow 80
      • O HTTPS na porta 443, que é a porta que os servidores Web criptografados utilizam, usando sudo ufw allow https ou sudo ufw allow 443

      Há várias outras maneiras de permitir outras conexões, além de especificar uma porta ou serviço conhecido.

      Faixas de portas específicas

      Você pode especificar faixas de portas com o UFW. Alguns aplicativos usam várias portas, em vez de uma única porta.

      Por exemplo, para permitir conexões via protocolo X11, que usam as portas 6000-6007, utilize esses comandos:

      • sudo ufw allow 6000:6007/tcp
      • sudo ufw allow 6000:6007/udp

      Ao especificar as faixas de porta com o UFW, você deve especificar o protocolo (tcp ou udp) para o qual as regras devem aplicar-se. Nós não mencionamos isso antes porque não especificar o protocolo automaticamente permite ambos os protocolos, o que é OK na maioria dos casos.

      Endereços IP específicos

      Ao trabalhar com o UFW, você também pode especificar endereços IP. Por exemplo, se quiser permitir conexões de um endereço IP específico, como um endereço IP de trabalho ou domicílio de 203.0.113.4, você precisa especificar from, então o endereço IP:

      • sudo ufw allow from 203.0.113.4

      Você também pode especificar uma porta específica na qual o endereço IP tem permissão para se conectar, adicionando to any port seguido do número da porta. Por exemplo, se quiser permitir que o endereço 203.0.113.4 se conecte à porta 22 (SSH), utilize este comando:

      • sudo ufw allow from 203.0.113.4 to any port 22

      Sub-redes

      Se você quiser permitir uma sub-rede de endereços IP, você pode fazer isso usando uma notação CIDR para especificar uma máscara de rede. Por exemplo, se você quiser permitir todos os endereços IP na faixa de 203.0.113.1 a 203.0.113.254, você pode usar este comando:

      • sudo ufw allow from 203.0.113.0/24

      De maneira similar, você também pode especificar a porta de destino na qual a sub-rede 203.0.113.0/24 tem permissão para se conectar. Novamente, nós vamos usar a porta 22 (SSH) como um exemplo:

      • sudo ufw allow from 203.0.113.0/24 to any port 22

      Conexões a uma Interface de Rede Específica

      Se você quiser criar uma regra de firewall que se aplique apenas a uma interface de rede específica, você pode fazer isso especificando “allow in on” seguido do nome da interface de rede.

      Você pode querer verificar suas interfaces de rede antes de continuar. Para fazer isso, utilize este comando:

      Output Excerpt

      2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state . . . 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default . . .

      O resultado destacado indica os nomes de interfaces de rede. Normalmente, elas recebem nomes como eth0 ou enp3s2.

      Então, se o seu servidor tiver uma interface de rede pública chamada eth0, você pode permitir o tráfego HTTP (porta 80) nela, usando este comando:

      • sudo ufw allow in on eth0 to any port 80

      Fazer isso permitiria que seu servidor recebesse pedidos HTTP da internet pública.

      Ou, se você quiser que seu servidor de banco de dados MySQL (porta 3306) escute conexões na interface de rede privada eth1, por exemplo, você pode usar este comando:

      • sudo ufw allow in on eth1 to any port 3306

      Isso permitiria que outros servidores na sua rede privada se conectassem ao seu banco de dados MySQL.

      Passo 6 — Negando conexões

      Se você não tiver mudado a política padrão para conexões de entrada, o UFW está configurado para negar todas as conexões de entrada. Geralmente, isso simplifica o processo de criação de uma política de firewall segura ao exigir que você crie regras que permitam explicitamente portas e endereços IP específicos.

      No entanto, algumas vezes você irá querer negar conexões específicas baseadas no endereço IP ou na sub-rede da origem, talvez porque você saiba que seu servidor está sendo atacado a partir daí. Além disso, se você quisesse alterar sua política de entrada padrão para permitir (allow) (o que não é recomendado), você precisaria criar regras para negar (deny) quaisquer serviços ou endereços IP para os quais você não quisesse permitir conexões.

      Para escrever regras de deny, você pode usar os comandos descritos acima, substituindo allow por deny.

      Por exemplo, para negar conexões HTTP, você pode usar este comando:

      Ou se você quiser negar todas as conexões do endereço 203.0.113.4 você pode usar este comando:

      • sudo ufw deny from 203.0.113.4

      Agora, vamos ver como excluir regras.

      Passo 7 — Excluindo regras

      Saber como excluir regras do firewall é tão importante quanto saber como criá-las. Há duas maneiras diferentes para especificar quais regras excluir: pelo número da regra ou pela regra em si (semelhante ao modo como as regras foram especificadas quando foram criadas). Vamos começar com o método *excluir pelo número *da regra porque é mais fácil.

      Pelo número da regra

      Se você estiver usando o número da regra para excluir regras do firewall, a primeira coisa que você vai querer fazer é obter uma lista das regras do seu firewall. O comando status do UFW tem uma opção para mostrar números ao lado de cada regra, como demonstrado aqui:

      Numbered Output:

      Status: active To Action From -- ------ ---- [ 1] 22 ALLOW IN 15.15.15.0/24 [ 2] 80 ALLOW IN Anywhere

      Se decidirmos que queremos excluir a regra 2, aquela que permite conexões na porta 80 (HTTP), podemos especificar isso em um comando delete do UFW desta forma:

      Isso mostraria um prompt de confirmação e então excluiria a regra 2, que permite conexões HTTP. Note que se você tivesse o IPv6 habilitado, você iria querer excluir a regra correspondente ao IPv6 também.

      Pela regra

      A alternativa para os números das regras é especificar a regra propriamente dita a ser excluída. Por exemplo, se quiser remover a regra allow http, você pode escrever desta forma:

      • sudo ufw delete allow http

      Você também poderia especificar a regra por allow 80, em vez de pelo nome do serviço:

      Esse método irá excluir as regras do IPv4 e do IPv6, se houver.

      Passo 8 — Verificando o status e as regras do UFW

      A qualquer momento, você pode verificar o status do UFW com este comando:

      Se o UFW estiver desabilitado - o que acontece por padrão, você verá algo como isso:

      Output

      Status: inactive

      Se o UFW estiver ativo - o que deve ser o caso se você tiver seguido o Passo 3 - o resultado dirá que ele está ativo e listará quaisquer regras que estejam definidas. Por exemplo, se o firewall estiver configurado para permitir conexões via SSH (porta 22) de qualquer lugar, o resultado poderia parecer com este:

      Output

      Status: active Logging: on (low) Default: deny (incoming), allow (outgoing), disabled (routed) New profiles: skip To Action From -- ------ ---- 22/tcp ALLOW IN Anywhere

      Use o comando status, se quiser verificar como o UFW configurou o firewall.

      Passo 9 — Desabilitando ou redefinindo o UFW (opcional)

      Se você decidir que não quer usar o UFW, você pode desativá-lo com este comando:

      Quaisquer regras que você tenha criado com o UFW já não estarão mais ativas. Você sempre poderá executar sudo ufw enable se precisar ativá-lo mais tarde.

      Se você já tiver regras do UFW configuradas, mas decidir que quer começar novamente, você pode usar o comando de redefinição:

      Isso irá desabilitar o UFW e excluir quaisquer regras que tiverem sido definidas anteriormente. Lembre-se de que as políticas padrão não irão voltar para suas configurações originais se, em algum momento, você as tiver alterado. Isso deve dar a você um novo começo com o UFW.

      Conclusão

      Seu firewall agora está configurado para permitir (pelo menos) conexões via SSH. Certifique-se de permitir outras conexões de entrada que seu servidor, ao mesmo tempo em que limita quaisquer conexões desnecessárias, para que seu servidor seja funcional e seguro.

      Para aprender sobre mais configurações comuns do UFW, verifique o tutorial Fundamentos do UFW: regras comuns de firewall e comandos.



      Source link