All perguntas(server)

Tenho um QNAP conectado a um roteador em uma rede remota. Na mesma rede, conectado ao mesmo roteador, há também um servidor Linux. Dentro da rede remota, tudo funciona bem. Posso acessar a interface web do QNAP NAS. Também posso acessar o servidor Linux por meio da configuração de encaminhamento de porta no roteador.

No entanto, quando tento conectar-me à VPN e através dela ao servidor Linux, seja via ping, SSH ou interface web, não consigo conectar-me de forma alguma. Tudo expira. Não é nenhum firewall no servidor Linux, verifiquei ou desabilitei tudo (firewalld, iptables, SELinux) enquanto depurava isso.

Estou tentando rotacionar uma lista da linha de comando e passá-la para um método Post para o Servicenow usando o módulo Ansible URI. Estou muito perto, mas não consegui exatamente o que queria. Agradeceria se alguém pudesse me corrigir.

papel

• adicionar_gerente
  • tarefas/main.yml
  • vars/ondemand_add.yml

1. tarefas/main.yml

    - name: Submit API request to add managers
      uri:
        url: "{{ contacturl }}"
        headers: "{{ headers }}"
        user: "{{ key }}"
        password: "{{ secret }}"
        body: "{{ item }}"
        force_basic_auth: yes
        body_format: json
        method: POST
        status_code: 201
        validate_certs: false
      with_items: "{{ od_user }}"
      register: result
      changed_when: False
      failed_when: False
      ignore_errors: True

2. vars/ondemand_add.yml

od_user:
  - cmdbRequest: "contactCreate"
    user: "{{ manager_id }}"
    servername: "{{ ansible_hostname }}"
    type: "Server Management"
    contactType: "Manager"

Meu comando de playbook é o seguinte

#ansible-playbook -i meuhost, -e '{"role": "add_manager", "manager_id ":['1234', '4567']}' -- top.yml

Criei o CA da seguinte forma:

1. Certificado autoassinado com uma chave privada, root-ca.cer
2. Outro certificado, assinado com root-ca.cer, seu nome é admin-ca.cer
3. Certificado de cliente assinado com admin-ca.cer, seu nome é client.cer

openssl verifyadmin-ca.cer contra root-ca.cer passa, mas client.cer contra admin-ca.cer falha no nível 1.

Acho que se eu adicionar root-ca.cer a certificados confiáveis ​​no meu SO, isso resolveria o problema, mas se possível, eu gostaria de evitar isso. Em vez disso, posso construir um client.cerde tal forma que inclua toda a cadeia até root-ca.cer?

Se isso for importante, o propósito de client.ceré ser usado como certificado de cliente ao conectar por SSL ao meu servidor. Um host virtual usa root-ca.cercomo CA, outro admin-ca.cer- e esse não funciona.

Preciso instalar o Oracle Database 12c na minha máquina local, mas não consigo encontrar um link de download funcional. O site oficial da Oracle parece ter removido ou restringido o acesso a versões mais antigas.

Tentei procurá-lo na página oficial de download da Oracle, mas só vejo as versões mais recentes. Existe uma fonte oficial ou verificada onde eu ainda possa obter o Oracle Database 12c?

Bom dia pessoal,

Estou tentando criar um filtro de usuário LDAP - para uso com o aplicativo Xen Orchestra - que verificará se o usuário que está tentando fazer login é um membro do GROUPA ou GROUPB. Eles não precisam ser membros de ambos.

Já tenho um filtro que funciona para membros do GROUPA:

(&(sAMAccountName={{name}})(memberOf=CN=GROUPA,OU=Groups,OU=folder,DC=mydomain,DC=local))

Agora estou tentando expandir esse filtro para incluir membros do GROUPA ou GROUPB (assim), mas não está funcionando:

(&(sAMAccountName={{name}})(|(memberOf=CN=GROUPA,OU=Groups,OU=folder,DC=mydomain,DC=local)(memberOf=CN=GROUPB,OU=Groups,OU=folder,DC=mydomain,DC=local)))

Qualquer dica seria muito apreciada, obrigado.

Tenho executado meu servidor de e-mail sem problemas por alguns anos, mas recentemente tive duas instâncias em que me registrei em um site e nunca recebi o e-mail de verificação. Um era do mcsignup.comdomínio, o outro de mandrillapp.com.

Este é um exemplo de entrada do arquivo de log de e-mail:

postfix/smtpd[1550221]: connect from mail17.mcsignup.com[198.2.179.112]
postfix/smtpd[1550221]: discarding EHLO keywords: CHUNKING
postfix/smtpd[1550221]: disconnect from mail17.mcsignup.com[198.2.179.112] ehlo=1 starttls=1 quit=1 commands=3
postfix/smtpd[1550221]: connect from mail17.mcsignup.com[198.2.179.112]
postfix/smtpd[1550221]: discarding EHLO keywords: CHUNKING
postfix/smtpd[1550221]: disconnect from mail17.mcsignup.com[198.2.179.112] ehlo=1 starttls=1 quit=1 commands=3

Li em outro post que isso pode ser devido a algumas das minhas configurações serem muito restritas, mas gostaria de entender o problema antes de fazer qualquer alteração. Tenho o spamassassin em execução, mas acho que as mensagens nem chegam a esse estágio.

Há outros arquivos de log que devo verificar?

Avise-me se preciso compartilhar alguns arquivos de configuração para facilitar as coisas.

[EDITAR] main.cf

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
home_mailbox = Maildir/
inet_interfaces = all
inet_protocols = ipv4, ipv6
local_recipient_maps = proxy:unix:passwd.byname $alias_maps
mailbox_size_limit = 0
mailbox_transport = lmtp:unix:private/dovecot-lmtp
message_size_limit = 33554432
milter_default_action = accept
milter_protocol = 2
mydestination = mail.marcocastorina.com, marcocastorina.com, localhost.localdomain, localhost
mydomain = marcocastorina.com
myhostname = mail.marcocastorina.com
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
myorigin = $mydomain
non_smtpd_milters = $smtpd_milters
readme_directory = no
recipient_delimiter = +
relayhost =
smtp_dns_support_level = dnssec
smtp_host_lookup = dns
smtp_tls_mandatory_protocols = >=TLSv1.2
smtp_tls_protocols = >=TLSv1.2
smtp_tls_security_level = dane
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_discard_ehlo_keywords = chunking
smtpd_forbid_unauth_pipelining = yes
smtpd_milters = inet:localhost:12301
smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination reject_unknown_sender_domain
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = $mydomain
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_sender_restrictions = permit_sasl_authenticated permit_mynetworks
smtpd_tls_CAfile = /etc/letsencrypt/live/mail.marcocastorina.com/fullchain.pem
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.marcocastorina.com/cert.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.marcocastorina.com/privkey.pem
smtpd_tls_mandatory_ciphers = high
smtpd_tls_mandatory_exclude_ciphers = aNULL, MD5
smtpd_tls_mandatory_protocols = >=TLSv1.2
smtpd_tls_protocols = >=TLSv1.2
smtpd_tls_security_level = encrypt
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache

mestre.cf

smtp       inet  n       -       y       -       -       smtpd -o content_filter=spamassassin
submission inet  n       -       y       -       -       smtpd -o syslog_name=postfix/submission -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_sasl_type=dovecot -o smtpd_sasl_path=private/auth -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o smtpd_recipient_restrictions=reject_non_fqdn_recipient,reject_unknown_recipient_domain,permit_sasl_authenticated,reject_unauth_destination,reject
pickup     unix  n       -       y       60      1       pickup
cleanup    unix  n       -       y       -       0       cleanup
qmgr       unix  n       -       n       300     1       qmgr
tlsmgr     unix  -       -       y       1000?   1       tlsmgr
rewrite    unix  -       -       y       -       -       trivial-rewrite
bounce     unix  -       -       y       -       0       bounce
defer      unix  -       -       y       -       0       bounce
trace      unix  -       -       y       -       0       bounce
verify     unix  -       -       y       -       1       verify
flush      unix  n       -       y       1000?   0       flush
proxymap   unix  -       -       n       -       -       proxymap
proxywrite unix  -       -       n       -       1       proxymap
smtp       unix  -       -       y       -       -       smtp
relay      unix  -       -       y       -       -       smtp
showq      unix  n       -       y       -       -       showq
error      unix  -       -       y       -       -       error
retry      unix  -       -       y       -       -       error
discard    unix  -       -       y       -       -       discard
local      unix  -       n       n       -       -       local
virtual    unix  -       n       n       -       -       virtual
lmtp       unix  -       -       y       -       -       lmtp
anvil      unix  -       -       y       -       1       anvil
scache     unix  -       -       y       -       1       scache
maildrop   unix  -       n       n       -       -       pipe flags=DRhu user=vmail argv=/usr/bin/maildrop -d ${recipient}
uucp       unix  -       n       n       -       -       pipe flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
ifmail     unix  -       n       n       -       -       pipe flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
bsmtp      unix  -       n       n       -       -       pipe flags=Fq. user=bsmtp argv=/usr/lib/bsmtp/bsmtp -t$nexthop -f$sender $recipient
scalemail-backend unix - n       n       -       2       pipe flags=R user=scalemail argv=/usr/lib/scalemail/bin/scalemail-store ${nexthop} ${user} ${extension}
mailman    unix  -       n       n       -       -       pipe flags=FR user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py ${nexthop} ${user}
spamassassin unix -      n       n       -       -       pipe user=debian-spamd argv=/usr/bin/spamc -f -e /usr/sbin/sendmail -oi -f ${sender} ${recipient}

Em um servidor dedicado para hospedagem web usando o Windows Server 2022, há 5 anos entregamos e-mails diariamente para um cliente que tem 10 mil usuários em nossa plataforma via IIS 6.0 sem problemas. Eles atualizaram recentemente suas políticas para e-mails "externos" (o produto fornecido é exclusivamente para uso interno deles, somos considerados uma empresa externa), o que significa que estamos com a taxa limitada, pois estamos enviando de um único endereço IP – resultando em levar até 8 horas para entregar 10 mil e-mails por dia (para este destinatário específico), o que não é ideal quando queremos que atualizações críticas sejam entregues aos usuários em tempo hábil (como estávamos acostumados nos últimos 5 anos, antes dessa mudança de política).

A equipe de segurança de TI sugere que aumentemos o número de endereços IP dos quais entregamos e-mails.

Em uma tentativa de aumentar nossa área de superfície IP para e-mails, atribuímos um endereço IP adicional à máquina, configuramos um servidor virtual adicional no IIS 6.0, atribuímos o endereço IP apenas para descobrir que o IP principal da máquina assina a si mesmo como a origem de todos os e-mails, e o endereço IP adicional é puramente para e-mails de entrada, não para os e-mails de saída que estamos tentando enviar.

Seguindo alguns conselhos questionáveis ​​online, instalei o hMailServer, na ilusão de que poderia usá-lo para criar vários servidores e fazer com que ele assinasse o e-mail de saída com o endereço IP dentro das configurações. Infelizmente, isso apenas adiciona um salto adicional após a fonte e não parece resolver o problema.

Estou lendo sobre o uso do DNS Round-Robin para entrega de e-mails, do HAProxy como balanceador de carga e muito mais, mas simplesmente não sei qual é a (melhor?) maneira de seguir em frente.

Por motivos de segurança, gostaríamos de manter todos os e-mails "internos" em vez de usar um provedor de retransmissão SMTP terceirizado. - Existe alguma maneira, na arquitetura Windows, de resolver esse problema e enviar vários e-mails de forma bastante uniforme entre vários endereços IP? Precisamos considerar uma solução baseada em Linux, em uma VM?

Você resolveu problemas semelhantes?

Não consigo baixar os logs do Defender For Endpoint para o SIEM-Wazuh local .

Configurei tenantId appId appSecreto defeder_for_endpoint_alerts.pyscript gerado anteriormente pelo lado da Microsoft.

O defender_for_endpoint_alerts.pyscript acima mencionado retorna o erro:

urllib.error.HTTPError: HTTP Error 403: Forbidden

O token é gerado e contém os seguintes valores:

"aud": "https://api.securitycenter.microsoft.com",

"roles": [
"Alert.Read.All"
],

O que pode estar causando isso?

Isto é um complemento à pergunta feita aqui: migração do GCP para a AWS Hosted Zone

Exportei os registros DNS do GCP e os importei para a AWS. Também mantive as entradas no GCP para garantir que quaisquer solicitações que cheguem ao GCP Clod DNS ainda sejam resolvidas. Atualizei meu registrador DNS para apontar os registros NS para a AWS. No entanto, após essa alteração, alguns de nossos usuários não conseguem acessar nossos servidores. Muitos de nossos usuários conseguem acessar os servidores, mas falha para alguns deles. Qual pode ser o motivo?

a) Devo dar algum intervalo de tempo após importar os registros na AWS antes de alterar as entradas no registrador?

b) Existe uma maneira segura de verificar se a propagação do DNS está completa? Eu verifiquei usando https://www.whatsmydns.net/ e pude ver que todos os servidores de nomes do mundo conseguiram resolver meu domínio. Mas como alguns de nossos usuários reclamaram, tive que reverter as alterações feitas no meu registrador.

Qualquer dica seria bem-vinda.

Estou no Ubuntu 22.04 e tenho o seguinte arquivo sodoers para o usuário btrbk, localizado em /etc/sudoers.d/btrbk, que funciona bem:

Cmnd_Alias BTRFS_FILESYSTEM_USAGE = /usr/bin/btrfs filesystem usage *
Cmnd_Alias BTRFS_SUBVOLUME_SHOW = /usr/bin/btrfs subvolume show *
Cmnd_Alias BTRFS_SUBVOLUME_LIST = /usr/bin/btrfs subvolume list *
Cmnd_Alias BTRFS_SUBVOLUME_SNAP = /usr/bin/btrfs subvolume snapshot *
Cmnd_Alias BTRFS_SUBVOLUME_DELETE = /usr/bin/btrfs subvolume delete *
Cmnd_Alias BTRFS_SEND = /usr/bin/btrfs send *
Cmnd_Alias BTRFS_RECEIVE = /usr/bin/btrfs receive *
Cmnd_Alias READLINK = /usr/bin/readlink *
Cmnd_Alias TEST = /usr/bin/test *

btrbk ALL= NOPASSWD: BTRFS_FILESYSTEM_USAGE, BTRFS_SUBVOLUME_SHOW, BTRFS_SUBVOLUME_LIST, BTRFS_SUBVOLUME_SNAP, BTRFS_SUBVOLUME_DELETE, BTRFS_SEND, BTRFS_RECEIVE, READLINK, TEST

Por outro lado, tenho o seguinte para o usuário dev, localizado em /etc/sudoers.d/dev, a maior parte do qual é um subconjunto do para btrbk, mas todos estão falhando:

Cmnd_Alias BTRFS_FILESYSTEM_SHOW_DEV = /usr/bin/btrfs filesystem show *
Cmnd_Alias BTRFS_FILESYSTEM_USAGE_DEV = /usr/bin/btrfs filesystem usage *
Cmnd_Alias BTRFS_SUBVOLUME_SHOW_DEV = /usr/bin/btrfs subvolume show *
Cmnd_Alias BTRFS_SUBVOLUME_LIST_DEV = /usr/bin/btrfs subvolume list *

Cmnd_Alias TRANSMISSION_RESTART_DEV = /usr/bin/systemctl restart transmission-daemon.service

dev ALL= NOPASSWD: BTRFS_FILESYSTEM_SHOW_DEV, BTRFS_FILESYSTEM_USAGE_DEV, BTRFS_SUBVOLUME_SHOW_DEV, BTRFS_SUBVOLUME_LIST_DEV
dev ALL= NOPASSWD: TRANSMISSION_RESTART_DEV

O arquivo /etc/soderstem o devido

@includedir /etc/sudoers.d

E, as permissões para sudoerse sudoers.d/*são 440 com o proprietário root. sudo -lU btrbkA saída comparada com a de devparece estar correta:

$ sudo -l -U btrbk
Matching Defaults entries for btrbk on ThinkPad:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin, use_pty

User btrbk may run the following commands on ThinkPad:
    (root) NOPASSWD: /usr/bin/btrfs filesystem usage *, /usr/bin/btrfs subvolume show *, /usr/bin/btrfs subvolume list *, /usr/bin/btrfs
        subvolume snapshot *, /usr/bin/btrfs subvolume delete *, /usr/bin/btrfs send *, /usr/bin/btrfs receive *, /usr/bin/readlink *,
        /usr/bin/test *

$ sudo -l -U dev
Matching Defaults entries for dev on ThinkPad:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin, use_pty

User dev may run the following commands on ThinkPad:
    (ALL : ALL) ALL
    (root) NOPASSWD: /usr/bin/btrfs filesystem show *, /usr/bin/btrfs filesystem usage *, /usr/bin/btrfs subvolume show *, /usr/bin/btrfs subvolume
        list *
    (root) NOPASSWD: /usr/bin/systemctl restart transmission-daemon.service

Para o usuário dev, o btrfs apresenta falhas de permissão:

$ btrfs filesystem show
ERROR: cannot open /dev/mapper/luks.root: Permission denied
ERROR: cannot open /dev/mapper/ub.luks.root: Permission denied
ERROR: cannot open /dev/mapper/luks.data: Permission denied
ERROR: cannot open /dev/mapper/sd.luks.backup: Permission denied

Da mesma forma para a transmissão, que abre uma janela para autenticação, que quando cancelada...

$ systemctl restart transmission-daemon.service 
Failed to restart transmission-daemon.service: Access denied
See system logs and 'systemctl status transmission-daemon.service' for details.

$ journalctl -x -b0 | grep transmission | tail -n1
Apr 03 15:38:53 ThinkPad polkitd(authority=local)[2612]: Operator of unix-session:3 FAILED to authenticate to gain authorization for action org.freedesktop.systemd1.manage-units for system-bus-name::1.1042 [systemctl restart transmission-daemon.service] (owned by unix-user:dev)

Alguém pode dar sugestões sobre o porquê disso acontecer?