On Jun 3, 8:41am, MICHAEL NITTMANN wrote:
} Subject: incoming/outgoing packet filtering (Cisco screening)
} Hi list,
} Don Lewis has a problem with the following configuration:
} net a ---------+
} router +-----internet
} net b ---------+
} 'How do you prevent forged packets from the internet that have net A
} or B as source address'
} 1) firewall routers must be configured to not honor source routing,
} which I assume is done for a correct firewall router
} 2) if a packet is sent with source address from net a or b from the
} internet access (I would prefer to call it 'public', not to give a
} bad sound to 'Internet'), an eventual reply will go to net a or b,
} not back to the public (his 'internet') access.
} One shot is possible.
I agree that it is unlikely that the attacker will have any feedback on
the progress of his attack, but more that one shot is possible. As long
as the attacker didn't consume too much bandwidth, he could quite possibly
keep up the attack for quite a while before being detected.
} If you allow UDP, you cannot defend against incoming packets.
} My personal opinion: isolated udp's pose no threat. Denial of
} service? This is always possible if somebody jams my public
} interface with junk. Even if it does not go through it will clog the
} public access pipe. Don't need to forge packets for that.
The problem is that since you can't block forged UDP from the public
net without affecting UDP between net A and net B (because the router
has outbound filters only), you have to carefully assess the risk to
each UDP based service on the protected net. For instance, if the
attacker can guess NFS filehandles, he can delete files (there was
a patch to SunOS a while back to make filehandles more difficult to
guess). By feeding request packets that are suitably corrupted to
various servers, it may be possible to crash them (the daemon core
dumps, the host panics, etc.).