Re: Wierd Logs

[Robert Collins <robert.collins () ITDOMAIN COM AU>]

Just a few thoughts

To enlarge on the answer that message usually indicates you have NAT on
but aren't translating that source address *or* that destination
address. (You don't _have_ to translate everything)

If the src address is not on your network it's probably someone routing
onto your LAN from a home modem or some such internal issue. If the
destination address is an address you aren't translating, (because you
use it internally somewhere), maybe a router went down and the traffic
was incorrectly hitting the PIX...

Rob

> -----Original Message-----
> From: Otto Peltomaa [mailto:otto.peltomaa () HELTEL FI]
> Sent: Tuesday, 29 August 2000 5:37 AM
> To: INCIDENTS () SECURITYFOCUS COM
> Subject: Re: Wierd Logs
>
>
> Hi Rick
>
> I found at least somekind of an ansver for you from Cisco CCO -site:
> "
> %PIX-3-305005: No translation group found for protocol.
>
> Explanation   This message logs when a nat and global command 
> cannot be
> found for a protocol. The protocol can be TCP, UDP, or ICMP.
>
> Action This message can be either an internal error or an error in the
> configuration."
>
>
> Otto Peltomaa
> System Engineer, Information Technology
> Oy Heltel Ab
> FINLAND
>  - - -
>
>
> Incidents,
>
>   I have seem some very strange things in my PIX logs and I wanted to
> see if
> someone could shed some light on this. I have repeatedly tested and
> cannot
> reproduce this attack.
>
> The logs state
>
> 305005: No translation group found for tcp src
> inside:246.89.253.41/27849
> dst outside:200.254.60.200/8755
> 305005: No translation group found for tcp src
> inside:62.195.36.140/27082
> dst outside:200.254.60.200/8763
> 305005: No translation group found for tcp src
> inside:33.188.240.89/57477
> dst outside:200.254.60.200/8770
> 305005: No translation group found for tcp src
> inside:201.243.53.18/25288
> dst outside:200.254.60.200/8778
>
> This is a small piece of the logs, and this attack went on for several
> hours, The PIX is configured for NAT and to only allow outbound
> connections.
> and NONE of these addreses are in our address space at all.
>
> I have tracked the origin of the attack back and dealt with it there ,
> but I
> am still unsure of what/how allowed them to bring down the network
> behind
> the PIX.  I have tried Smurf/Tribe floods , spoofing src addreses,
> anything
> I could things of , but I could not duplicate this. (of course that
> could
> also be the result of dealing with it for 26 hours :) I could not get
> the
> dst address to be wrong. Anyway can someone shed some light here...
>
> Thanks !
> Off to sleep
>
> Rick