Borja Lopez - wrote:

>On Wed, 02 Oct 2002 10:35:08 +0200
>Cedric Berger <cedricwireless-networks.com> wrote:
>
>
>
>>This is a routing problem, and a PF limitation.
>>Here is how you can do it, but you would need 2 firewalls for that.
>>
>>
>> [ bridge1 ] [ bridge2 ]
>> | |
>> | |
>> | |
>> rl1 | | rl1
>> [ firewall1 ] [ firewall2 ]
>> rl0 \ / rl0
>> \ /
>> \ /
>> \ /
>> [switch]
>> |
>>
>> |
>> { SERVERS }
>>
>>
>>Ok, what is really important on this settings it that each
>>of the firewall has its default route different, pointing
>>upstream on the internet.
>>
>>Now here comes the trick: you need to put the following
>>rules on each firewall:
>>
>>FW1:
>>
>>rdr on rl1 proto tcp from any to my_public_ip1/32 port 80 -> 192.168.4.3 port 80
>>rdr on rl1 proto tcp from any to my_public_ip1/32 port 443 -> 192.168.4.3 port 443
>>rdr on rl1 proto tcp from any to my_public_ip1/32 port 25 -> 192.168.4.3 port 25
>>nat on rl0 froto tcp from !rl0 to 192.168.4.3 -> rl0
>>
>>FW2:
>>
>>rdr on rl1 proto tcp from any to my_public_ip2/32 port 80 -> 192.168.4.3 port 80
>>rdr on rl1 proto tcp from any to my_public_ip2/32 port 443 -> 192.168.4.3 port 443
>>rdr on rl1 proto tcp from any to my_public_ip2/32 port 25 -> 192.168.4.3 port 25
>>nat on rl0 froto tcp from !rl0 to 192.168.4.3 -> rl0
>>
>>
>>The "trick" here is the NAT lines. this is NOT for outgoing traffic. this NAT
>>line is for incoming traffic. it will create a second state on the firewall,
>>first state is the redirect, and second state will change the *source* address
>>of incoming packets to be the internal IP of the firewall. If you do that, the
>>servers will believe that all connections comes from the internal addresss of
>>one of the firewall, and will be able to route it back to the correct firewall.
>>This will create true symetrical routing (that was the problem in your first
>>setting).
>>
>>I've tested that, it works perfectly with 3.1. There is only one problem,
>>you loose on the server the ability to know the real source address of
>>your connections. that might or might not be a problem for you. usually,
>>this info is just used for logging, and logging can be done on the firewall
>>as well.
>>
>>
>
>OK, i have done the config with two firewalls, one trick: it works perfectly
>if you only do the nat trick you said in one firewall, so, you only lose 50%
>of the apache logs.
>That's my main problem, the logging facility. Apache logs are almost perfect,
>and i want to know every ip that connects to my mail server.
>Thinking about that, i only have an idea: to do a log all on both firewalls...
>but it could be a high load for them (both are powerful AMD Athlon 1.2Ghz and 128-256Mb RAM).
>How do you do your logs? any tip?
>
If you want to log everything, the question is more about your hard
drive performances (think fast SCSI) than your raw power. If you
went to decode packets to print a log looking like apache logs, that
is another story. You can also use PF to tell him to duplicate all
IP packets to a third interface, and log the data from both firewalls
on another device. there is an infinite number of solutions here.

You asked me how I do my logs, so I will answer that question.
But be warned that this is just a quick-n-dirty method, and I'm
sure people will jump in and say that it is all bad. I know.

logger# cat log.sh
  #!/bin/ksh
  NOW=`date "+%Y-%m-%d-%H"`
  echo $$ >/root/log.pid
  exec tcpdump -s 2000 -ni fxp1 -w $NOW".log" your_tcpdump_rule(tcp port
80 for inst.)
logger# cat logloop.sh
  while true; do
        /root/log.sh
  done
logger# crontab -l | tail -1
0 * * * * kill `cat /root/log.pid`
logger# nohup ./logloop.sh &

logger# cat log
But there is certainly much much better way for doing that in your case.
You just need to find a package which will look deep enough in the
HTTP 1.0/1.1 packet to extract the requested URL. Maybee one of the
intrusion detection package can generate such a log. Doing that for SSL
will be a more difficult challenge, though.
Cedric

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]