InterLinked's questions

Tenho meu calendário publicado no Exchange 2010, de modo que tenho links que posso usar para obter anonimamente os detalhes do calendário como um ICS, com todos os detalhes disponíveis, que uso para acessar meu calendário a partir de meus próprios aplicativos e sistemas privados.

O que eu gostaria de fazer é também ter um par separado de links que eu possa disseminar mais amplamente, que contenham apenas informações de livre/ocupado. Embora esta seja uma das opções, não consigo gerar links adicionais, pois o calendário já está compartilhado com detalhes, ou seja, parece que só consigo compartilhar o calendário em uma configuração, não em várias:

Há algo que estou esquecendo aqui que permitiria que fosse compartilhado de várias maneiras diferentes? No outlook.com/Office365 online, é possível fazer isso, mas não encontrei nenhuma documentação que diga que não pode ser feito nas versões locais (mostrado abaixo, eu já tenho um link "todos os detalhes" publicado, e tenho a opção de compartilhá-lo novamente, com livre/ocupado):

É possível compartilhar um calendário em cada configuração possível com o Exchange 2010, como acontece com o outlook.com/Exchange Online, ou apenas uma configuração por vez é possível?

Estou ciente de ferramentas de proxy iCal como https://github.com/scy/calproxy que podem fornecer uma visualização filtrada de livre/ocupado, mas parece muito trabalhoso configurar algo assim se houver uma maneira de fazer isso nativamente.

Existe alguma maneira de instalar apenas o cliente sendmail, sem instalar o MTA do sendmail?

O que quero dizer com isso é o sendmail -tcomando frequentemente usado por processos como crono envio de e-mails. A maioria desses programas espera algum tipo de programa compatível com a API sendmail, sendmailpara o qual eles possam enviar seus e-mails de saída.

Atualmente no meu servidor de e-mail, não tenho nenhum sendmailbinário e, como tal, vejo coisas assim no cron:

(CRON) info (No MTA installed, discarding output)

Na verdade, eu tenho um MTA instalado - um que eu mesmo escrevi (não Postfix, exim, etc.) - mas não tenho nenhum sendmailprograma escrito para fazer interface com ele. Estou me perguntando se é possível instalar e usar o sendmailprograma isoladamente para receber qualquer coisa fornecida a ele e, em seguida, abrir uma conexão SMTP localhost:25 e alimentá-la no MTA usando uma transação SMTP. Dessa forma, não preciso escrever meu próprio sendmailprograma que tenha a mesma interface para fazer isso.

Isso é possível? Eu diria que algo assim já existe, então não quero reinventar a roda. A instalação padrão sendmailtambém instala o MTA do sendmail, o que eu não quero; Não quero instalar nenhum pacote MTA que possa atrapalhar ou interferir no MTA real já existente no sistema.

Na pesquisa que fiz, parece haver muito pouca separação entre os dois. Todos os tutoriais parecem assumir que você está usando um dos MTAs "padrão". Se a resposta for "não", existe documentação sobre a sendmailAPI binária completa que precisa ser implementada para compatibilidade do programa?

Estou migrando um servidor rodando Debian 10 para um servidor rodando Debian 12 (e um kernel 6.x), e a última coisa que parece não estar funcionando é o TLS 1.0, que estou tentando descobrir.

Estou ciente de que alterei SECLEVELe MinProtocolconforme descrito aqui: https://stackoverflow.com/a/61568390/6110631 , mas isso não funcionou, por algum motivo.

No sistema de trabalho, tenho:

[system_default_sect]
MinProtocol = TLSv1.0
CipherString = ALL:@SECLEVEL=1

Tentei adicionar isso da mesma maneira no novo sistema, mas o TLS 1.0 ainda parece não funcionar. No servidor Apache (que depende do aplicativo), posso ver:

AH02039: Certificate Verification: Error (68): CA signature digest algorithm too weak

Eu esperava isso, pois imaginei que o TLS 1.0 estaria desabilitado por padrão, então brinquei mais com a configuração. Nenhuma alteração que fiz pareceu funcionar, e ao fazer capturas de pacotes da perspectiva do cliente por meio de um espelho de porta, pude ver que toda a negociação TLS estava falhando completamente (logo após o Client Hello, Alert (Level: Fatal, Description: Protocol Version).

Sondando com openssl s_client, parece que algo está muito quebrado com o TLS 1.0.

No servidor Debian 10 existente, recebo:

# openssl version
OpenSSL 1.1.1n  15 Mar 2022

# openssl s_client -connect OLDHOST -tls1
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = OLDHOST
verify return:1
---
Certificate chain
 0 s:CN = OLDHOST
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----

No entanto, no novo servidor Debian 12, recebo:

# openssl version
OpenSSL 3.0.9 30 May 2023 (Library: OpenSSL 3.0.9 30 May 2023)

# openssl s_client -connect NEWHOST -tls1
CONNECTED(00000003)
140101680407744:error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error:../ssl/record/rec_layer_s3.c:1544:SSL alert number 80
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 136 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1695085443
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no

O TLS 1.2 ainda funciona corretamente, mas entendo isso para TLS 1.0 e TLS 1.1.

Eu tentei usar DEFAULT:@SECLEVEL=1e ALL:@SECLEVEL=1outras combinações de sec nível 1, sec nível 0, ALL, DEFAULT, LEGACY, etc. Nenhum deles parece funcionar. Tenho reiniciado regularmente o Apache e todo o servidor entre as alterações.

Também tentei adicionar isso à configuração do Apache, então tenho o seguinte:

Protocols h2 http/1.1
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite ALL:@SECLEVEL=0
SSLHonorCipherOrder on
SSLCompression off
SSLSessionTickets off

Outras perguntas/respostas relacionadas, que infelizmente não produziram mais informações:

• SSLVerifyClient NÃO funciona com o novo openssl e/ou novo apache (debian 10)

• https://stackoverflow.com/questions/40365295/openssl-1-0-2-and-error-ssl-ctx-newlibrary-has-no-ciphers

• https://stackoverflow.com/questions/61927683/how-to-enable-the-old-tls-1-0-and-tls-1-1-on-apache-on-ubuntu-20-04

• https://bugzilla.redhat.com/show_bug.cgi?id=2069239

Alguns lugares parecem sugerir que hoje em dia você precisa diminuir SECLEVELde 1 para 0 para que isso funcione, por exemplo, para certificados SHA1, o que eu fiz, mas ainda sem charuto.

O suporte a TLS 1.0 e 1.1 não foi removido no OpenSSL 3 (eu verifiquei), portanto deve ser suportado, com a configuração adequada.

Todas as soluções documentadas não parecem estar funcionando para mim, e não pareço estar mais perto depois de perder o dia inteiro depurando isso. Existe alguma outra solução que alguém encontrou para fazer as cifras mais antigas funcionarem? Estou especificando ALLcifras em ambos os níveis 0 e 1, e ele não parece estar me obedecendo, então isso parece um tanto bizarro.

Acabei de encontrar uma condição bizarra em um sistema Debian em que estava trabalhando.

Do nada, um programa reclamou que seu rungroup não foi encontrado. Depois de pesquisar um pouco, parece que meu sistema não acha mais que nenhum usuário ou grupo existe em todo o sistema, incluindo arquivos root.

No entanto, todos eles ainda estão lá em /etc/passwd, /etc/group, etc.

Por exemplo:

root@debian:/etc# getent passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
_apt:x:100:65534::/nonexistent:/usr/sbin/nologin
systemd-timesync:x:101:102:systemd Time Synchronization,,,:/run/systemd:/usr/sbin/nologin
systemd-network:x:102:103:systemd Network Management,,,:/run/systemd:/usr/sbin/nologin
systemd-resolve:x:103:104:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin
messagebus:x:104:105::/nonexistent:/usr/sbin/nologin
unscd:x:105:109::/var/lib/unscd:/usr/sbin/nologin
ntp:x:106:112::/nonexistent:/usr/sbin/nologin
sshd:x:107:65534::/run/sshd:/usr/sbin/nologin
systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin
festival:x:108:29::/nonexistent:/usr/sbin/nologin
mysql:x:110:116:MySQL Server,,,:/nonexistent:/bin/false
Debian-exim:x:111:117::/var/spool/exim4:/usr/sbin/nologin
postfix:x:112:118::/var/spool/postfix:/usr/sbin/nologin
opendkim:x:113:120::/var/run/opendkim:/usr/sbin/nologin
telnetd:x:109:115::/nonexistent:/usr/sbin/nologin
com:x:1001:1001:,,,:/home/com:/bin/bash
asterisk:x:1004:1004:Asterisk,,,:/home/asterisk:/bin/bash
postgres:x:115:123:PostgreSQL administrator,,,:/var/lib/postgresql:/bin/bash
memcache:x:116:124:Memcached,,,:/nonexistent:/bin/false
do-agent:x:998:998::/home/do-agent:/bin/false

root@debian:/etc# su - root
su: user root does not exist
root@debian:/etc# su - asterisk
su: user asterisk does not exist
root@debian:/etc# su - com
su: user com does not exist

root@debian:/etc# ls -la /etc/passwd
-rw-r--r-- 1 0 0 2227 Jul 29 06:28 /etc/passwd
root@debian:/etc# ls -la /etc/group
-rw-r--r-- 1 0 0 1013 Jul 29 06:28 /etc/group

Outra coisa estranha como você pode ver é que lsao invés de mostrar o nome de usuário e grupo do arquivo, apenas mostra o uid e gid do arquivo.

Eu posso cat os arquivos e a saída para todos os usuários e grupos aparece bem.

Então, é claro que agora todos os tipos de coisas não estão funcionando: não consigo fazer novas conexões SSH com o servidor, embora algumas existentes ainda estejam abertas (o mesmo para telnet, etc.)

Estou com um pouco de medo de reiniciar o servidor e ver se isso corrige, pois se não, isso dificultará o procedimento, pois terei que usar o login do console (e dado que não acho que root é um usuário válido, estou um pouco cauteloso até mesmo com isso.)

Alguém já viu esse tipo de coisa antes e sabe porque está acontecendo?

Estamos tendo um problema bizarro com um de nossos domínios que está acontecendo há mais de 15 horas neste momento. O domínio não pode ser resolvido em muitas partes do país. Eu tentei pingar em alguns servidores Linux diferentes e obtive:

example.com: Temporary failure in name resolution

O problema não é geograficamente limitado. Pessoas de todo o país já me disseram que também não podem pingar o domínio. No entanto, algumas pessoas podem pingar o domínio e acessá-lo normalmente.

Finalmente, alguém me indicou este site: https://dnschecker.org/ip-blacklist-checker.php

Quando tento resolver o domínio, "Na lista negra?" é Não para todos eles, exceto para este:dnsbl.spfbl.net

Quando clico no erro, ele diz isso:

Nenhum rDNS foi encontrado.

Este IP foi sinalizado porque não possui FCrDNS válido.

Registre um rDNS válido para este IP, que aponta para o mesmo IP.

O rDNS deve ser registrado em seu próprio domínio para que você possa excluí-lo.

Não consigo pensar no que causou isso ou como corrigi-lo. Os registros A do domínio não apontam para um IP estático até onde eu saiba, pois ele passa pelos balanceadores de carga da Cloudflare. Achei que poderia ter sido um problema com o Cloudflare, que usamos para nossos servidores de nomes. No entanto, o portal deles não indicou nada ontem ou nada relevante esta manhã.

A única correção que encontramos é alterar manualmente o servidor DNS preferencial. Por exemplo, o Google e o OpenDNS não resolvem o domínio. No dnsblacklist.org, 7 dos 12 resolvedores de DNS não conseguem resolvê-lo. A Cloudflare e outros 4 resolvedores podem resolvê-lo com sucesso. Se alterarmos o servidor DNS preferencial para 1.1.1.1manualmente nos servidores, agora eles podem pingar o domínio.

O problema é que todos os nossos usuários públicos, obviamente, não vão fazer isso. Alguma opinião sobre o que exatamente está acontecendo? Não alterei nada nos registros de domínio recentemente, e isso não afeta nenhum dos meus outros domínios que também usam Cloudflare como servidor de nomes. O problema afeta todos os subdomínios neste domínio, bem como o domínio primário, independentemente de o tráfego nesse endereço ser proxy por meio da Cloudflare.

ATUALIZAR:

Outro domínio:

Domínio problemático:

Estou familiarizado com a dependência do Active Directory no DNS e as práticas recomendadas em relação ao DNS na nomenclatura do Active Directory (por exemplo, use um subdomínio do domínio corporativo dedicado ao AD). Eu tenho apenas uma pergunta bastante conceitual sobre isso, no entanto:

1. Quão necessário é que um registro DNS (em qualquer lugar realmente) seja apontado para o controlador de domínio? Por exemplo, digamos que minha rede seja proprietária example.come eu esteja pensando em alocar ad.example.compara o domínio. Como o controlador de domínio é o servidor DNS autoritativo da rede, se você chamá-lo ad.example.com, mesmo sem adicionar um registro DNS CNAME para ele, todas as solicitações no domínio ad.example.comserão atendidas corretamente pelo controlador de domínio - e isso realmente não importa se as solicitações externas não forem. Estou esquecendo de algo? Que diferença faz a adição de um registro DNS, já que o DC não deve ser acessível de fora, de qualquer maneira? Você pode fugir sem fazê-lo (funcionalmente)? Esta resposta parece sugerir isso , mas o OP também diz que usa registros DNS públicos.

2. Eu sei que todos criticam isso, mas a maior parte da minha experiência com domínios AD tem visto organizações usarem seu domínio DNS raiz como o nome de domínio AD (por exemplo, apenas example.com). Supondo que eu também quisesse seguir esse caminho (e não serei dissuadido de fazê-lo), quais são os passos a seguir/coisas a considerar ao fazer isso? Eu continuo ouvindo sobre "conflitos", mas não está claro em que sentido esses conflitos existem. Seriam apenas as solicitações para o site example.comque irão para o próprio controlador de domínio, que precisa redirecionar as solicitações com base na porta? Qual é a maneira "adequada" de lidar com esses conflitos quando você reutiliza o domínio raiz para o AD?

Minha pergunta é semelhante a esta pergunta , mas para o Apache. Eu mesmo trato todos os erros HTTP usando uma página personalizada de tratamento de erros.

Percebi hoje que, quando recebo um erro 414, recebo a página de erro padrão do Apache 414:

Request-URI Too Long
The requested URL's length exceeds the capacity limit for this server.
Apache/2.4.25 (Debian) Server at host Port 80

Eu tenho tentado ler sobre como corrigir isso, mas não cheguei muito longe. No entanto, parece que o que está acontecendo é que o Apache nem está deixando a solicitação 414 chegar ao meu site, então meu .htaccessarquivo não está sendo lido.

Como posso forçar o Apache a passar solicitações de erro 414 para o meu site? Eu preciso ser capaz de lidar com o erro sozinho.

Eu não encontrei esse problema estranho com nenhum outro tipo de erro, além de um 414. 404, 403, 401, etc. todos funcionam bem - apenas não este - então não é que meu tratamento de erros não esteja funcionando em geral . Eu também tenho uma partida de 414 no meu.htaccess

Eu tenho um servidor hospedado executando o Asterisk PBX com as seguintes especificações: Debian 9 x86 Linux de 64 bits, 2 GB de RAM, largura de banda de 2 TB e armazenamento SSD de 20 GB.

Há quase um dia, o servidor está aparentemente "offline". Não consigo SSH ou me conectar a ele usando o FileZilla (SFTP). No entanto, estou recebendo respostas normais de ping:

Pinging domain.com [IP.AD.DR.ESS] with 32 bytes of data:
Reply from IP.AD.DR.ESS: bytes=32 time=28ms TTL=51
Reply from IP.AD.DR.ESS: bytes=32 time=30ms TTL=51
Reply from IP.AD.DR.ESS: bytes=32 time=26ms TTL=51
Reply from IP.AD.DR.ESS: bytes=32 time=27ms TTL=51

Ping statistics for IP.AD.DR.ESS:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 26ms, Maximum = 30ms, Average = 27ms

C:\Users\username>ping domain.com

Pinging domain.com [IP.AD.DR.ESS] with 32 bytes of data:
Reply from IP.AD.DR.ESS: bytes=32 time=27ms TTL=51
Reply from IP.AD.DR.ESS: bytes=32 time=30ms TTL=51
Reply from IP.AD.DR.ESS: bytes=32 time=30ms TTL=51
Reply from IP.AD.DR.ESS: bytes=32 time=43ms TTL=51

Ping statistics for IP.AD.DR.ESS:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 27ms, Maximum = 43ms, Average = 32ms

Houve um breve período em que, por alguns minutos, recebi "Resposta expirada", mas em poucos minutos estava acessível novamente e tem sido assim desde então.

O irônico aqui é que os tempos médios de ida e volta aqui são um pouco melhores do que normalmente são quando o servidor está operacional!

Além de alguns minutos ontem, nenhum dos meus pings foi expirado.

Entrei em contato com o administrador do meu servidor, que já foi DDoSed antes e ele disse que era um DDoS e a única coisa a fazer seria esperar. No entanto, isso não se soma a mim. Quando pesquisei como poderia dizer se era, de fato, um ataque DDoS, uma coisa que continuei vendo foi:

Existem várias pistas que indicam que um ataque DDoS em andamento está acontecendo — Loggly :

- O TTL (time to live) em uma solicitação de ping expira

Eu pedi ao meu administrador do servidor para entrar em contato com o host do servidor e ele recusou, dizendo que era um ataque DDoS e a única coisa a fazer era esperar que acabasse, que o host do servidor não poderia fazer nada, e tudo seria apenas um perda de tempo.

Pessoalmente, eu estava cético quanto a isso, especialmente com o que encontrei apenas pingando o servidor.

Quando tento SSHing, simplesmente não recebo nada, então, eventualmente, o software causou o tempo limite da conexão e, no FileZilla, recebo o software causou a interrupção da conexão, não pôde se conectar ao servidor.

Isso é realmente um possível ataque DDoS? Ou algo mais poderia ser responsável por isso, explicando por que o servidor está completamente inacessível e por que o ping parece indicar que o servidor está "saudável"?

Ah, também, todas as chamadas (Asterisco) para o servidor são descartadas, então não pode ser nada específico do administrador, o servidor como um todo parece estar inativo, exceto pelas respostas de ping.