[MASOCH-L] RES: Monitorar conexão PostgreSQL

[..:: S.e.r.i.a.L ::..]

Fabio:

com certeza essa regra será melhor fragmentada, senão, haja servidor pra
tudo isso mesmo, recursos da máquina vão estar super alto mesmo.
outro detalhe é: esse servidor não é gateway de internet, então casos como
busca por palavras, não irá ocorrer (menos mal).

Marlon:
com ctz terei que documentar tudo isso, inclusive, vou fazer um script soh
pra essas regras, com comentarios e etc, para facilitar a administração. Qto
a SSL ou qualquer outro meio encriptado, não haverá, isso é ctz.

os testes que fiz, foi com o psql, agora preciso testar com o pgadmin e o
ems.

[.]´s



Em 5 de maio de 2010 13:13, MARLON BORBA <MBORBA at trf3.jus.br> escreveu:

> O problema de fazer isso dessa forma é que você, ou quem venha a
> administrar o "firewall", deve lembrar-se de que essa regra foi inserida
> (sugestão: DOCUMENTÁ-LA em algum lugar) e, se o servidor for manutenido
> por qualquer motivo, verificar se a regra está ativa e, caso negativo,
> reativá-la.
>
> Há outros inconvenientes: Essa regra bloqueia a execução de INSERTs no
> SGBDR mesmo por pessoas autorizadas. É por isso que um controle de
> privilégios no próprio SGBDR é uma solução mais inteligente. E se a
> conexão for encriptada, você não conseguirá analisar o "payload" e
> portanto o pacote não será bloqueado.
>
>
>
>  >>>Em 5/5/2010 às 12:58, "..:: S.e.r.i.a.L ::.." <skroot at gmail.com>
> gravou:
>
> > Então, consegui bloquear o preciso através do iptables + string.
> Exemplo:
> > /sbin/iptables -A FORWARD -m string -s 0/0 -d 0/0  --string "insert"
> --algo
> > bm -j DROP
> >
> > isso fez com eu conecta-se no banco, porém não consegui fazer insert.
> A
> > única coisa chata que vi foi que ele eh sensitive case, só pelo fato
> de
> > bloquear, já resolve.
> >
> > agora vamos ver no que vai dar (rsrs).
> >
> > vlw!
> >
> > [.]´s
> >
> >
> > Em 5 de maio de 2010 12:29, MARLON BORBA <MBORBA at trf3.jus.br>
> escreveu:
> >
> >> Diria que sua monitoração está na camada 7 (Aplicação).
> >> Mas essa filtragem, pelos motivos que os meus colegas já
> destacaram,
> >> não convém, pois pode introduzir problemas de integridade no SGBDR.
> >> Sugiro tentar outro tipo de controle (privilégios de usuário no
> banco,
> >> na aplicação...).
> >>
> >>
> >>
> >>  >>>Em 5/5/2010 às 10:54, "..:: S.e.r.i.a.L ::.."
> <skroot at gmail.com>
> >> gravou:
> >>
> >> > Pensando nesse nível de monitoramento que preciso chegar, qual é
> a
> >> camada na
> >> > tabela OSI que se enquandraria?
> >> >
> >> > [.]´s
> >>
> >>
> >>
> >> --
> >>
> >> Abraços,
> >>
> >> Marlon Borba, CISSP, APC DataCenter Associate
> >> Técnico Judiciário · Segurança da Informação
> >> IPv6 Evangelist · Moreq-Jus Evangelist
> >> Comissão Local de Resposta a Incidentes - CLRI
> >> TRF 3 Região
> >> (11) 3012-2030 (VoIP)
> >> --
> >> Follow me on Twitter!
> >> twitter.com/mborba
> >> --
> >>
> >> __
> >> masoch-l list
> >> https://eng.registro.br/mailman/listinfo/masoch-l
> >>
> >
>
> --
>
> Abraços,
>
> Marlon Borba, CISSP, APC DataCenter Associate
> Técnico Judiciário · Segurança da Informação
> IPv6 Evangelist · Moreq-Jus Evangelist
> Comissão Local de Resposta a Incidentes - CLRI
> TRF 3 Região
> (11) 3012-2030 (VoIP)
> --
> Follow me on Twitter!
> twitter.com/mborba
> --
>
> __
> masoch-l list
> https://eng.registro.br/mailman/listinfo/masoch-l
>



-- 
[.]´s
..:: S.e.r.i.a.L ::..