Perguntas[iis](server)

No Windows Server que estou olhando, o IIS executa o serviço de publicação WWW, e ele é protegido por firewall para permitir apenas as portas 80 e 443 para esse serviço. Conexões de navegadores de clientes expiram, e quando olho no log de eventos de segurança no servidor, vejo eventos registrados como este:

The Windows Filtering Platform has blocked a connection.

Application Information:
    Process ID:     4
    Application Name:   System

Network Information:
    Direction:      Inbound
    Source Address:     192.168.10.21 <= This is this server where the event is logged
    Source Port:        80 <= This is the IIS WWW publishing service listening port
    Destination Address:    192.168.10.3 <= This is the client PC where the browser requests the URL on the IIS
    Destination Port:       60112
    Protocol:       6

Filter Information:
    Filter Run-Time ID: 86327
    Layer Name:     Receive/Accept
    Layer Run-Time ID:  44

Se a conexão for de entrada, como dito acima, a origem deve ser 192.168.10.3, a porta de origem deve ser qualquer porta alta aleatória que o navegador usa, o destino deve ser 192.168.10.21 e a porta de destino deve ser 80, mas é o contrário.

Não entendendo por que os campos de eventos estão de cabeça para baixo, não consigo imaginar uma maneira de permitir essa conexão.

Se essa não for realmente a solicitação original, mas a resposta do IIS à solicitação que foi permitida, então por que ela está sendo bloqueada? Não há regras de bloqueio no firewall, e a única regra que pertence a conexões HTTP(s) é a regra Allow inbound para o serviço WWW do IIS.

Eu configurei vários servidores Apache e suas respectivas regras da maneira que descrevi acima, e nunca tive problemas. Se o IIS precisa de uma abordagem diferente, então por que e como? É um requisito do fornecedor que o site rode no IIS, então não tenho liberdade a esse respeito.

EDITAR:

Se eu modificar a regra para aplicar a quaisquer programas ou serviços, então a conexão funciona. Se eu restringi-la para aplicar somente a serviços, ela ainda funciona. E somente quando eu seleciono especificamente o Worldwide Web Publishing Service como seu alvo, então ele para de permitir a conexão. A partir disso, fica claro que há algum problema entre o Firewall do Windows e o IIS, mas o que é?

A configuração é a seguinte:

Windows Server 2022 Standard com IIS 10.

Aplicativo baseado em ASP .NET 4.8, executado com Integrated modee Application Pool Identity.

Estou tentando remover os seguintes cabeçalhos:

Server, X-Powered-By, X-ASPNet-Version, X-ASPNetMVC-Version.

Não importa o que seja feito, os cabeçalhos permanecem.

Coisas tentadas:

1. Remover no nível do servidor do RESPONSE HEADERScabeçalho X-Powered-By- sem efeito, ainda aparece no conteúdo dinâmico.

2. Defina enableVersionHeader no arquivo de configuração applicationhost.config do servidor e no arquivo de configuração do aplicativo sem efeito:

<configuration>
  <system.web>
    <httpRuntime enableVersionHeader="false" />
  </system.web>
</configuration>

3. Definido no nível do servidor sem efeito:

<configuration>
  <system.webServer>
    <security>
      <requestFiltering removeServerHeader="true" />
    </security>
  </system.webServer>
</configuration>

4. Defina o valor de registro DWORD DisableServerHeader como 1 e reinicie o IIS sem efeito: HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters!DisableServerHeader

5. Tentei modificar Global.asaxpara remover o cabeçalho ASPNetMVC, mas isso quebrou o aplicativo.

Confirmei que as alterações no nível do servidor vão para o nível do site. Tentei configurar manualmente também no web.config no site. Mesmo efeito (nenhum).

O URL Scan não está mais disponível, então não é uma opção. A última opção parece ser usar o URL Rewrite, mas eu preferiria não usá-lo se possível, já que supostamente há soluções nativas para isso.

O que estou fazendo errado e há algo que não estou entendendo?

Então, estou pensando em hospedar dois sites em servidores separados. Por exemplo: site de produção no servidor IIS: 192.168.0.1 e SpecialApps IIS: 192.168.0.2, que também é o servidor de teste atual que eventualmente entrará em produção.

Atualmente, após inúmeras horas de pesquisa, foi sugerido que eu instalasse o Application Request Routing (ARR), o que eu fiz no servidor .2

meu objetivo é poder ir para https://test.mycompany.com.au para ir para .2 e https://test.mycompany.com.au/prod para ir para .1

quando o usuário acessa https://test.mycompany.com.au/prod , precisa redirecionar para https://mycompany.com.au , que é a URL de produção hospedada em .1

Está com problemas para tentar fazer o padrão de código de reescrita de URL funcionar

Isso é mesmo viável?

Existe uma maneira de fazer solicitações de despejo do IIS para seus arquivos de log o mais rápido possível?

Contexto

Estou enfrentando um atraso muito longo entre uma solicitação que faço ao IIS ser atendida e ser realmente registrada nos logs do IIS. Isso pode variar entre 20 e 60 segundos de atraso.

Alguns pontos-chave:

• Assim que a solicitação aparecer no arquivo de log, ele mostrará a hora real em que a solicitação ocorreu,
• os relatórios de solicitação são processados ​​em até 350 ms,
• nos logs de solicitação do IIS, as solicitações também não ficam "travadas"
• a solicitação é totalmente tratada no navegador rapidamente
• Pude notar que em uma produção, pouco ocupada ou nada, o Windows Server 2012 (IIS 6.2 build 9200)
• mesmo comportamento em meu host de desenvolvimento, nem um pouco ocupado , Windows 10 (IIS 10.0.19041.1)
• a produção está no armazenamento da Amazon (não sei dizer a tecnologia exata que eles usam, acredito que seja derivada do SSD)
• o armazenamento local é um disco SSD
• se eu monitorar arquivos no mesmo disco/sistema de arquivos, as atualizações dos arquivos serão refletidas instantaneamente na tela (no máximo, se houver, atraso de 1s)

Algumas coisas que eu tentei

Tentei tail -fou continuo repetindo tailo comando e também o Notepad ++ com o modo "Visualizar> Monitoramento (tail -f)" . Todos atualizando o conteúdo do arquivo ao mesmo tempo, obedecendo ao atraso um tanto aleatório, mas sempre longo.

A partir de uma cópia desta pergunta que postei (fora do tópico) em StackOverflow , Xudong Peng sugeriu que eu tentasse uma configuração flushByEntryCountW3CLog do arquivo de configuração de todo o servidor IIS ( %WinDir%\System32\Inetsrv\Config\applicationHost.configou nó de nível superior do Gerenciador IIS (computador) > Editor de configuração > sites.applicationHost/sites/siteDefaults/logFile). Isso fez com que o intervalo de registro mudasse, mas para pior. Senti que agora estava sendo descartado a cada minuto, então reverti para 0.

No tópico acima, também garanti que o específico <site>que estava testando não substituísse o sitesDefault/logFile/flushByEntryCountW3CLogin applicationHost.config. Também reciclei o pool de aplicativos (portanto, os sites também foram reciclados) e a configuração certamente entraria em vigor. Continua a mesma mudança de “comportamento” que parecia pior.

Parece que, mesmo que o buffer (dessas configurações, 64k) não seja preenchido, ele é despejado a cada minuto. Ao definir 1isso, senti que o despejo aconteceu entre 1 e 2 minutos.

Não consegui encontrar nenhuma outra configuração relacionada ao "buffer do arquivo de log" (para que o IIS preenchesse um buffer de entradas de log antes de "despejá-las" nos arquivos).

Conclusão

Isso é normal? Todo mundo que lida com logs do IIS precisa reservar um tempo para verificar as solicitações nos logs, ou talvez haja uma maneira de (pelo menos temporariamente) fazer solicitações de despejo do IIS para o arquivo de log o mais rápido possível?

Configurei um servidor FTP do Windows usando IIS. As regras de porta do firewall foram configuradas e habilitadas automaticamente durante a instalação do FTP, permitindo o tráfego FTP nas portas 21, 1024-65535 e 990.

Quando tento conectar-me a partir do servidor em que o servidor FTP está sendo executado, consigo conectar-me com êxito e sem problemas. No entanto, quando tento conectar-me ao servidor FTP a partir de um computador na rede, a conexão atinge o tempo limite. Se eu desabilitar o firewall, poderei conectar-me com sucesso.

Estou testando a conexão FTP usando o PowerShell.

Qualquer ajuda será apreciada. Obrigado.

Quando executo manualmente a consulta diretamente no SSMS, ela é executada com êxito (em 10 a 20 segundos). Quando a consulta é iniciada por meio do aplicativo Web .NET/IIS, ela trava praticamente indefinidamente e acaba bloqueando outras consultas. Acabei matando depois de esperar 20 minutos.

Quais são os fatores que fariam com que uma consulta fosse interrompida quando aplicada por meio do aplicativo .NET/IIS?

Ele contém algumas junções de tabelas grandes, mas, novamente, funciona muito bem no SSMS, então eu esperaria quase ao mesmo tempo no aplicativo da web .NET. Alguma ideia?

Obrigado!

Ao acessar o site externamente nos é servido um certificado SSL que foi removido anteriormente (meses atrás) por ter expirado e um novo certificado emitido. Não consigo encontrar nenhuma referência ao certificado antigo em lugar nenhum. Ao executar, netsh http show sslcerto certificado antigo não aparece na saída, enquanto o certificado reemitido está. Ao acessar o site no servidor, o certificado esperado é servido corretamente.

Este é um padrão do Windows Server 2019 e IIS 10. O servidor é anterior a mim, então não estive envolvido na configuração. Provavelmente foi criado a partir de uma imagem de um servidor existente enquanto era movido de uma empresa de hospedagem para outra.

Temos um aplicativo da web .aspx de formulários da web herdado instalado em "Site padrão". É possível ativar https: apenas para este aplicativo da web? dado que existem outros aplicativos da web implantados em "Site padrão"

Todas as instruções que encontrei on-line insistem na criação de uma ligação https: no IIS na porta: 443

O desafio é: quero saber se existe alguma outra maneira possível de habilitar https: apenas para aquele aplicativo da web sem impactar os outros aplicativos?

Um dos meus serviços de descanso ficou offline em um servidor mais antigo (iis 7). E embora eu precise mover isso para um servidor atualizado; Preciso colocá-lo online novamente, pelo menos por um curto prazo.

Estou conversando com o carteiro para verificar a resposta, mas estou recebendo um erro de servidor 500 em troca.

Infelizmente, não parece que FailedReqLogFiles seja atualizado para serviços de descanso; pelo menos nada está aparecendo lá.

No arquivo de log iis do site, tenho o seguinte:

16/05/2024 13:32:41 10.1.1.101 GET /api/GetInfo - 443 checkuser 10.1.1.202 PostManRuntime/7.37.3 500 0 0 15312

Eu entendo a maior parte da linha, exceto os últimos 3 números.

500 é o erro, mas quanto é 0 0 15312?

Estou executando o IIS 10 no Windows Server 2019, com instalação do WordPress (entre outras coisas), com URL Rewrite 2.1 instalado. O IIS está configurado corretamente para o aplicativo Wordpress, que está funcionando bem por si só.

Estou tentando definir regras de reescrita de URL do diretório raiz do servidor que enviará determinadas solicitações ao aplicativo WordPress.

Se eu navegar para https://this.is.my.server.com/wp/this-is-a-test/, a página carrega bem.

Eu defino um mapa de reescrita que inclui uma entrada para enviar /this-is-a-testpara /wp/this-is-a-test/e crio uma regra de reescrita que usa esse mapa para redirecionar solicitações. Funciona bem - o URL original retorna um status HTTP 301 e a solicitação é encaminhada para o URL esperado. Aqui está a regra:

<rule name="Rewrite rule1 for RewriteFriendlyUrlsToBlog" enabled="true" stopProcessing="true">
    <match url=".*" />
        <conditions>
            <add input="{RewriteFriendlyUrls:{REQUEST_URI}}" pattern="(.+)" />
        </conditions>
    <action type="Redirect" url="{C:1}" appendQueryString="true" logRewrittenUrl="true" />
</rule>

No entanto, preciso de uma regra de reescrita, não de um redirecionamento. Se eu editar esta regra para ser reescrita, recebo um erro 404. A regra ajustada é exatamente igual à anterior, exceto por ser uma reescrita em vez de um redirecionamento:

<rule name="Rewrite rule1 for RewriteFriendlyUrlsToBlog" enabled="true" stopProcessing="false">
    <match url=".*" />
    <conditions>
        <add input="{RewriteFriendlyUrls:{REQUEST_URI}}" pattern="(.+)" />
    </conditions>
    <action type="Rewrite" url="{C:1}" appendQueryString="true" logRewrittenUrl="true" />
</rule>

As informações detalhadas sobre erros incluem:

Requested URL: https://this.is.my.server.com/wp/this-is-a-test/

... o que sugere duas coisas para mim:

1. A própria regra de reescrita está enviando a solicitação corretamente, mas
2. A solicitação reescrita pode estar faltando informações necessárias para que o PHP/WordPress interprete adequadamente a solicitação ou
3. A regra na pasta WordPress que redireciona solicitações que não são um arquivo ou uma pasta index.phpnão está sendo executada por algum motivo.

Mas não sei o que precisaria ser feito para que essa regra de reescrita funcionasse corretamente.