Re: "portscans" (was Re: Arbor Networks DoS defense product)
Scott Francis <darkuncle@darkuncle.net> writes: [...]
And why, pray tell, would some unknown and unaffiliated person be scanning my network to gather information or run recon if they were not planning on attacking? I'm not saying that you're not right, I'm just saying that so far I have heard no valid non-attack reasons for portscans (other than those run by network admins against their own networks).
Before choosing an onling bank, I portscanned the networks of the banks I was considering. It was the only way I could find to get a rough assessment of their network security, which was important to me as a customer for obvious reasons. I'm not sure if I would have been impressed or annoyed if they had stopped accepting packets from my machine during the scan. :-) -----ScottG.
On Sat, May 18, 2002 at 09:43:16PM -0400, sgifford@suspectclass.com said: [snip]
network to gather information or run recon if they were not planning on attacking? I'm not saying that you're not right, I'm just saying that so far I have heard no valid non-attack reasons for portscans (other than those run by network admins against their own networks).
Before choosing an onling bank, I portscanned the networks of the banks I was considering. It was the only way I could find to get a rough assessment of their network security, which was important to me as a customer for obvious reasons.
In that case, I would not consider the scan to have come from an 'unaffiliated' person. I'm sure if the bank's network operator noticed it, and contacted you, things would have been cleared up with no harm done. To make it a bit more clear: cases where the scanner can demonstrate a good and benign reason for scanning (they do occasionally exist[1]), no blackhole is required. Sending an email notification prior to putting in a blackhole is a good first step to eliminate potential false positives. [1] Random strangers unaffiliated with your network will almost never have a valid & benign reason for portscanning you.
I'm not sure if I would have been impressed or annoyed if they had stopped accepting packets from my machine during the scan. :-)
Loss of a customer, probably. :) -- Scott Francis darkuncle@ [home:] d a r k u n c l e . n e t Systems/Network Manager sfrancis@ [work:] t o n o s . c o m GPG public key 0xCB33CCA7 illum oportet crescere me autem minui
rough assessment of their network security, which was important to me as a customer for obvious reasons.
In that case, I would not consider the scan to have come from an 'unaffiliated' person. I'm sure if the bank's network operator noticed it, and contacted you, things would have been cleared up with no harm done. To
It sounds like you know something that I don't. How do you find out the contact information for someone given only an IP address? -Ralph
helium:~$ whois -a 207.99.113.65 Net Access Corporation (NETBLK-NAC-NETBLK01) 1719b Route 10E, Suite 111 Parsippany, NJ 07054 US Netname: NAC-NETBLK01 Netblock: 207.99.0.0 - 207.99.127.255 Maintainer: NAC Coordinator: Net Access Corporation (ZN77-ARIN) legal@nac.net 800-638-6336 Domain System inverse mapping provided by: NS1.NAC.NET 207.99.0.1 NS2.NAC.NET 207.99.0.2 ADDRESSES WITHIN THIS BLOCK ARE NON-PORTABLE * Reassignment information for this network is available * at whois.nac.net 43 On Sun, 19 May 2002, Ralph Doncaster wrote:
rough assessment of their network security, which was important to me as a customer for obvious reasons.
In that case, I would not consider the scan to have come from an 'unaffiliated' person. I'm sure if the bank's network operator noticed it, and contacted you, things would have been cleared up with no harm done. To
It sounds like you know something that I don't. How do you find out the contact information for someone given only an IP address?
-Ralph
-- Alex Rubenstein, AR97, K2AHR, alex@nac.net, latency, Al Reuben -- -- Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
We maintain most comprehensive whois recursive engine tool at completwhois.com So you could also try this and get more info :) [support@sokol support]$ whois -h completewhois.com 207.99.113.65 [completewhois.com] [whois.arin.net] Net Access Corporation (NETBLK-NAC-NETBLK01) 1719b Route 10E, Suite 111 Parsippany, NJ 07054 US Netname: NAC-NETBLK01 Netblock: 207.99.0.0 - 207.99.127.255 Maintainer: NAC Coordinator: Net Access Corporation (ZN77-ARIN) legal@nac.net 800-638-6336 Domain System inverse mapping provided by: NS1.NAC.NET 207.99.0.1 NS2.NAC.NET 207.99.0.2 ADDRESSES WITHIN THIS BLOCK ARE NON-PORTABLE * Reassignment information for this network is available * at whois.nac.net 43 Record last updated on 22-Aug-2001. Database last updated on 18-May-2002 19:58:45 EDT. The ARIN Registration Services Host contains ONLY Internet Network Information: Networks, ASN's, and related POC's. Please use the whois server at rs.internic.net for DOMAIN related Information and whois.nic.mil for NIPRNET Information. [WHOIS.NAC.NET] NAC-Rwhoisd32 Server Ready - [silver/43] Rwhoisd32 v1.0.36 Net Access Corp. (NETBLK-NET-CF637140-28) PO Box 55 Denville, NJ 07834 USA Netname : NET-CF637140-28 Netblock: 207.99.113.64/28 Coordinator: Rubenstein, Alex network@nac.net Database updated instantaneously. This Registration Services Host contains ONLY Net Access Corporation Network Information. Please use the whois server at whois.arin.net for networks not found here. On Sun, 19 May 2002, Alex Rubenstein wrote:
helium:~$ whois -a 207.99.113.65 Net Access Corporation (NETBLK-NAC-NETBLK01) 1719b Route 10E, Suite 111 Parsippany, NJ 07054 US
Netname: NAC-NETBLK01 Netblock: 207.99.0.0 - 207.99.127.255 Maintainer: NAC
Coordinator: Net Access Corporation (ZN77-ARIN) legal@nac.net 800-638-6336
Domain System inverse mapping provided by:
NS1.NAC.NET 207.99.0.1 NS2.NAC.NET 207.99.0.2
ADDRESSES WITHIN THIS BLOCK ARE NON-PORTABLE
* Reassignment information for this network is available * at whois.nac.net 43
On Sun, 19 May 2002, Ralph Doncaster wrote:
rough assessment of their network security, which was important to me as a customer for obvious reasons.
In that case, I would not consider the scan to have come from an 'unaffiliated' person. I'm sure if the bank's network operator noticed it, and contacted you, things would have been cleared up with no harm done. To
It sounds like you know something that I don't. How do you find out the contact information for someone given only an IP address?
-Ralph
-- Alex Rubenstein, AR97, K2AHR, alex@nac.net, latency, Al Reuben -- -- Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
That's a netblock, not an IP address. Your script kiddie at home with a cable modem or ADSL connection is not going to have his IP SWIP'd or populated in his ISP's rwhois server. Try that with 206.47.27.12 for instance. That is a Sympatico ADSL customer here in Ottawa. Ralph Doncaster principal, IStop.com div. of Doncaster Consulting Inc. On Sun, 19 May 2002, Alex Rubenstein wrote:
helium:~$ whois -a 207.99.113.65 Net Access Corporation (NETBLK-NAC-NETBLK01) 1719b Route 10E, Suite 111 Parsippany, NJ 07054 US
Netname: NAC-NETBLK01 Netblock: 207.99.0.0 - 207.99.127.255 Maintainer: NAC
Coordinator: Net Access Corporation (ZN77-ARIN) legal@nac.net 800-638-6336
Domain System inverse mapping provided by:
NS1.NAC.NET 207.99.0.1 NS2.NAC.NET 207.99.0.2
ADDRESSES WITHIN THIS BLOCK ARE NON-PORTABLE
* Reassignment information for this network is available * at whois.nac.net 43
On Sun, 19 May 2002, Ralph Doncaster wrote:
rough assessment of their network security, which was important to me as a customer for obvious reasons.
In that case, I would not consider the scan to have come from an 'unaffiliated' person. I'm sure if the bank's network operator noticed it, and contacted you, things would have been cleared up with no harm done. To
It sounds like you know something that I don't. How do you find out the contact information for someone given only an IP address?
-Ralph
-- Alex Rubenstein, AR97, K2AHR, alex@nac.net, latency, Al Reuben -- -- Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
On Sun, May 19, 2002 at 10:03:08AM -0400, ralph@istop.com said:
rough assessment of their network security, which was important to me as a customer for obvious reasons.
In that case, I would not consider the scan to have come from an 'unaffiliated' person. I'm sure if the bank's network operator noticed it, and contacted you, things would have been cleared up with no harm done. To
It sounds like you know something that I don't. How do you find out the contact information for someone given only an IP address?
You know the contact information for the block that the scan originated from. From there, it's detective work (if the admin of the block in question cooperates, hopefully not too much). -- Scott Francis darkuncle@ [home:] d a r k u n c l e . n e t Systems/Network Manager sfrancis@ [work:] t o n o s . c o m GPG public key 0xCB33CCA7 illum oportet crescere me autem minui
On 18 May 2002, Scott Gifford wrote:
Scott Francis <darkuncle@darkuncle.net> writes:
[...]
And why, pray tell, would some unknown and unaffiliated person be scanning my network to gather information or run recon if they were not planning on attacking? I'm not saying that you're not right, I'm just saying that so far I have heard no valid non-attack reasons for portscans (other than those run by network admins against their own networks).
Before choosing an onling bank, I portscanned the networks of the banks I was considering. It was the only way I could find to get a rough assessment of their network security, which was important to me as a customer for obvious reasons.
I would argue that this is not good practice and you dont have the right to intrude on the workings of the banks network just because you have the technology to do so.. if a telnet port was open would you also check that you were unable to brute force your way in? That is to say.. what exactly were you hoping to find and then do with the results? I'd also say your reason for this is void, its not your responsibility to assess the bank's security. If they screw up they have insurance and you're not at risk.
I'm not sure if I would have been impressed or annoyed if they had stopped accepting packets from my machine during the scan. :-)
But surely if all their prospects do this they will not be able to handle the volume of attacks and will be unable to keep up with blocking the more minor benign scans. And you as a customer ought to prefer their time is spent on legitimate attacks which means no one scans then 'for good reasons' and all scans are therefore malicious and worthy of investigating... Steve
-----ScottG.
On 18 May 2002, Scott Gifford wrote:
Before choosing an onling bank, I portscanned the networks of the banks I was considering. It was the only way I could find to get a rough assessment of their network security, which was important to me as a customer for obvious reasons.
So for your offline banks, do you also go to the local branches at night and jiggle all the locks to make sure their doors and windows are locked? -Dan -- [-] Omae no subete no kichi wa ore no mono da. [-]
[ On Sunday, May 19, 2002 at 03:16:28 (-0700), Dan Hollis wrote: ]
Subject: Re: "portscans" (was Re: Arbor Networks DoS defense product)
On 18 May 2002, Scott Gifford wrote:
Before choosing an onling bank, I portscanned the networks of the banks I was considering. It was the only way I could find to get a rough assessment of their network security, which was important to me as a customer for obvious reasons.
So for your offline banks, do you also go to the local branches at night and jiggle all the locks to make sure their doors and windows are locked?
That analogy is fundamentaly flawed. For one the Interent is never locked after hours -- there is no "after hours", it's always open! There are also no sign posts at every router on the Internet. The only sign-posts are the responses you get from trying a given door -- either it opens or it doesn't. Unless you actually try to go somewhere in TCP/IP-land you won't know whether or not you can get there. A good firewall makes it appear for all intents and purposes that there's no door handle to wiggle in the first place. -- Greg A. Woods +1 416 218-0098; <gwoods@acm.org>; <g.a.woods@ieee.org>; <woods@robohack.ca> Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>
participants (8)
-
Alex Rubenstein -
Dan Hollis -
Ralph Doncaster -
Scott Francis -
Scott Gifford -
Stephen J. Wilcox -
william＠elan.net -
woods＠weird.com