It will stop attacks on ports/services that are not allowed. However, it cannot stop attacks for ports/services that are allowed. For example, you would hopefully deny inbound tcp/445 but might allow tcp/80 in for web services. We can still attack the web server and the web application....which is allowed by the ingress filtering.

Ahh okay thanks 

I had no idea there was a difference! Thanks for the clarification. I always assumed it was the same concept as egress filtering, which is apparently different!

This isn't directed at anyone who responded in this thread, but aside from garbage CEH trivia questions, I don't think there is a difference.

This seems to have caught on from the RFCs (2827 is actually superseded by 3704). However, these are specifically written for mitigating DoS attacks for service providers/large networks. They aren't literally defining the term.

There is no legitimate reason for ingress filtering to not mean the exact opposite of egress filtering.

Not making a argument or anything, just sharing my experience.

-3704 yes is an update to 2827, so it supersedes as such, but still  2827 is used to refer to uRPF as a base. Even CCIE v4 exams still use 2827 lol ... to test on.

- I do agree about ingress and egress as they are basically to block invalid traffic to enter or leave the network respectively, Whatever it maybe Spooing, Smurf etc.

Having ingress we allow certain things to enter our network.

However egress can be used to identify any anomaly. Egress usually let almost all IP traffic out of network (expect sourced from 1918, Bogon,  multicast,  and even some ftp, tftp, protocols).

I like to use egress to find out a sudden spike in outbound bandwidth and random ports sending large traffic; which is useful is end machines have been part of a bonet or a virus. Egress helps to quickly stop these attacks going out of the network. Once things are more clear on analysis, acls close the source of malicious activity can be applied.