Jump to content



Photo

Blocking network scan via smartphones apps "Fing"?


  • Please log in to reply
12 replies to this topic

#1 zoheb

zoheb

    Neowinian

  • Joined: 02-January 10
  • Location: haLLuNicaTeD pAradISe

Posted 04 August 2014 - 22:15

I came around with this android tool fing.  

When I was on office Wifi, I got a list of all the systems that are running across different networks.(3 VLANs with inter VLAN talking) using this app "Fing".

 

 The problem is some of them are servers which I don't want to expose.  Is it possible that we can prohibits specific linux/Windows systems to respond to such scans. 

 

If not, what should be the best approach in this scenario.

 

TIA ...




#2 +theblazingangel

theblazingangel

    Software Engineer

  • Tech Issues Solved: 6
  • Joined: 25-March 04
  • Location: England, UK

Posted 04 August 2014 - 23:14

You're focusing on the wrong thing. Why are you worrying about your servers showing up on simple scans like this, that in itself is not a big deal. The fact that they show up doesn't automatically make them insecure. Furthermore, attempting to block the servers from responding to such scans is only going to make connectivity issues more difficult for an administrator to troubleshoot.

 

Now what you should be concerned with is:

  • Maintaining the security of the servers - are they kept up to date with security patches; are they configured securely; etc - because it's security vulnerabilities and misconfiguration that result in compromise, not a computer's visibility.
  • Locking down network access to restrict what can access what on the network.


#3 Raa

Raa

    Resident president

  • Tech Issues Solved: 7
  • Joined: 03-April 02
  • Location: NSW, Australia

Posted 04 August 2014 - 23:21

If they're on your corporate wifi, what system are you using?

Enterprise grade wireless systems can help with this problem (Aruba, etc).

 

I deployed an Aruba system from scratch for work and have policies that restrict that sort of traffic.

 

As far as commercial wireless systems go though, it'll be a harder job as you'd probably have to put the APs behind firewalls or route the traffic to a proxy system to do the job, which may cause other issues for your users.



#4 +BudMan

BudMan

    Neowinian Senior

  • Tech Issues Solved: 100
  • Joined: 04-July 02
  • Location: Schaumburg, IL
  • OS: Win7, Vista, 2k3, 2k8, XP, Linux, FreeBSD, OSX, etc. etc.

Posted 04 August 2014 - 23:39

"When I was on office Wifi, I got a list of all the systems that are running across different networks.(3 VLANs with inter VLAN talking) using this app "Fing"."

I have the tool fing - notsure how you saw different vlans. Fing only scans the segment its on from my experience with it.

You state you were ON your corp network, so as the blazing angle mentiones not sure why answering a simple ping would be any sort of issue?

What do you think was exposed, to your own what I would assume secure network? Do you not have clients on this network that need to access these servers?

What I would wonder is why servers would be on the same segment as your wireless? Wireless should be segmented off with controls that only specific ports and services to specific IP on your other segments would be available from the wireless segment.

#5 OP zoheb

zoheb

    Neowinian

  • Joined: 02-January 10
  • Location: haLLuNicaTeD pAradISe

Posted 05 August 2014 - 07:51

I have the tool fing - notsure how you saw different vlans. Fing only scans the segment its on from my experience with it.

>> Wifi n/w has 192.168.0.0 n/w whose WAN IP is 192.168.1.x.  Now 192.168.1.x.is allowed to talk with other networks too.. i.e 192.168.2.0 and 192.168.3.0. 

 

So as per the implementation, any device in n/w 192.168.0.0 can get connected to all the networks.  But no system on 192.168.1.x / 192.168.2.x / 192.168.3.x network can connect to 192.168.0.0 n/w.

 

What I am planning is to limit access to only few servers (DNS/Samba etc) from Wifi n/w.  I am thinking of passing all Wifi traffic via Squid so that we can have access control there.  Let me know if any better solution.

 

Why are you worrying about your servers showing up on simple scans like this?

>> Sometimes we give guest access for some users that work on temp basis.  We do not want them to use Fing and get idea out all the servers.  Because one of them is entry to production though it is secured via ssh auth. But still why to take chances. 

 

BTW, this is what the security chairman of our company wants us to implement.

 

Regards.

Zoheb



#6 +ChuckFinley

ChuckFinley

    member_id=28229

  • Joined: 14-May 03

Posted 05 August 2014 - 07:53

"When I was on office Wifi, I got a list of all the systems that are running across different networks.(3 VLANs with inter VLAN talking) using this app "Fing"."

I have the tool fing - notsure how you saw different vlans. Fing only scans the segment its on from my experience with it.
 

 

I was going to say the EXACT same thing myself unless its been updated recently and you can specify subnets but I dont think so.

 

Sounds like this guy wants to hide his Pr0n and Torrent server at work  :shiftyninja:

 

The simple matter is that if you have a server, Well Clients need to be able to talk to it in some way shape or form....



#7 +BudMan

BudMan

    Neowinian Senior

  • Tech Issues Solved: 100
  • Joined: 04-July 02
  • Location: Schaumburg, IL
  • OS: Win7, Vista, 2k3, 2k8, XP, Linux, FreeBSD, OSX, etc. etc.

Posted 05 August 2014 - 10:45

"Wifi n/w has 192.168.0.0"

And what is the mask on that network, I am taking your using /22 vs /24? Have you set network size in fling to something other than /24? Fling by default scans the network it got assigned so if your saying you scanning 192.168.3 while on 192.168.0 am thinking your mask is /22 -- unless you over rode that in fling settings? You want a simple solution? Just change the networks so they are not next to each other. For example use 172.16-31.x.x for your other network segments or 10.x.x.x -- now even if they set fling to scan /8 --- if they are on 192.168.x.x never scan 172.31.14.0/24 ;) They would have to know that you have such a network or really long scans ;)

" But no system on 192.168.1.x / 192.168.2.x / 192.168.3.x network can connect to 192.168.0.0 n/w."

You have that the wrong way ;) That is the complete op of how you would normally set it up ;)

Your guest wireless network should not have access to anything and should be on its own segment, only thing guest should do is be able to use internet, and if you want specific servers on your other networks - limited to those specific IPs and those specific ports.

example - this is my HOME wireless segment rules

wirelessnetwork.png

So wireless clients can talk to my ntp server only for ntp. Then they can not talk to any of lan net. I have lan 192.168.1.0/24 and 192.168.3.0/24 is dmz. The not allows them to go to anything other, like internet but not my lan network. So they can talk to me dmz segment but not the lan segment.

But my local lan network can create traffic into the wireless..

"Well Clients need to be able to talk to it in some way shape or form...."

This is point here! If clients on your wifi need to talk to these services to actually do stuff like print, access files, etc. Then there is no real way to hide those services. Scanning for those - look under advanced on fling will how that server even if it doesn't answer simple ping.

#8 +theblazingangel

theblazingangel

    Software Engineer

  • Tech Issues Solved: 6
  • Joined: 25-March 04
  • Location: England, UK

Posted 05 August 2014 - 15:53

Why are you worrying about your servers showing up on simple scans like this?

>> Sometimes we give guest access for some users that work on temp basis.  We do not want them to use Fing and get idea out all the servers.  Because one of them is entry to production though it is secured via ssh auth. But still why to take chances. 

 

BTW, this is what the security chairman of our company wants us to implement.

 

Either you've misunderstood what exactly your security chairman wants you to implement, or he's incompetent.

 

Blocking ping scans is pointless, it's security through obscurity. It is not going to offer the security protection you need, it's just going to make network connectivity troubleshooting more difficult.

 

Hiding the servers from ping scans does not prevent communication with them via other protocols, and thus nor does it hide them from being discovered via scanning with these other protocols. For example, you say that the servers are running ssh for authentication, so what if I were to scan port 22 (ssh) across your network's entire IP range? I've just discovered all your servers (all those running ssh that is)! You can even do this yourself with fing, albeit only on one host at a time - press the cog icon top right to access the tools menu, under host tools select 'scan TCP services', and enter an IP address. fing also let's you configure the TCP services it scans for (tools > configuration > edit TCP services), the version I have here has a default list of 1027 services.

 

Fing of course isn't the only such scanning tool, what if one of your temp contractors were to connect their laptop to your network and run some other scanning tool that allows them to scan TCP services across a range of IP address, unlike fing allowing just one at a time. So what are you going to do about preventing the discovery of the servers via these other protocols?

 

Your attempt to enhance security by attempting to block discovery via blacklisting communication with pings is extremely weak and ineffective.

 

What you should be doing is segmenting your network (VLANS, which you've already got) and then implementing access controls, which is what your attempting, but you're going about completely wrong.

 

Here's how I would summarise your options, in terms of implementing layer3 access lists on your networking equipment (assuming you have equipment with such capabilities):

 

Quick definition of what I mean below by destination/source:

At destination = Access controls on the network equipment, at the point where the servers connect.

At source = Access controls on network equipment, at the point where clients connection to the network, or at the point where traffic is exiting the client's VLAN.

  • Blocking (blacklisting) pings at destination : WRONG - does not block other types of scanning or communication.
  • Blocking (blacklisting) pings at source : WRONG - does not block other types of scanning or communication.
  • Blocking (blacklisting) pings and other protocols/destination-ports like ssh at destination : WRONG - cuts off all communication making servers useless.
  • Blocking (blacklisting) pings and other protocols/destination-ports at destination, for traffic with source address in specific IP range : BETTER - though a whitelist is better than a blacklist, and it's imperfect because a malicious host could spoof the source IP address to get malicious packets through. Thus they could still DOS the server, or potentially exploit vulnerabilities where the malicious host being able to receive responses doesn't matter (e.g. a vulnerability in a server's database package that may allow random modification/corruption/deletion of data - the attacker may be satisfied with just screwing up the database as best as possible!).
  • Blocking (blacklisting) at source, pings and other protocols/destination-ports, destined for specific addresses/ranges : MUCH BETTER - now you're starting to properly cut off access to the servers from hosts you don't want to allow communication from.
  • Blocking at source, pings and other protocols/destination-ports, destined for specific addresses/ranges, by using a whitelist of stuff communications that are allowed : BEST - whitelists are generally preferable to blacklists.


#9 +BudMan

BudMan

    Neowinian Senior

  • Tech Issues Solved: 100
  • Joined: 04-July 02
  • Location: Schaumburg, IL
  • OS: Win7, Vista, 2k3, 2k8, XP, Linux, FreeBSD, OSX, etc. etc.

Posted 05 August 2014 - 16:49

^ good post!! And agree with whitelist, see in my simple example where I allow access to the 1 specific service I need, but block all other traffic to anything on that segment.

While you have stated your using vlans.. I have to ask because I have seen it many many times before, you sure your just not running different network address space over the same physical network? Using 192.168.1.0/22 for devices vs 192.168.2.0/22 for other devices or even /24 is not valid if they are over the same physical network. I ask this because from my use of fing - unless you went in and changed the range of scanning if your wireless client connected to 192.168.0.x/24 it would not scann anything on 192.168.1.0/24 or .2.0/24 or .3.0/24

#10 OP zoheb

zoheb

    Neowinian

  • Joined: 02-January 10
  • Location: haLLuNicaTeD pAradISe

Posted 06 August 2014 - 10:54

 unless you went in and changed the range of scanning if your wireless client connected to 192.168.0.x/24 it would not scan anything on 192.168.1.0/24 or .2.0/24 or .3.0/24 

>> This is what I did.

 

theblazingangel: Thanks a lot, I will be using either of the below option via Squid / apf FW.  

  • Blocking (blacklisting) at source, pings and other protocols/destination-ports, destined for specific addresses/ranges : MUCH BETTER - now you're starting to properly cut off access to the servers from hosts you don't want to allow communication from.
  • Blocking at source, pings and other protocols/destination-ports, destined for specific addresses/ranges, by using a whitelist of stuff communications that are allowed : BEST - whitelists are generally preferable to blacklists.


#11 +ChuckFinley

ChuckFinley

    member_id=28229

  • Joined: 14-May 03

Posted 06 August 2014 - 17:51

 

 unless you went in and changed the range of scanning if your wireless client connected to 192.168.0.x/24 it would not scan anything on 192.168.1.0/24 or .2.0/24 or .3.0/24 

>> This is what I did.

 

theblazingangel: Thanks a lot, I will be using either of the below option via Squid / apf FW.  

  • Blocking (blacklisting) at source, pings and other protocols/destination-ports, destined for specific addresses/ranges : MUCH BETTER - now you're starting to properly cut off access to the servers from hosts you don't want to allow communication from.
  • Blocking at source, pings and other protocols/destination-ports, destined for specific addresses/ranges, by using a whitelist of stuff communications that are allowed : BEST - whitelists are generally preferable to blacklists.

 

 

Yes but Pings are useful for diagnostics you know.... :)



#12 +theblazingangel

theblazingangel

    Software Engineer

  • Tech Issues Solved: 6
  • Joined: 25-March 04
  • Location: England, UK

Posted 06 August 2014 - 18:11

Yes but Pings are useful for diagnostics you know.... smile.png

 

Re-reading it, perhaps I could have written that last bullet point of mine a little clearer...

 

  • Blocking at source, all unwanted/unecessary communications, (e.g. blocking all communication with specific servers and or VLANs), by using a whitelist of communications that are allowed : BEST - whitelists are generally preferable to blacklists.


#13 +ChuckFinley

ChuckFinley

    member_id=28229

  • Joined: 14-May 03

Posted 07 August 2014 - 07:54

 

Re-reading it, perhaps I could have written that last bullet point of mine a little clearer...

 

  • Blocking at source, all unwanted/unecessary communications, (e.g. blocking all communication with specific servers and or VLANs), by using a whitelist of communications that are allowed : BEST - whitelists are generally preferable to blacklists.

 

 

 

Haha Woops sorry I wasn't talking to you I was talking to the OP.