Por que as configurações de sysctl do kernel 'net.inet.ip.forwarding' e 'net.inet.ip.fw.enable' permanecem ativas mesmo depois de desativá-las em um Xserve executando 10.6.8?

3

Situação muito bizarra. Eu herdei alguns Xservers de um administrador anterior que eu fui encarregado de limpar em vários níveis. Eu estou familiarizado com as configurações no Ubuntu e estou muito confortável com a linha de comando - incluindo compilar a partir da fonte - além de saber como manobrar em torno da linha de comando no OS X também. Mas me deparei com algo totalmente desconcertante em um dos servidores que está executando o 10.6.8 (Snow Leopard).

Primeira esquisitice, gostaria de desativar completamente o firewall de software. Soa tão simples como entrar em Server Admin e apenas dizendo para parar o firewall certo? Não! Então, se eu desligar o firewall, e eu faço o seguinte comando para verificar novamente na linha de comando:

sysctl -a | grep net.inet.ip.fw.enable

Os resultados são os esperados:

net.inet.ip.fw.enable: 0

Mas, se eu verificar novamente dentro de 5 minutos, ele será magicamente ativado novamente:

net.inet.ip.fw.enable: 1

Idem com o encaminhamento de NAT.

sysctl -a | grep net.inet.ip.forwarding

Desative no Administrador de servidores e este é o resultado:

net.inet.ip.forwarding: 0

Alguns minutos depois:

net.inet.ip.forwarding: 1

WTF?!? Eu verifiquei crontabs e eu sou o único usuário na máquina.

Eu tenho o aplicativo Server Admin em outra máquina definida para assistir a esta máquina, mas ela não está sendo executada o tempo todo. E esta questão existia antes disso. Eu não estou 100% familiarizado com sysctl , então preciso de orientação. FWIW, tenho alguns ajustes de Ethernet que defini em /etc/sysctl.conf muito recentemente, mas não há outros comandos ou configurações conectadas ao acima.

Por que essas configurações parecem mudar magicamente após alguns minutos? O que pode ser feito para impedir isso?

Agradecemos antecipadamente pela ajuda & ponteiros.

EDIT: conteúdo de /etc/hostconfig de acordo com um dos comentários abaixo:

AFPSERVER=-NO-
AUTHSERVER=-NO-
TIMESYNC=-NO-
QTSSWEBADMIN=-NO-
QTSSRUNSERVER=-NO-
MYSQLCOM=-YES-
IPFORWARDING=-NO-
    
por JakeGould 31.01.2013 / 05:26

2 respostas

1

Ok, resolvi esse aqui. Obrigado por todos os conselhos pessoal!

O que aconteceu é que há um aplicativo Java em execução através de um programa shell do Mac nesta máquina que possui opções diferentes para criar uma interface da Web baseada no Jetty. De alguma forma, isso foi configurado para assumir a porta 80 - a porta HTTP padrão - e desabilitar isso alterando o URL da porta para outra coisa - como 666666 - resolveu o problema. net.inet.ip.fw.enable e net.inet.ip.forwarding permanecem definidos em 0 (também conhecidos como: desativado) e não voltam à vida quando a porta é alterada para uma porta não padrão para fins de HTTP.

Dito isso, ainda preciso que o conteúdo seja entregue por meio de uma conexão padrão da porta 80. Então, liguei os serviços da Web no servidor & defina um proxy reverso daquele para a porta 666666. Tudo se comporta como deveria.

Mas o que é preocupante para mim é como o aplicativo conseguiu assumir algumas funções sudo level - como definir sysctl options - sem aparentemente pedir uma senha de administrador. Isso é normal para aplicativos Jetty ou idiossincrático para este aplicativo? Talvez tenha pedido uma senha de administrador quando foi instalada antes mesmo de eu ir para ela? Não sei nem me importo agora. Mas esclarecer isso esclareceu muitos problemas de rede nesta caixa, agora que este aplicativo não está mais sequestrando o roteamento & funções de firewall.

    
por 25.02.2013 / 03:10
2

Apenas uma ideia, mas você pode usar a ferramenta auditctl para ver quais processos estão tocando seu /etc/sysctl.conf .

Você pode ler mais sobre o auditctl neste tópico:

Especificamente, esta resposta:

A essência é você executar este comando:

% sudo auditctl -p a -w /etc/sysctl.conf

E, em seguida, observe o arquivo de log para ver quem é o processo culpado:

% tail -f /var/log/audit/audit.log
    
por 14.02.2013 / 15:20