[clue-tech] remote access to Windows network from Linux

[Jim Ockers]

Hi David,

David L. Willson wrote:
> Jim,
>
> I don't know if I'm a "senior" network engineer. I know I'm a darn 
> busy one. Maybe I'm a darn busy doofus? I will say that you walk your 
> talk, though. Even "www.ockers.net" is ping-able. I ... can't honestly 
> say I agree with leaving that on, but I see value in your consistency. :-)
Thanks for reminding me, I need to put up a legit web site there.  :)
>
> When I recommend turning it off, BTW, I'm referring mostly to 
> ping-sweeps, not to smurf/POD/DDOS attacks. A ping-sweep of a range is 
> often a moron's first step in "target discovery" and sometimes it's 
> just wiser to avoid the morons.
There are lots of ways of discovering a "target" and ping is just a 
convenience.  If your server gets h4x0red as a result of someone finding 
it via ping, then you have bigger security problems than the fact that 
ping was enabled.

I still think it's useful to leave ping enabled and then if someone is 
abusing it by flooding you something like that then you can address the 
problem on a case by case basis.  The usefulness of ICMP almost always 
outweighs the risks of turning it off, IMHO.  (Except for certain very 
risky cases, but those would be the exception, not the rule.)

Jim

>
> David L. Willson
> Trainer, Engineer, Enthusiast
> MCT MSCE Network+ A+ Linux+ LPIC-1 NovellCLA UbuntuCP
> tel://720.333.LANS
> Freeing people from the tyranny (or whatevery) of Microsofty-ness
>
> ----- "Jim Ockers" <ockers at ockers.net> wrote:
> > David L. Willson wrote:
>
>     >
>     > Nate: Turning off ping responses ~does~ "add security", just
>     like running ssh on a non-default port, and not returning specific
>     version numbers for PHP, and other things of that sort. Not
>     providing more info/access than needed is part of a good security
>     policy.  Turning off ping responses ~might~ be appropriate,
>     depending on the circumstances.
>     >
>
> Well I have to challenge this because as a senior network engineer who 
> troubleshoots strange problems that confuse everyone else, I find that 
> a disproportionate share of incidents that land on my desk have to do 
> with blocked ICMP.  I agree with Nate, in almost every case a sysadmin 
> who blocks ICMP echo request or reply is a doofus.  They may be well 
> meaning but if they actually do it (or if they aren't careful about 
> it) then they are a doofus.
> >
> > Blocking ICMP usually adds nearly nothing in security and serves 
> only to create a lot of confusion.  ICMP is an important part of the 
> IP protocols and people generally expect it to work, so when it 
> doesn't people tend to make incorrect assumptions about what's not 
> working.  Also, those pesky insecurity-causing type 3 packets are 
> absolutely critical to allow through from end to end if there is any 
> chance there is a network connection somewhere along the line with a 
> smaller MTU than what the sending system expects.  Over the years I 
> have seen several weird application issues caused by ICMP type 3 
> blocking, so much so that based on the symptoms that might be one of 
> the first things I check when I start troubleshooting.
> >
> > Sure there used to be the old smurf etc. attacks based on incorrect 
> ICMP handling, but I don't think there have been widespread issues 
> with ICMP for years now.
> >
>
>     >
>     >
>     > OTOH, once on the same IP subnet, an arp request is rarely
>     (never) declined, and so might make a better test.
>     >
>
> I think ARP traffic wouldn't be forwarded through a VPN router, since 
> I think it is on the ethernet segment only.
> >
>
>     >
>     >
>     > Dennis: Are you sure the VPN needs to be up to get to the TS?
>     There are an increasing number of networks with TS available
>     directly to the Internet.
>     >
>
> That might be a good idea and Dennis you could try suggest that to 
> your sysadmin/IT people.
> >
> > Jim
> >
> >

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://cluedenver.org/pipermail/clue-tech/attachments/20100923/77302531/attachment.html