I''ve been reading about DROP vs. REJECT and some are saying that DROP causes problems without any benefit. Do you guys agree? Should DROP normally not be used at all? - Grant ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword
Grant wrote:> I''ve been reading about DROP vs. REJECT and some are saying that DROP > causes problems without any benefit. Do you guys agree? Should DROP > normally not be used at all?DROP is perfectly acceptable as a default policy for traffic from the internet. Shorewall''s "default DROP action" (action.Drop) get applied before a packet is actually dropped, ensuring that traffic that it is potentially harmful to DROP is handled properly. DROP isn''t particularly friendly for traffic that originates behind your firewall -- for that traffic, REJECT is a better choice. ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword
>> I''ve been reading about DROP vs. REJECT and some are saying that DROP >> causes problems without any benefit. Do you guys agree? Should DROP >> normally not be used at all? > > DROP is perfectly acceptable as a default policy for traffic from the > internet. Shorewall''s "default DROP action" (action.Drop) get applied > before a packet is actually dropped, ensuring that traffic that it is > potentially harmful to DROP is handled properly. > > DROP isn''t particularly friendly for traffic that originates behind your > firewall -- for that traffic, REJECT is a better choice.What is the advantage of using DROP? Is it supposed to leave the requester wondering whether or not there is a service running at that location? - Grant ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword
> What is the advantage of using DROP? Is it supposed to leave the > requester wondering whether or not there is a service running at that > location?More or less... Imagine the big bad wolf knocking on your door. REJECT says "nyah nyah nyah, the door is locked" ...but maybe the wolf will huff and puff and blow your house down anyway. DROP says absolutely nothing, leaving the wolf scratching his head over whether the dead silence means nobody''s home or means somebody''s hiding under the bed. DROP implements what in some other contexts is called "stealth". A few years ago some of those home NAT boxes were released without a "stealth" capability, and the feedback was so resoundingly negative they quickly got a firmware revision. DROP is very useful for "flying under the radar", which is often a good way to avoid being hacked. The downside of DROP, since everybody''s treated the same, is that YOU won''t be able to get any response either. It can make troubleshooting quite difficult. Assuming troubleshooting the Internet is _somebody_else''s_ problem so it''s okay to use DROP liberally on your outside interface (where the hackers are) is often reasonable. thanks! -Chuck Kollars ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword
Grant wrote:>>> I''ve been reading about DROP vs. REJECT and some are saying that DROP >>> causes problems without any benefit. Do you guys agree? Should DROP >>> normally not be used at all? >> DROP is perfectly acceptable as a default policy for traffic from the >> internet. Shorewall''s "default DROP action" (action.Drop) get applied >> before a packet is actually dropped, ensuring that traffic that it is >> potentially harmful to DROP is handled properly. >> >> DROP isn''t particularly friendly for traffic that originates behind your >> firewall -- for that traffic, REJECT is a better choice. > > What is the advantage of using DROP? Is it supposed to leave the > requester wondering whether or not there is a service running at that > location?Since DROP doesn''t return any indication to the dropped connection request: a) It reduces the footprint of your network making it less visible from the internet. This has the effect of slowing down port scanners. b) In the event of a DDOS attack using forged source addresses, it prevents your firewall from contributing to the attack. c) In the event of a DOS attack on your network, it prevents a flood of output responses. ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword
>>>> I''ve been reading about DROP vs. REJECT and some are saying that DROP >>>> causes problems without any benefit. Do you guys agree? Should DROP >>>> normally not be used at all? >>> DROP is perfectly acceptable as a default policy for traffic from the >>> internet. Shorewall''s "default DROP action" (action.Drop) get applied >>> before a packet is actually dropped, ensuring that traffic that it is >>> potentially harmful to DROP is handled properly. >>> >>> DROP isn''t particularly friendly for traffic that originates behind your >>> firewall -- for that traffic, REJECT is a better choice. >> >> What is the advantage of using DROP? Is it supposed to leave the >> requester wondering whether or not there is a service running at that >> location? > > Since DROP doesn''t return any indication to the dropped connection request: > > a) It reduces the footprint of your network making it less visible from > the internet. This has the effect of slowing down port scanners. > > b) In the event of a DDOS attack using forged source addresses, it > prevents your firewall from contributing to the attack. > > c) In the event of a DOS attack on your network, it prevents a flood of > output responses.Thanks, that makes a lot of sense. Is there a way to scan for REJECTions so you can tell if you need to be DROPping any that you aren''t? - Grant ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword
Grant wrote:> > Thanks, that makes a lot of sense. Is there a way to scan for > REJECTions so you can tell if you need to be DROPping any that you > aren''t?Look at your log. ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword