This is a faq file for comp.security.misc and comp.security.unix. It is cross-posted to alt.security because I think it will also be useful there. Yes, I know that syntactically, these are not all "questions". Please check whether your question is in this file before posting. Also, unix-specific questions should be posted to comp.security.unix, not comp.security.misc; so if they're in here, there are now TWO reasons not to post them to comp.security.misc. New for August: the "what should I read" question. ------------------------------ Subject: Table of contents - This faq - Can anyone here tell me how to exploit the [whatever] bug? or Can anyone here tell me how to break in to my ISP? - What do the "identd" lines in my syslog mean? Is this a security exposure? Can I turn off identd? - I just noticed that [something]. Has my machine been compromised? - What does port number [whatever] mean? - Here's new, unbreakable encryption software. - What should I read to learn how to secure my computers? What should I read to learn about computer security? - Is there a newer version of cops? - Tripwire fails the self-test, dumps core when building the database, and dumps core when verifying. - Cops won't "make" in some versions of linux (GNU). - What's that weird URL with SATAN/SAINT? I'm not running a web server! or SATAN says "Can't find my own hostname". - SATAN doesn't display right in my web browser; it asks me to save the file. - How do I find all setuid and setgid files? - I can't get .rhosts/.shosts to work with ssh. (Note: there is a newsgroup comp.security.ssh) - Should I block all ICMP at my firewall/router? - How do I prevent my machine from announcing OS version, daemon version, etc in the banner message? - Is a portscan of a machine malicious/illegal/unfriendly? - Can my ISP/employer monitor [various things I'm doing]? ------------------------------ Subject: This faq This is not supposed to be a statement of group consensus. This is simply supposed to be a few VERY frequently asked questions and their answers, so that we can snidely say "see the faq" when people ask them. The answers supplied are supposed to be completely uncontroversial amongst people who know what they're talking about. (My first answer might be a bit borderline in this respect but I don't recall ever having seen a contrary opinion here.) Except for the portscan question, in which I've attempted to present ALL of the major views. Contributions of questions are welcome (with or without answers); however, the idea is that they are supposed to be things which have straightforward answers and which we see very frequently (at least prior to their inclusion in this document). If your answer is long, it might not belong in this document, at least as I see the purpose of this document. For example, it is intentional that this document doesn't contain firewall recommendations, even though that's a frequently-asked question here. (But see the firewall faq at http://www.clark.net/pub/mjr/pubs/fwfaq/) Thanks to Juan Gallego, Lamont Granquist, and Martin Ouwehand for additional suggestions re finding setuid files on different systems. Thanks to Dan Niles and Jyrki Havia for tripwire bug details as posted to the newsgroup. Thanks to Dan Farmer for making me aware of cops 1.04+ (cf 1.04). Also taken from the newsgroup are some words from Olaf Schreck about correctly editing the SATAN perl file (responding to a newbie error). Thanks to Scott Barman for a Windows NT security book reference. Disclaimer: The posting of this file is not to be construed as a commitment to provide free consulting to people I don't know. Post your questions to the newsgroup and I might answer them there, or someone else might do it better. (Although if you say "please send e-mail copies", I'm going to ignore your message.) Disclaimer 2: There ARE errors in this file, but at the time of writing, I didn't know what they were. (If I knew, I would have fixed them.) This document is offered on an "as-is" basis, no warranty is implied, blah blah blah. The metafaqs say you should choose a random day of the month to post monthly faqs on, so I just used random() and got the number 22 (I don't think it's necessary for it to be a cryptographic random number). ------------------------------ Subject: Can anyone here tell me how to exploit the [whatever] bug? or Can anyone here tell me how to break in to my ISP? No. We're security professionals. We try to secure systems. We think that securing systems and fixing bugs are more intellectual activities than running a program which someone else wrote which you don't understand. You should only attempt "penetration testing" of a system with the consent of its administrators and/or owners. They will only be interested in your services if you know something. You can start your education by learning some general computer science and computer programming, and by reading computer security textbooks and/or newsgroups. ------------------------------ Subject: What do the "identd" lines in my syslog mean? Is this a security exposure? Can I turn off identd? Discarding the timestamp and hostname, the lines look something like this: identd[10362]: from: 205.238.143.33 ( mail.dejanews.com ) for: 20546, 25 identd[10362]: Successful lookup: 20546 , 25 : flaps.users This states that the machine 205.238.143.33 asked your machine who was connecting from port 20546 on your machine to port 25 on 205.238.143.33. And your machine responded that the user was "flaps", and that flaps's group is "users". (10362 is the process id number of this particular invocation of identd; for example, if two identd requests happened at about the same time and the two lines were interleaved, it would help you sort them out.) Theoretically, this is a security-sensitive data exposure, although the practical effect of this is arguably nil. And it can be very helpful to the admin of a machine which often has more than a few simultaneous users. When one of your users does something untoward, this allows the remote machine to log the username, and then the remote sysadmin's complaint to you will contain information useful to you. A linux machine at home connected to the internet via ppp and with only one user should not be running identd because it does not contribute to this process. Very few things on the net REQUIRE the sender to be running identd, because many machines don't have it and because many people turn it off. Your identd program probably has various options to configure what information it discloses; see the man page. You might want to run it with options to minimize data OTHER than the above (-o and -e in the common implementation), and/or perhaps run it with the option to report numeric uids rather than lognames (-n), which is just as useful for tracking down offenders from your point of view. On the other hand, if you report numeric uids, then in some cases the remote people will be able to gain logname<->uid translation info (e.g. the outgoing connection is a mail message bearing 'from' information), so it's hard to say which discloses less data. If you feel that this data is sensitive but still want to run identd, there are some identd servers out there which report the data encrypted, so that all the target sysadmins can do with the information they get is to send the token back to you for your own use. This facility might be available as -C. You specify these options on the identd command-line, wherever it appears, which is usually in /etc/inetd.conf. The identd protocol is documented in RFC 1413. It is the same as "auth". The query specifies the port numbers only; the two IP addresses are the sender and target of the identd query. Thus you cannot query about IP connections to other machines, although you can query about connections which don't concern you but are to a machine you have an account on. RFC 1413 states, "If you wouldn't run a 'finger' server due to privacy considerations you may not want to run this protocol." I agree with this but suggest that it might not apply to a cryptographic identd (e.g. -C). ------------------------------ Subject: I just noticed that [something]. Has my machine been compromised? Maybe. You probably don't know whether it always was like this. You should look around your system enough of the time that you get used to how things look BEFORE you get broken into. And you should make a practice of following up oddities you find, so that your judgement as to what is and is not weird improves with experience. If it's too late for that, before posting to comp.security.* ask at least one local expert in the OS you're running, or in the case of unix, one local unix expert. There may be a straightforward, happy explanation for the behaviour you observe. Or there may not. Not all anomalies are the result of an intrusion; to some extent "My machine has been broken into!" has replaced the "I have a virus!" default explanation of a few years ago. On the other hand, machine breakins are very common these days, too. ------------------------------ Subject: What does port number [whatever] mean? The basic reference is RFC 1700, or ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers However, you can write a program which uses any port number, whether it has a standard meaning or not; and similarly you can write a program which uses a port number in a way contrary to its standard meaning. If you notice an attempted connection to a weird port number on your machine, the connection might have been meant for some other machine running an idiosyncratic service (perhaps someone typoed the IP address or hostname), it might be a probe for a widely-spread trojan horse program, it might be part of some kind of portscan, or plenty of other possibilities. If you notice your machine listening on an unexpected port, you may have been broken into, or it may be a "feature" of your OS distribution or some third-party software you're running. In unix, most ports your OS distribution will use will be listed in /etc/services, along with MANY you don't use. /etc/inetd.conf lists services whose daemons are started on demand by inetd, the internet "super-server" (see the man page). In different ways depending on OS version, /etc/rc* specifies some standalone daemons to be started up on boot (or initlevel change); see man pages (including man init). These are conventional ways to start services but any program can listen on a port (unprivileged processes can only listen on port numbers >=1024 in most multiuser OSes). Some port numbers are not fixed. There are several possibilities here, but in unix these most notably include port numbers bearing services registered under the "portmapper", which listens on port 111. Type "rpcinfo -p yourmachine" for a list of services for which the portmapper is serving as a directory. (Some of these port numbers may in fact be fixed, in which case client programs have two different ways to find the port number (hardcode the port number or use the portmapper).) To see what listeners you have running (open ports), the canonical incantation is "netstat -an". But doing a portscan from a remote machine might be more reliable if you suspect your machine has been compromised, because the netstat program could have been replaced. To find out what process is doing the listening, try something like lsof. Again, once your machine has been compromised, this might report the wrong answer; the purpose of using lsof would be to investigate the normal behaviour of your machine, not to check whether it's been compromised. ------------------------------ Subject: Here's new, unbreakable encryption software. It's probably not substantially new, and I'm sure it's not unbreakable. Read the snake oil FAQ at http://www.interhack.net/people/cmcurtin/snake-oil-faq.html ------------------------------ Subject: What should I read to learn how to secure my computers? What should I read to learn about computer security? The number one thing to do is to install all of your vendor's security patches and to disable unused services (in unix, comment things out of /etc/inetd.conf, and remove daemon invocations from /etc/rc* (details depend on OS version)). See some other basic information in ftp://ftp.cert.org/pub/tech_tips/UNIX_configuration_guidelines Subscribe to the CERT advisory list and to your vendor's security alert list to keep current in future. If you're trying to learn your way around unix and internet security in general, I suggest you want to start with a good grasp of unix basics, e.g. from the Kernighan & Pike book. You'll also want to be strong in C, which education you can begin with the Kernighan & Ritchie book. (Of course there are alternatives to both.) If you're feeling strong after that and want to go for the details, read Farmer & Venema's "Improving the Security of Your Site by Breaking Into it" at http://www.fish.com/security/admin-guide-to-cracking.html , and the Cheswick & Bellovin firewalls book. For a gentler approach covering a broader range of security issues, read Spafford & Garfinkel's "Practical Unix and Internet Security". A more hands-on-oriented book about firewalls is Chapman & Zwicky. If you're interested in cryptography, the canonical book is Schneier's "Applied Cryptography", and you might be interested in RFC 1750. I've received a recommendation for "Windows NT Security" by Rutstein. Some URLs with security notes for particular systems (in addition to those above, and don't forget your vendor's security patch list): Linux security: http://metalab.unc.edu/LDP/HOWTO/Security-HOWTO.html Irix (out of date but contains notes which are still important): ftp://rtfm.mit.edu/pub/faqs/sgi/faq/security Improve assorted file permissions for solaris 2.2 through 2.6, changing the pkg database to match: ftp://ftp.fwi.uva.nl/pub/solaris/fix-modes.tar.gz Solaris security: http://www.sunworld.com/common/security-faq.html Unix versus Windows NT: http://www.unix-vs-nt.org (Canonical URLs for additional platforms solicited! Non-vendor URLs preferred.) ------------------------------ Subject: Is there a newer version of cops? No. Version 1.04+ is a bit old but performs some functions which are still as useful as they ever were. (And the message "/usr/lib/sendmail could have a hole/bug!" is still right although the cert advisory quoted could be changed.) (1.04+ contains an assortment of minor fixes and enhancements to 1.04, and was released in 1993 by the original author (Dan Farmer).) ------------------------------ Subject: Tripwire fails the self-test, dumps core when building the database, and dumps core when verifying. Fails the self-test (on fast machines): You have to slow it down (just the self-test scripts, not the tripwire binary itself). The test scripts create and then update a file, and then fail to detect that the timestamp has changed. But this is ok, because the timestamp has indeed not changed, because this all happens within a second on some modern machines. This occurs in a few places in the test scripts. If a second-boundary happens to be crossed during this brief interval, then that particular test will succeed, but another one might fail soon. In the tests directory, edit 3 of the 4 files named test.*.sh: in test.escape.sh, add "sleep 1" on line 46 (in the cert version), just before running tripwire; in inter and update, un-comment-out the "sleep 1". If this isn't good enough (obscure but can happen), use "sleep 2". See ftp://coast.cs.purdue.edu/pub/COAST/Tripwire/README-third Dumps core when building the database (if you have 8-bit chars in filenames): Tripwire 1.2 contains a bug relating to octal printing of 8-bit chars in file names. The bug occurs in filename_escape() in src/utils.c. Double the size of the "octal_array" to contain all 256 possible entries, and change octal_array[(int)(*pcin)] to octal_array[*pcin & 255] farther down. (This only works if you have eight-bit bytes, of course, but most of us do.) Dumps core when verifying (this bug surfaces on some systems only): In config.parse.c just before the end of configfile_read(), on line 356 in the tripwire 1.2 distribution, there is a "rewind(fpout);". It should be conditional on "specified_configmode" as in the previous 'if' statement: at this point the values "fpin" and "fpout" are the same (see line 184), so it is actually rewinding the fp it might have closed in the previous line. So simply add the word "else" before the "rewind". (Perhaps change "fpout" to "fpin" for clarity, although this won't affect its behaviour.) ------------------------------ Subject: Cops won't "make" in some versions of linux (GNU). Remove the '#' from "BRAINDEADFLAGS" in the makefile. (This adds a "-lcrypt" to the compilation of pass.c.) ------------------------------ Subject: What's that weird URL with SATAN/SAINT? I'm not running a web server! or SATAN says "Can't find my own hostname". SATAN acts as a web server so that it can use HTML conveniently. The main thing it gets out of HTML is its hypertext capabilities (you can click on stuff). The web browser communicates with it using the HTTP protocol. This allows it to generate responses to queries dynamically, rather than having to generate a huge number of static files (to be accessed via file://). It includes a cryptographic random number at the beginning of the URL so that others can't contact your copy of SATAN and retrieve the information it's supplying. If SATAN claims it "can't find my own hostname" or if the web browser can't resolve your hostname in the URL, try adding your hostname to /etc/hosts. You can list multiple hostnames for a given IP address in /etc/hosts; among them should be the output from the "hostname" command and also your fully-qualified domain name ("myname.dept.organization.org" rather than "myname" or "myname.dept"). ------------------------------ Subject: SATAN doesn't display right in my web browser; it asks me to save the file. Newer web browsers seem to use different algorithms in guessing mime types when the web server doesn't supply them. Anyway, web servers are supposed to supply the correct mime type and it's easy to fix SATAN to do so. Add, in perl/html.pl, in process_html_request before it sends anything (actually I see I put it just before the "Make sure they gave us the right magic number"): # # ajr addition # print CLIENT <