Top Document: comp.security.unix and comp.security.misc frequently asked questions Previous Document: How do I recover from forgetting my root password? (Similarly: I messed up the root line in /etc/passwd and can't su or login as Next Document: Can my ISP/employer monitor [various things I'm doing]? See reader questions & answers on this topic! - Help others by sharing your knowledge This is included here because it's a recurring flamefest. Please avoid simply repeating the same old basic statements, because we've heard 'em all. First of all, what a portscan is: Basically (there are myriad variants), it's an attempted connection to every single port number on a given machine or range of machines. Suppose you want to break in to a particular machine. First thing you might do is to run a port-scanner to find out what all the "open ports" are (ports with a listener). Then you see, aha there's an imapd, let's try the imapd exploit program. Rather than just trying all sorts of programs which wouldn't even connect let alone break in. Portscanning your own machine is valuable; you may find listeners you didn't know were there, and then you can close them off and/or check their security. Since you have to secure each service on its own anyway, some people argue that there's no need to defend against portscanning itself. On the other hand, you might configure your system to page you, or delete all your files, or perform some such useful action when it detects a port-scanning in progress. Some defense systems cease accepting connections of any kind from that IP address when they detect a portscan, and some sysadmins write to your ISP and try to get you kicked off. This leads to "stealth port-scanners" which try to avoid triggering the alarms by various means. Some people argue that there's not too much in the way of useful action you can take automatically when you detect a port-scanning in progress, and "counterattack" software is unwise and can be used via forgery to launch attacks from your machine. Now, the basic portscanning arguments. (The discussion is only about machines you don't admin, obviously; there is an additional, finer dispute about the situation with machines you have some legitimate association with but not as sysadmin, but I don't propose to address that intermediate situation here.) I might be willing to add other statements to this list if they're similarly terse, and certainly do let me know if you feel I've inadequately represented a viewpoint, except that I reserve the right to apply a sense of humour. Portscanning has been argued to be malicious/illegal/satanic because (see rebuttals in subsequent section): - a portscan is always/usually a prelude to or part of an attack, like testing doorknobs to see if they're unlocked - my pager beeps when I get portscanned, which takes my time unfairly (aka my machine crashes, sends lots of e-mail, changes the root password to "soup") - if everyone portscans a few machines for fun, in total there will be a constant barrage of portscans to all/many/some machines, overloading them - an attempt to commit a criminal offence is itself a criminal offence - portscanning someone ELSE's machine is a completely different matter than portscanning one's own - a stealth portscan shows criminal intent even if you argue that a traditional portscan does not - any connection to a machine you're not explicitly authorized to use constitutes the criminal offence of unauthorized access to a computer (i.e. it's already a breakin) - various lame analogies Portscanning has been argued to be innocent/salutory/pure because (see rebuttals in previous section): - the "hands-on imperative": people should be curious, people should explore, people should think - a portscan uses a negligible amount of resources on the target machine - if a portscan is a prelude to an attack, the ATTACK is what's wrong; the portscan is not wrong, and is not usually a prelude to an attack anyway - legally, "mere preparation" does not constitute an attempt - having a listener on a port solicits connections; you can't complain that someone makes the connection to the advertised port; port numbers are "well-known" for a reason - if a portscan crashes your system, it's crappy anyway; if your pager beeps when you get portscanned, that's a stupid configuration - if your machine is connected to the internet, it's your job as sysadmin to deal with network activity and you shouldn't complain if you don't like it - various lame analogies NOTE! The above two sections are a pair. Don't cite a point from one section in your favour without examining its rebuttal in the other section! I am not attempting to resolve this issue here, just to decrease repetition. Note re analogies: Analogies are a good way to express a point of view but usually the attempt to draw conclusions from them is essentially circular. I recommend using an analogy to express views but not to argue. Example of a useful analogy: "Looking through someone's protected files without their permission is like looking through their desk drawers." Very connotative; conveys concepts of reasonable expectations of privacy despite organizational ownership of the infrastructure; shows what the speaker thinks some of the fundamental issues are; but note it's still not a proof of anything. Example of a useless analogy: "Portscanning isn't like trying to turn the doorknob, it's like looking at the doorknob while passing by on the street." Conveys no information other than "I think portscanning is ok". Neither is an argument, but one of them gives a wealth of information as to the basic perspective of the speaker and the other is useless. User Contributions:Top Document: comp.security.unix and comp.security.misc frequently asked questions Previous Document: How do I recover from forgetting my root password? (Similarly: I messed up the root line in /etc/passwd and can't su or login as Next Document: Can my ISP/employer monitor [various things I'm doing]? Single Page [ Usenet FAQs | Web FAQs | Documents | RFC Index ] Send corrections/additions to the FAQ Maintainer: flaps@dgp.toronto.edu (Alan J Rosenthal)
Last Update March 27 2014 @ 02:11 PM
|
Comment about this article, ask questions, or add new information about this topic: