Filtrando requisições inválidas do Apache - logger - rsyslog para syslog-ng em um servidor de log remoto possível?

3

EDIT: Obrigado pela ajuda

Aqui está uma ideia rápida da configuração:

servidor da web X

No apache httpd.conf:

LogFormat "%v %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" vcombined
CustomLog "|/usr/bin/logger -p local6.info -t access " vcombined

No rsyslog.conf:

*.* @logserver

Logserver

syslog-ng.conf:

...
parser p_apache {csv-parser(columns(
"APACHE.VIRTUAL_HOST",
"APACHE.CLIENT_IP",
"APACHE.IDENT_NAME",
"APACHE.USER_NAME",
"APACHE.TIMESTAMP",
"APACHE.REQUEST_URL",
"APACHE.REQUEST_STATUS",
"APACHE.CONTENT_LENGTH",
"APACHE.REFERER",
"APACHE.USER_AGENT",
"APACHE.PROCESS_TIME",
"APACHE.SERVER_NAME")
# flags:
#   escape-none,escape-backslash,escape-double-char,
#   strip-whitespace
flags(escape-double-char,strip-whitespace)
delimiters(" ")
quote-pairs('""[]')
);};
...
source s_net { udp(ip(0.0.0.0) port(514) so_rcvbuf(1048576)); };
destination hosts_acc { file("/var/log/hosts/$HOST/${APACHE.VIRTUAL_HOST}_acc.log"); };
filter f_apacheacc   { facility(local6); };
log { source(s_net); parser(p_apache); filter(f_apacheacc); destination(hosts_acc); };
...

O log chega bem, mas há muitos logs como os seguintes:

-rw------- 1 root root       5726 Apr  6 01:02 xc3\x9d\xc3\x9ed$yA;_acc.log
-rw------- 1 root root      23435 Apr  6 01:06 \xc3\x9ed$yA;_acc.log
-rw------- 1 root root        745 Apr  6 00:57 xc3\x9ed$yA;_acc.log
-rw------- 1 root root       8440 Apr  5 22:50 \xc3\xaf_F\xc3\x95$yA;_acc.log
-rw------- 1 root root       3112 Apr  6 00:58 xe2\x80\x94w\xe2\x80\x98\xc3\x9d\xc3\x9ed$yA;_acc.log
-rw------- 1 root root       4220 Apr  5 22:03 xe2\x80\x98\twd\xc2\xa2\xc2\xb0\xc3\x96$yA;_acc.log
-rw------- 1 root root       1055 Apr  5 22:03 xe2\x80\x98\xc2\x9dw\xc3\x94\xc3\xb4T\xc5\x93$yA;_acc.log
-rw------- 1 root root       1821 Apr  6 00:58 \xe2\x80\x98\xc3\x9d\xc3\x9ed$yA;_acc.log
-rw------- 1 root root       2875 Apr  6 01:02 xe2\x80\x98\xc3\x9d\xc3\x9ed$yA;_acc.log
-rw------- 1 root root       3165 Apr  5 22:48 \xe2\x80\x99-w\xc3\xaf_F\xc3\x95$yA;_acc.log
-rw------- 1 root root       3165 Apr  5 22:40 \xe2\x80\x99\xe2\x80\x9aw\xe2\x82\xac\xc2\xbd\xe2\x80\x9d($yA;_acc.log
-rw------- 1 root root      15825 Apr  5 22:50 xe2\x80\x99\xe2\x80\x9aw\xe2\x82\xac\xc2\xbd\xe2\x80\x9d($yA;_acc.log
-rw------- 1 root root       1055 Apr  5 22:39 \xe2\x80\x9aw\xe2\x82\xac\xc2\xbd\xe2\x80\x9d($yA;_acc.log
-rw------- 1 root root       2110 Apr  5 22:50 xe2\x80\x9aw\xe2\x82\xac\xc2\xbd\xe2\x80\x9d($yA;_acc.log
-rw------- 1 root root       2034 Apr  5 22:50 \xe2\x80\x9d($yA;_acc.log
-rw------- 1 root root       4066 Apr  5 22:45 xe2\x80\x9d($yA;_acc.log
-rw------- 1 root root       7212 Apr  6 13:30 \xe2\x80\xb9>$yA;_acc.log
-rw------- 1 root root       3000 Apr  6 13:25 xe2\x80\xb9>$yA;_acc.log

A minha pergunta é onde e como posso filtrá-los, não os quero no sistema de arquivos (Mas, na verdade, acho que não seria uma má idéia mantê-los logados, mas no arquivo VHost correto)

Aqui está um exemplo de VHost

<VirtualHost *:80>
    ServerAdmin [email protected]
    ServerName xxx.xx
    DocumentRoot /var/www/vhosts/xxx
    <Directory /var/www/vhosts/xxx>
        AllowOverride All
        Options All
        RewriteEngine on
    </Directory>
</VirtualHost>

E o vhost "pega-tudo" padrão na parte inferior do arquivo de configuração do vhosts:

<VirtualHost *:80>

    ServerName default
    ServerAlias *
    ServerAlias catchall.xxx.xx

    DocumentRoot /var/www/vhosts/nodomain

    <Directory "/var/www/vhosts/nodomain">
        Options Indexes FollowSymLinks
        AllowOverride none
        Allow from All
    </Directory>
    CustomLog /dev/null combined
    ErrorLog /dev/null
</VirtualHost>

Eu publiquei isso em uma pergunta relacionada mas é melhor em sua própria pergunta.

Aqui estão alguns exemplos de dentro dos arquivos de log

r_acc.log:
Apr  7 11:16:27 xxxxx access: r PC 5.0; eSobiSubscriber 2.0.4.16; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C)"
Apr  7 11:16:28 xxxxx access: r PC 5.0; eSobiSubscriber 2.0.4.16; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C)"

########################

D46-28E2-0FBC95-78798EV\xe2\x80\x94w\xe2\x80\x98\xc3\x9d\xc3\x9ed$yA;_acc.log:
Apr  7 14:54:06 xxxxx access: D46-28E2-0FBC95-78798EV\xe2\x80\x94w\xe2\x80\x98\xc3\x9d\xc3\x9ed$yA; B557000E-F20D-35DD-021A-9824EC-17A4AFV\xe2\x80\x94w\xe2\x80\x98\xc3\x9d\xc3\x9ed$yA; 3BD03D7B-EEFD-83FF-7599-B751AD-6F0A2EV\xe2\x80\x94w\xe2\x80\x98\xc3\x9d\xc3\x9ed$yA; 9CAE0724-D455-0B31-3378-871C11-BBD0A4V\xe2\x80\x94w\xe2\x80\x98\xc3\x9d\xc3\x9ed$yA; C1E24799-3979-2452-81-3BAA0FFD361F5A; 0E701CBC-5832-5AB6-D5-CFBF9BDE863EAA; 464714B1-B3E2-774A-A4-FEA612A46CEE06; 74C817B0-D081-D2CC-6D-C4EF0F1B4F49BB; 1338B1DE-67CD-977C-B35D-1F2C4441DD6A; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 1.1.4322; .NET CLR 3.5.30729; .NET CLR 3.0.30729; OfficeLiveConnector.1.5; OfficeLivePatch.1.3; .NET4.0C; BRI/2)"

########################

V\xe2\x80\x94w\xe2\x80\x98\xc3\x9d\xc3\x9ed$yA;_acc.log:
Apr  7 14:55:04 xxxxx access: V\xe2\x80\x94w\xe2\x80\x98\xc3\x9d\xc3\x9ed$yA; FEEACE4F-092A-1D46-28E2-0FBC95-78798EV\xe2\x80\x94w\xe2\x80\x98\xc3\x9d\xc3\x9ed$yA; B557000E-F20D-35DD-021A-9824EC-17A4AFV\xe2\x80\x94w\xe2\x80\x98\xc3\x9d\xc3\x9ed$yA; 3BD03D7B-EEFD-83FF-7599-B751AD-6F0A2EV\xe2\x80\x94w\xe2\x80\x98\xc3\x9d\xc3\x9ed$yA; 9CAE0724-D455-0B31-3378-871C11-BBD0A4V\xe2\x80\x94w\xe2\x80\x98\xc3\x9d\xc3\x9ed$yA; C1E24799-3979-2452-81-3BAA0FFD361F5A; 0E701CBC-5832-5AB6-D5-CFBF9BDE863EAA; 464714B1-B3E2-774A-A4-FEA612A46CEE06; 74C817B0-D081-D2CC-6D-C4EF0F1B4F49BB; 1338B1DE-67CD-977C-B35D-1F2C4441DD6A; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 1.1.4322; .NET CLR 3.5.30729; .NET CLR 3.0.30729; OfficeLiveConnector.1.5; OfficeLivePatch.1.3; .NET4.0C; BRI/2)"

###################

xc2\x90\xc3\x91\xc3\x94\xc2\xab$yA;_acc.log:
Apr  7 19:48:39 xxxxx access: xc2\x90\xc3\x91\xc3\x94\xc2\xab$yA; 3C12D25C-9D40-91CF-1F40-AC-B1A083426DV-w\xc2\x90\xc3\x91\xc3\x94\xc2\xab$yA; D4713FA8-0142-A0C2-4812-BA-E03221005BV-w\xc2\x90\xc3\x91\xc3\x94\xc2\xab$yA; 199BAF2A-ECD5-39FA-65C3-E8-B107FAFF08V-w\xc2\x90\xc3\x91\xc3\x94\xc2\xab$yA; 384BDA70-9954-7744-05A0-C4-C7D9FEA685V-w\xc2\x90\xc3\x91\xc3\x94\xc2\xab$yA; EE7292A9-333C-AF70-5A7F-55-CAA7D0BA39V-w\xc2\x90\xc3\x91\xc3\x94\xc2\xab$yA; -AD7D48FA3A55-2A33-D10B-B4B66276D8B8; -166A9C6A2E71-24DF-A192-C8258AA4DE14; -00077C6C84E0-A302-4954-3D6D17C54D31; 3F56C318-EC3C-432B-680F-7E4BB2B852C4; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C)"
Apr  7 19:48:39 xxxxx access: xc2\x90\xc3\x91\xc3\x94\xc2\xab$yA; 3C12D25C-9D40-91CF-1F40-AC-B1A083426DV-w\xc2\x90\xc3\x91\xc3\x94\xc2\xab$yA; D4713FA8-0142-A0C2-4812-BA-E03221005BV-w\xc2\x90\xc3\x91\xc3\x94\xc2\xab$yA; 199BAF2A-ECD5-39FA-65C3-E8-B107FAFF08V-w\xc2\x90\xc3\x91\xc3\x94\xc2\xab$yA; 384BDA70-9954-7744-05A0-C4-C7D9FEA685V-w\xc2\x90\xc3\x91\xc3\x94\xc2\xab$yA; EE7292A9-333C-AF70-5A7F-55-CAA7D0BA39V-w\xc2\x90\xc3\x91\xc3\x94\xc2\xab$yA; -AD7D48FA3A55-2A33-D10B-B4B66276D8B8; -166A9C6A2E71-24DF-A192-C8258AA4DE14; -00077C6C84E0-A302-4954-3D6D17C54D31; 3F56C318-EC3C-432B-680F-7E4BB2B852C4; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C)"

Obrigado

    
por zeyus 06.04.2011 / 17:40

3 respostas

1

Se você quiser manter a sua configuração de log igual e lidar com esses arquivos estranhos no syslog-ng, você pode tentar definir um filtro de 'hosts conhecidos' e adicioná-lo a todas as suas diretivas de log.

Em seguida, capture os que não estiverem em um log de fallback com um nome que não dependa de informações na mensagem de log.

destination hosts_acc { file("/var/log/hosts/$HOST/${APACHE.VIRTUAL_HOST}_acc.log"); };
destination hosts_def { file("/var/log/hosts/unk/unmatched.log"); };
filter f_apacheacc   { facility(local6); };
filter f_known { host("myserver1") or host("myserver2") or...); };
log { source(s_net); parser(p_apache); filter(f_known); filter(f_apacheacc); destination(hosts_acc); flags("final"); };
log { source(s_net); parser(p_apache); filter(f_apacheacc); destination(hosts_def); flags("fallback"); }; 

Você pode fazer uma coisa semelhante para qualquer variável, como APACHE.VIRTUAL_HOST ou com o que quiser

    
por 08.04.2011 / 20:05
0

Não tem seu log vhost padrão.

(Adicionando mais aqui para poder usar formatação.)

Você provavelmente deseja os logs. Você poderia configurar o vhost padrão da seguinte forma:

LogFormat "default %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" vcombineddefault
CustomLog "|/usr/bin/logger -p local6.info -t access " vcombineddefault

Substitui %v por default .

(Estou supondo que o rsyslog esteja analisando corretamente o log do apache. Não sei sobre essa parte.)

    
por 06.04.2011 / 18:52
0

(Estou substituindo minha resposta antiga por essa nova resposta com base nas novas informações que você está dando. Infelizmente, ainda não tenho uma resposta.)

Estes são solicitações malformadas para o seu servidor da web. Não há método GET ou POST, etc. e isso está jogando fora seu analisador syslog-ng. O syslog-ng está assumindo que coisas como 'xc3 \ x9d \ xc3 \ x9ed $ yA;' é o 'APACHE.VIRTUAL_HOST' e está construindo os diretórios como você também o instruiu.

De acordo com o link , este / xhh texto não é imprimível caracteres nas solicitações:

For security reasons, starting with version 2.0.46, non-printable and other special characters in %r, %i and %o are escaped using \xhh sequence

Estou confuso porque essas solicitações estão no seu log de acesso. Não há GET, HEAD, POST, etc., então não é um pedido válido do que eu posso ver.

Você pode postar mais algumas linhas do seu arquivo de log na pergunta acima (é difícil lê-las nos comentários), para que possamos ter uma ideia melhor de como essas solicitações estão chegando?

    
por 06.04.2011 / 21:22