Port List-over 1000 services identified

Service names and port numbers are used to distinguish between different
services that run over transport protocols such as TCP, UDP, DCCP, and
SCTP.

Service names are assigned on a first-come, first-served process, as
documented in [RFC6335].

Port numbers are assigned in various ways, based on three ranges: System
Ports (0-1023), User Ports (1024-49151), and the Dynamic and/or Private
Ports (49152-65535); the difference uses of these ranges is described in
[RFC6335]. System Ports are assigned by IETF
process for standards-track protocols, as per [RFC6335].  User Ports
are assigned by IANA using the "IETF Review" process, the "IESG 
Approval" process, or the "Expert Review" process, as per
[RFC6335].  Dynamic Ports are not assigned.

The registration procedures for service names and port numbers are
described in [RFC6335].

Assigned ports both System and User ports SHOULD NOT be used without
or prior to IANA registration.

************************************************************************
* PLEASE NOTE THE FOLLOWING:                                           *
*                                                                      *
* ASSIGNMENT OF A PORT NUMBER DOES NOT IN ANY WAY IMPLY AN             *
* ENDORSEMENT OF AN APPLICATION OR PRODUCT, AND THE FACT THAT NETWORK  *
* TRAFFIC IS FLOWING TO OR FROM A REGISTERED PORT DOES NOT MEAN THAT   *
* IT IS "GOOD" TRAFFIC, NOR THAT IT NECESSARILY CORRESPONDS TO THE     *
* ASSIGNED SERVICE. FIREWALL AND SYSTEM ADMINISTRATORS SHOULD          *
* CHOOSE HOW TO CONFIGURE THEIR SYSTEMS BASED ON THEIR KNOWLEDGE OF    *
* THE TRAFFIC IN QUESTION, NOT WHETHER THERE IS A PORT NUMBER          *
* REGISTERED OR NOT.                                                   *

Port     TCP     UDP     Description     Status

0         UDP     Reserved     Official


1     TCP     UDP     TCP Port Service Multiplexer (TCPMUX)     Official

2     TCP     UDP     CompressNET Management Utility     Official


3     TCP     UDP     CompressNET Compression Process     Official

4     TCP     UDP     Unassigned     Official

5     TCP     UDP     Remote Job Entry     Official

7     TCP     UDP     Echo Protocol     Official

8     TCP     UDP     Unassigned     Official

9     TCP     UDP     Discard Protocol     Official

10     TCP     UDP     Unassigned     Official

11     TCP     UDP     Active Users (systat service)     Official

12     TCP     UDP     Unassigned     Official

13     TCP     UDP     Daytime Protocol (RFC 867)     Official

14     TCP     UDP     Unassigned     Official

15     TCP     UDP     Previously netstat service     Unofficial

16     TCP     UDP     Unassigned     Official

17     TCP     UDP     Quote of the Day     Official

18     TCP     UDP     Message Send Protocol     Official

19     TCP     UDP     Character Generator Protocol (CHARGEN)     Official

20     TCP         FTP—data transfer     Official

21     TCP         FTP—control (command)     Official

22     TCP     UDP     Secure Shell (SSH)—used for secure logins, file transfers (scp, sftp) and port forwarding     Official

23     TCP         Telnet protocol—unencrypted text communications     Official

24     TCP     UDP     Priv-mail : any private mail system.[citation needed]     Official

25     TCP         Simple Mail Transfer Protocol (SMTP)—used for e-mail routing between mail servers     Official

26     TCP     UDP     Unassigned     Official

27     TCP     UDP     NSW User System FE
    Official

29     TCP     UDP     MSG ICP
    Official

33     TCP     UDP     Display Support Protocol
    Official

34     TCP     UDP     Remote File (RF)—used to transfer files between machines
    Unofficial

35     TCP     UDP     Any private printer server protocol
    Official

37     TCP     UDP     TIME protocol     Official

39     TCP     UDP     Resource Location Protocol (RLP)—used for determining the location of higher level services from hosts on a network     Official

40     TCP     UDP     Unassigned     Official

42     TCP     UDP     ARPA Host Name Server Protocol     Official

42     TCP     UDP     Windows Internet Name Service     Unofficial

43     TCP         WHOIS protocol     Official

47     TCP     UDP     NI FTP     Official

49     TCP     UDP     TACACS Login Host protocol
    Official

50     TCP     UDP     Remote Mail Checking Protocol     Official

51     TCP     UDP     IMP Logical Address Maintenance
    Official

52     TCP     UDP     XNS (Xerox Network Systems) Time Protocol     Official

53     TCP     UDP     Domain Name System (DNS)     Official

54     TCP     UDP     XNS (Xerox Network Systems) Clearinghouse     Official

55     TCP     UDP     ISI Graphics Language (ISI-GL)
    Official

56     TCP     UDP     XNS (Xerox Network Systems) Authentication     Official

56     TCP     UDP     Route Access Protocol (RAP)     Unofficial

57     TCP         Mail Transfer Protocol (RFC 780)     Unofficial

58     TCP     UDP     XNS (Xerox Network Systems) Mail     Official

67         UDP     Bootstrap Protocol (BOOTP) Server; also used by Dynamic Host Configuration Protocol (DHCP)     Official

68         UDP     Bootstrap Protocol (BOOTP) Client; also used by Dynamic Host Configuration Protocol (DHCP)     Official

69         UDP     Trivial File Transfer Protocol (TFTP)     Official

70     TCP         Gopher protocol     Official

71     TCP         NETRJS protocol     Official

72     TCP         NETRJS protocol     Official

73     TCP         NETRJS protocol     Official

74     TCP         NETRJS protocol     Official

79     TCP         Finger protocol     Official

80     TCP     UDP     Hypertext Transfer Protocol (HTTP)     Official

81     TCP         Torpark—Onion routing     Unofficial

82         UDP     Torpark—Control     Unofficial

88     TCP     UDP     Kerberos—authentication system
    Official

90     TCP     UDP     dnsix (DoD Network Security for Information Exchange) Securit Attribute Token Map
    Official

90     TCP     UDP     Pointcast     Unofficial

99     TCP         WIP Message protocol     Unofficial

101     TCP         NIC host name     Official

102     TCP         ISO-TSAP (Transport Service Access Point) Class 0 protocol     Official

104     TCP     UDP     ACR/NEMA Digital Imaging and Communications in Medicine     Official

105     TCP     UDP     CCSO Nameserver Protocol (Qi/Ph)     Official

107     TCP         Remote TELNET Service protocol     Official

108     TCP     UDP     SNA Gateway Access Server      Official

109     TCP         Post Office Protocol v2 (POP2)     Official

110     TCP         Post Office Protocol v3 (POP3)     Official

111     TCP     UDP     ONC RPC (SunRPC)     Official

113     TCP         ident—Authentication Service/Identification Protocol, used by IRC servers to identify users     Official

113         UDP     Authentication Service (auth)     Official

115     TCP         Simple File Transfer Protocol (SFTP)     Official

117     TCP         UUCP Path Service     Official

118     TCP     UDP     SQL (Structured Query Language) Services     Official

119     TCP         Network News Transfer Protocol (NNTP)—retrieval of newsgroup messages     Official

123         UDP     Network Time Protocol (NTP)—used for time synchronization     Official

135     TCP     UDP     DCE endpoint resolution     Official

135     TCP     UDP     Microsoft EPMAP (End Point Mapper), also known as DCE/RPC Locator service, used to remotely manage services including DHCP server, DNS server and WINS. Also used by DCOM     Unofficial

137     TCP     UDP     NetBIOS NetBIOS Name Service     Official

138     TCP     UDP     NetBIOS NetBIOS Datagram Service     Official

139     TCP     UDP     NetBIOS NetBIOS Session Service     Official

143     TCP         Internet Message Access Protocol (IMAP)—management of email messages     Official

152     TCP     UDP     Background File Transfer Program (BFTP)     Official

153     TCP     UDP     SGMP, Simple Gateway Monitoring Protocol     Official

156     TCP     UDP     SQL Service     Official

158     TCP     UDP     DMSP, Distributed Mail Service Protocol     Unofficial

161         UDP     Simple Network Management Protocol (SNMP)     Official

162     TCP     UDP     Simple Network Management Protocol Trap (SNMPTRAP)     Official

170     TCP         Print-srv, Network PostScript[citation needed]     Official

175     TCP         VMNET (IBM z/VM, z/OS & z/VSE - Network Job Entry(NJE))[citation needed]     Official

177     TCP     UDP     X Display Manager Control Protocol (XDMCP)     Official

179     TCP         BGP (Border Gateway Protocol)     Official

194     TCP     UDP     Internet Relay Chat (IRC)     Official

199     TCP     UDP     SMUX, SNMP Unix Multiplexer     Official

201     TCP     UDP     AppleTalk Routing Maintenance     Official

209     TCP     UDP     The Quick Mail Transfer Protocol     Official

210     TCP     UDP     ANSI Z39.50     Official

213     TCP     UDP     Internetwork Packet Exchange (IPX)     Official

218     TCP     UDP     Message posting protocol (MPP)     Official

220     TCP     UDP     Internet Message Access Protocol (IMAP), version 3     Official

256     TCP     UDP     2DEV "2SP" Port
    Unofficial

259     TCP     UDP     ESRO, Efficient Short Remote Operations
    Official

264     TCP     UDP     BGMP, Border Gateway Multicast Protocol     Official

280     TCP     UDP     http-mgmt     Official

308     TCP         Novastor Online Backup     Official

311     TCP         Mac OS X Server Admin (official
ly AppleShare IP Web administration)
    Official

318     TCP     UDP     PKIX TSP, Time Stamp Protocol     Official

319         UDP     Precision time protocol event messages     Official

320         UDP     Precision time protocol general messages     Official

323     TCP     UDP     IMMP, Internet Message Mapping Protocol
    Unofficial

350     TCP     UDP     MATIP-Type A, Mapping of Airline Traffic over Internet Protocol
    Official

351     TCP     UDP     MATIP-Type B, Mapping of Airline Traffic over Internet Protocol
    Official

366     TCP     UDP     ODMR, On-Demand Mail Relay
    Official

369     TCP     UDP     Rpc2portmap
    Official

370     TCP         codaauth2—Coda authentication server
    Official

370         UDP     codaauth2—Coda authentication server
    Official

370         UDP     securecast1—Outgoing packets to NAI's servers
    Unofficial

371     TCP     UDP     ClearCase albd
    Official

383     TCP     UDP     HP data alarm manager
    Official

384     TCP     UDP     A Remote Network Server System
    Official

387     TCP     UDP     AURP, AppleTalk Update-based Routing Protocol     Official

389     TCP     UDP     Lightweight Directory Access Protocol (LDAP)     Official

401     TCP     UDP     UPS Uninterruptible Power Supply
    Official

402     TCP         Altiris, Altiris Deployment Client
    Unofficial

411     TCP         Direct Connect Hub     Unofficial

412     TCP         Direct Connect Client-to-Client     Unofficial

427     TCP     UDP     Service Location Protocol (SLP)     Official

443     TCP         HTTPS (Hypertext Transfer Protocol over SSL/TLS)     Official

444     TCP     UDP     SNPP, Simple Network Paging Protocol (RFC 1568)     Official

445     TCP         Microsoft-DS Active Directory, Windows shares     Official

445     TCP         Microsoft-DS SMB file sharing     Official

464     TCP     UDP     Kerberos Change/Set password     Official

465     TCP         Cisco protocol
    Unofficial

465     TCP         SMTP over SSL     Unofficial

475     TCP     UDP     tcpnethaspsrv (Aladdin Knowledge Systems Hasp services, TCP/IP version)
    Official

497     TCP         Dantz Retrospect     Official

500     TCP         Qmatic Qwin communication port
    Unofficial

500         UDP     Internet Security Association and Key Management Protocol (ISAKMP)     Official

501     TCP         STMF, Simple Transportation Management Framework—DOT NTCIP 1101[citation needed]     Unofficial

502     TCP     UDP     asa-appl-proto, Protocol
    Unofficial

502     TCP     UDP     Modbus, Protocol     Unofficial

504     TCP     UDP     Citadel—multiservice protocol for dedicated clients for the Citadel groupware system     Official

510     TCP         First Class Protocol
    Unofficial

512     TCP         Rexec, Remote Process Execution     Official

512         UDP     comsat, together with biff     Official

513     TCP         rlogin     Official

513         UDP     Who
    Official

514     TCP         Shell—used to execute non-interactive commands on a remote system (Remote Shell, rsh, remsh)     Official

514         UDP     Syslog—used for system logging     Official

515     TCP         Line Printer Daemon—print service     Official

517         UDP     Talk
    Official

518         UDP     NTalk
    Official

520     TCP         efs, extended file name server
    Official

520         UDP     Routing Information Protocol (RIP)     Official

524     TCP     UDP     NetWare Core Protocol (NCP) is used for a variety things such as access to primary NetWare server resources, Time Synchronization, etc.     Official

525         UDP     Timed, Timeserver
    Official

530     TCP     UDP     RPC
    Official

531     TCP     UDP     AOL Instant Messenger     Unofficial

532     TCP         netnews
    Official

533         UDP     netwall, For Emergency Broadcasts
    Official

540     TCP         UUCP (Unix-to-Unix Copy Protocol)     Official

542     TCP     UDP     commerce (Commerce Applications)
    Official

543     TCP         klogin, Kerberos login     Official

544     TCP         kshell, Kerberos Remote shell     Official

545     TCP         OSIsoft PI (VMS), OSISoft PI Server Client Access     Unofficial

546     TCP     UDP     DHCPv6 client     Official

547     TCP     UDP     DHCPv6 server     Official

548     TCP         Apple Filing Protocol (AFP) over TCP     Official

550         UDP     new-rwho, new-who
    Official

554     TCP     UDP     Real Time Streaming Protocol (RTSP)     Official

556     TCP         Remotefs, RFS, rfs_server     Official

560         UDP     rmonitor, Remote Monitor
    Official

561         UDP     monitor
    Official

563     TCP     UDP     NNTP protocol over TLS/SSL (NNTPS)     Official

587     TCP         e-mail message submission (SMTP)     Official

591     TCP         FileMaker 6.0 (and later) Web Sharing (HTTP Alternate, also see port 80)     Official

593     TCP     UDP     HTTP RPC Ep Map, Remote procedure call over Hypertext Transfer Protocol, often used by Distributed Component Object Model services and Microsoft Exchange Server     Official

604     TCP         TUNNEL profile,[21] a protocol for BEEP peers to form an application layer tunnel     Official

623         UDP     ASF Remote Management and Control Protocol (ASF-RMCP)[citation needed]     Official

631     TCP     UDP     Internet Printing Protocol (IPP)     Official

631     TCP     UDP     Common Unix Printing System (CUPS)     Unofficial

635     TCP     UDP     RLZ DBase[citation needed]     Official

636     TCP     UDP     Lightweight Directory Access Protocol over TLS/SSL (LDAPS)     Official

639     TCP     UDP     MSDP, Multicast Source Discovery Protocol     Official

641     TCP     UDP     SupportSoft Nexus Remote Command (control/listening): A proxy gateway connecting remote control traffic[citation needed]     Official

646     TCP     UDP     LDP, Label Distribution Protocol, a routing protocol used in MPLS networks     Official

647     TCP         DHCP Failover protocol[22]     Official

648     TCP         RRP (Registry Registrar Protocol)[23]     Official

651     TCP     UDP     IEEE-MMS[citation needed]     Official

652     TCP         DTCP, Dynamic Tunnel Configuration Protocol[citation needed]     Unofficial

653     TCP     UDP     SupportSoft Nexus Remote Command (data): A proxy gateway connecting remote control traffic[citation needed]     Official

654     TCP         Media Management System (MMS) Media Management Protocol (MMP)[24]     Official

657     TCP     UDP     IBM RMC (Remote monitoring and Control) protocol, used by System p5 AIX Integrated Virtualization Manager (IVM)[25] and Hardware Management Console to connect managed logical partitions (LPAR) to enable dynamic partition reconfiguration     Official

660     TCP         Mac OS X Server administration     Official

665     TCP         sun-dr, Remote Dynamic Reconfiguration[citation needed]     Unofficial

666         UDP     Doom, first online first-person shooter     Official

674     TCP         ACAP (Application Configuration Access Protocol)     Official

691     TCP         MS Exchange Routing     Official

694     TCP     UDP     Linux-HA High availability Heartbeat     Official

695     TCP         IEEE-MMS-SSL (IEEE Media Management System over SSL)[26]     Official

698         UDP     OLSR (Optimized Link State Routing)     Official

700     TCP         EPP (Extensible Provisioning Protocol), a protocol for communication between domain name registries and registrars (RFC 5734)     Official

701     TCP         LMP (Link Management Protocol (Internet)),[27] a protocol that runs between a pair of nodes and is used to manage traffic engineering (TE) links     Official

702     TCP         IRIS[28][29] (Internet Registry Information Service) over BEEP (Blocks Extensible Exchange Protocol)[30] (RFC 3983)     Official

706     TCP         Secure Internet Live Conferencing (SILC)     Official

711     TCP         Cisco Tag Distribution Protocol[31][32][33]—being replaced by the MPLS Label Distribution Protocol[34]     Official

712     TCP         Topology Broadcast based on Reverse-Path Forwarding routing protocol (TBRPF) (RFC 3684)     Official

712         UDP     Promise RAID Controller[citation needed]     Unofficial

720     TCP         SMQP, Simple Message Queue Protocol[citation needed]     Unofficial

749     TCP     UDP     Kerberos (protocol) administration     Official

750         UDP     kerberos-iv, Kerberos version IV     Official

751     TCP     UDP     kerberos_master, Kerberos authentication     Unofficial

752         UDP     passwd_server, Kerberos Password (kpasswd) server     Unofficial

753     TCP         Reverse Routing Header (rrh)[35]     Official

753         UDP     Reverse Routing Header (rrh)     Official

753         UDP     userreg_server, Kerberos userreg server     Unofficial

754     TCP         tell send[citation needed]     Official

754     TCP         krb5_prop, Kerberos v5 slave propagation     Unofficial

754         UDP     tell send[citation needed]     Official

760     TCP     UDP     krbupdate [kreg], Kerberos registration     Unofficial

782     TCP         Conserver serial-console management server     Unofficial

783     TCP         SpamAssassin spamd daemon     Unofficial

808     TCP         Microsoft Net.TCP Port Sharing Service[citation needed]     Official

829     TCP         CMP (Certificate Management Protocol)[citation needed]     Unofficial

843     TCP         Adobe Flash[36]     Unofficial

847     TCP         DHCP Failover protocol     Official

848     TCP     UDP     Group Domain Of Interpretation (GDOI) protocol[citation needed]     Official

860     TCP         iSCSI (RFC 3720)     Official

873     TCP         rsync file synchronisation protocol     Official
 USA only
888     TCP         cddbp, CD DataBase (CDDB) protocol (CDDBP)—unassigned but widespread use     Unofficial

901     TCP         Samba Web Administration Tool (SWAT)     Unofficial

901     TCP         VMware Virtual Infrastructure Client (UDP from server being managed to management console)     Unofficial

901         UDP     VMware Virtual Infrastructure Client (UDP from server being managed to management console)     Unofficial

902     TCP         ideafarm-door[citation needed]     Official

902     TCP         VMware Server Console (TCP from management console to server being Managed)     Unofficial

902         UDP     ideafarm-door[citation needed]     Official

902         UDP     VMware Server Console (UDP from server being managed to management console)     Unofficial

903     TCP         VMware Remote Console [37]     Unofficial

904     TCP         VMware Server Alternate (if 902 is in use, i.e. SUSE linux)     Unofficial

911     TCP         Network Console on Acid (NCA)—local tty redirection over OpenSSH     Unofficial

944         UDP     Network File System (protocol) Service     Unofficial

953     TCP     UDP     Domain Name System (DNS) RNDC Service     Unofficial

973         UDP     Network File System (protocol) over IPv6 Service     Unofficial

981     TCP         SofaWare Technologies Remote HTTPS management for firewall devices running embedded Check Point FireWall-1 software     Unofficial

987     TCP         Microsoft This Secure Hypertext Transfer Protocol (HTTPS) port makes Windows SharePoint Services viewable through Remote Web Workplace[citation needed]     Unofficial

989     TCP     UDP     FTPS Protocol (data): FTP over TLS/SSL     Official

990     TCP     UDP     FTPS Protocol (control): FTP over TLS/SSL     Official

991     TCP     UDP     NAS (Netnews Administration System)[38]     Official

992     TCP     UDP     TELNET protocol over TLS/SSL     Official

993     TCP         Internet Message Access Protocol over SSL (IMAPS)     Official

995     TCP         Post Office Protocol 3 over TLS/SSL (POP3S)     Official

999     TCP         ScimoreDB Database System[citation needed]     Unofficial

1002     TCP         Opsware agent (aka cogbot)[citation needed]     Unofficial

1023     TCP     UDP     Reserved[1]

20 things to do after installing Kali Linux

20 things to do after installing Kali Linux

List of 20 things to do after installing Kali Linux

 CONTENTS

· Standard Packages:

o Kali Specific:

 1. Fix Device not managed error – wired network

 2. Fix default repository

 3. Update, Upgrade, Dist-Upgrade

 4. Fix PulseAudio warning

 5. Enable sound on Boot

o Useful utilities and Software’s

§ 6. Install Java

§ 7. Install Flash

§ 8. Install File Roller – Archive Manager

 9. Add a standard user

 10. Add add-apt-repository

 11. Install Tor

 12. Install Filezilla FTP Client

 13. Install HTOP and NetHogs

 14. Install proprietary drivers for your Graphics card

 15. Install Recordmydesktop and Reminna Remote Desktop Client

 16. Install GDebi Package Manager

o Enhancements and accessibility

17. Install a theme

18. Install a new desktop environment (I prefer XFCE).

 19. Enable Autologin user

 More Advanced stuffs:

20. Unlock GPU processing

 a. AMD

 b. NVIDIA

Standard Packages:

Standard packages contains anything and everything I found useful. This list if divided into 3 parts:

· Kali Specific

Kali Linux is a special build from Debian. Kali Linux inherits a lot of the issues from Debian Linux. This section shows you how to resolve of those. They are not specific to Kali Linux only and you might be leave them as it is, but I found that if I see an error my OCD kicks in and I have to make it go away…

· Useful utilities and Software’s

A collection of utilities and software’s I found useful. These are day to day software’s that are available in most other Linux distributions or at least I think they should be made available as part of a default installation.

· Enhancements and accessibility

Kali Linux is made to boot up fast and low of resources. But if you have some more CPU and GPU power to spare, you might want to try to make it look more colorful.

Kali Specific:

1. Fix Device not managed error – wired network

If you want NetworkManager to handle interfaces that are enabled in /etc/network/interfaces: Set managed=true in /etc/NetworkManager/NetworkManager.conf. So this file looks like:
[main]
plugins=ifupdown,keyfile

[ifupdown]
managed=true

Read the full article on fixing Wired Network interface “Device not managed” error in Debian or Kali Linux.

2. Fix default repository

The simplest way is to edit the /etc/apt/sources.list remove or comment every-line with # at the front and add the following lines..

 leafpad /etc/apt/sources.list

Comment or remove existing config with the following lines:

## Regular repositories
deb http://http.kali.org/kali kali main non-free contrib
deb http://security.kali.org/kali-security kali/updates main contrib non-free
## Source repositories
deb-src http://http.kali.org/kali kali main non-free contrib
deb-src http://security.kali.org/kali-security kali/updates main contrib non-free

Save and close the file. Details and explanations can be found in adding official Kali Linux Repositories page.

3. Update, Upgrade, Dist-Upgrade

Clean, update, upgrade and dist-upgrade your Kali installation.
 apt-get clean && apt-get update && apt-get upgrade -y && apt-get dist-upgrade -y

4. Fix PulseAudio warning

My Kali throws me this warning:

[warn] PulseAudio configured for per-user sessions ... (warning).

Debian variants also throws similar warning during boot.To fix this do the following:

leafpad /etc/default/pulseaudio

Find this line:

PULSEAUDIO_SYSTEM_START=0

Replace 0 with 1

PULSEAUDIO_SYSTEM_START=1

Where, 0 = don’t start in system mode, 1 = start in system mode
reboot

Details and explanations can be found in Fixing PulseAudio configured for per-user sessions … (warning) in Kali Linux page.

5. Enable sound on Boot

Follow the steps below to fix sound mute in Kali Linux on boot
apt-get install alsa-utils -y

In GNOME Desktop (The default Kali Desktop)

· Right Click on the small volume ICON and select Sound Preferences

· Alternatively, you can also go to Applications > System Tools > Preferences > System Settings > Sound to bring up the same options.

· Use the Output volume slider to ON, shown similar the screenshot above. That’s it you’re done. Close Sound window.

Details and explanations can be found in fixing sound mute in Kali Linux on boot page.

6. Install Java

Go to the following link and download jdk7. At the time of writing this guide the jdk version was jdk-7u45-linux-x64. Note that I’m using x64 which is 64-bit. 32-bit users should choose their versions accordingly. Not that tough really!

Following is what I’ve used.
 JDK-7u45-Linux-x64
 At the time of writing this guide the available version was jdk-7u45-linux-x64.tar.gz

Download and save the file in /root directory.

tar -xzvf /root/jdk-7u45-linux-x64.tar.gz
mv jdk1.7.0_45 /opt
cd /opt/jdk1.7.0_45

This step registers the downloaded version of Java as an alternative, and switches it to be used as the default:
update-alternatives --install /usr/bin/java java /opt/jdk1.7.0_45/bin/java 1
update-alternatives --install /usr/bin/javac javac /opt/jdk1.7.0_45/bin/javac 1
update-alternatives --install /usr/lib/mozilla/plugins/libjavaplugin.so mozilla-javaplugin.so /opt/jdk1.7.0_45/jre/lib/amd64/libnpjp2.so 1
update-alternatives --set java /opt/jdk1.7.0_45/bin/java
update-alternatives --set javac /opt/jdk1.7.0_45/bin/javac
update-alternatives --set mozilla-javaplugin.so /opt/jdk1.7.0_45/jre/lib/amd64/libnpjp2.so

Follow installing Java JDK in Kali Linux post for step by step instructions and testing options.

7. Install Flash

This is fairly simple and easy and should work from most people out there:
 In the terminal:

 apt-get install flashplugin-nonfree

and then type in:

update-flashplugin-nonfree --install

That’s it. You flash should be working as expected.

Follow installing Flash in Kali Linux post for step by step instructions and testing options. This post also includes manual Flash installation procedures for those whose installation might fail with above mentioned process.

8. Install File Roller – Archive Manager

Kali Linux lacks a proper GUI archive manager. Install it Archive Manager (File Roller) using the following command:

apt-get install unrar unace rar unrar p7zip zip unzip p7zip-full p7zip-rar file-roller -y

You can now find Archive Manager in Applications > Accessories > Archive Manager.

9. Add a standard user

Kali Linux got only root user by default. While most applications require root access, it’s always a good idea to add a second user. Open terminal and type following to create new user (replace user1 with your desired user name)
useradd -m user1
(Note: -m means create home directory which is usually /home/username)

Now set password for this user

passwd user1

Enter desired password twice Add user to sudo group (to allow user to install software, allow printing, use privileged mode etc.)
usermod -a -G sudo user1

(Note: -a means append or add and –G mean to specified group/groups)

 Change default shell of previously created user to bash

chsh -s /bin/bash user1

To learn more, follow this excellent and detailed post on adding remove user (standard user/non-root) in Kali Linux. This post explains how to add a user with all user directories already in place (thereby avoiding “Could not update .ICEauthority var/lib/gdm3/.ICEauthority” or any error containing .ICEauthority or permission in general.

10. Add add-apt-repository

Debian allows users to add and use PPA repositories by an application named add-apt-repository however, Kali Linux didn’t include this in their default package list. With Kali, because this is a special purpose application and certain modifications were made to make it work for what it does best (Penetration Test). To enable PPA Repository via add-apt-repository application, follow the steps below:

 First install Python

Software properties package.

apt-get install python-software-properties

Next install apt-file

apt-get install apt-file

Update apt-file.

apt-file update

This takes a while, so in case your apt-file update is SLOW, you might want to try and fix that as well. (Note that I got repo.kali.org in my /etc/apt/sources.list file instead of http.kali.org.) Once apt-file update is complete, you should be able to search for it.

apt-file search add-apt-repository

Your output should look similar to this:

python-software-properties: /usr/bin/add-apt-repository
python-software-properties: /usr/share/man/man1/add-apt-repository.1.gz

The default add-apt-repository application located in (/usr/bin/add-apt-repository) works for Debian. So if you’re using Kali, chances are it won’t work. There’s a nice fix for that which I will add at the bottom of this post, (try them on VirtualBox if you feel like). But I found we can just mimic Ubuntu Oneiric to make add-apt-repository work.

cd /usr/sbin
vi add-apt-repository
Add the following code and save the file.
#!/bin/bash
if [ $# -eq 1 ]
NM=`uname -a && date`
NAME=`echo $NM | md5sum | cut -f1 -d" "`
then
  ppa_name=`echo "$1" | cut -d":" -f2 -s`
  if [ -z "$ppa_name" ]
  then
    echo "PPA name not found"
    echo "Utility to add PPA repositories in your debian machine"
    echo "$0 ppa:user/ppa-name"
  else
    echo "$ppa_name"
    echo "deb http://ppa.launchpad.net/$ppa_name/ubuntu oneiric main " >> /etc/apt/sources.list
    apt-get update >> /dev/null 2> /tmp/${NAME}_apt_add_key.txt
    key=`cat /tmp/${NAME}_apt_add_key.txt | cut -d":" -f6 | cut -d" " -f3`
    apt-key adv --keyserver keyserver.ubuntu.com --recv-keys $key
    rm -rf /tmp/${NAME}_apt_add_key.txt
  fi
else
  echo "Utility to add PPA repositories in your debian machine"
  echo "$0 ppa:user/ppa-name"
fi

Note: In this line echo "deb http://ppa.launchpad.net/$ppa_name/ubuntu oneiric main" >> /etc/apt/sources.list

I’ve used Oneiric. You can try to use Lucid, Raring or Saucy as per your choice. Now chmod and chown the file.

chmod o+x /usr/sbin/add-apt-repository
chown root:root /usr/sbin/add-apt-repository

Now that we added the correct code, we can use add-apt-repository to add a PPA repository. I tried the following to add themes and custom icons in Kali Linux.

/usr/sbin/add-apt-repository ppa:noobslab/themes
/usr/sbin/add-apt-repository ppa:alecive/antigone

I’ve removed all screenshots from this post, but if you want see read and understand how it all works, I suggest reading the details post on adding PPA repository add-apt-repository in Kali Linux.

11. Install Tor

Tor is free software and an open network that helps you defend against traffic analysis, a form of network surveillance that threatens personal freedom and privacy, confidential business activities and relationships, and state security. This guide guides your through installing tor in Kali Linux. Tor protects you by bouncing your communications around a distributed network of relays run by volunteers all around the world: it prevents somebody watching your Internet connection from learning what sites you visit, and it prevents the sites you visit from learning your physical location.

Tor is available in Kali repository, to install it directly from the repository open your Terminal and type this:

apt-get install tor

Enable tor service from command line:

service tor start

Browse with confident by using proxychains and tor

proxychains iceweasel

To keep things simple in this post, I’ve only shows one part of using Tor. You might want to read the full details in Installing Tor In Kali Linux post.

12. Install Filezilla FTP Client

No Linux installation is complete with a proper fully fledged FTP Client. Filezilla is the best out there, so install Filezilla using the following command:

apt-get install filezilla filezilla-common -y

13. Install HTOP and NetHogs

This is a special one, HTOP shows running process and memory used including many more details. (you could use top command, but HTOP is just more useful). NetHogs is useful and it shows traffic used by applications per interface. Install them using the following command:

apt-get install htop nethogs -y

You can now run then using the following commands:

htop
nethogs eth0
nethogs wlan0

I’m almost certain, you’ll enjoy using these tiny tools.

14. Install proprietary drivers for your Graphics card

Depending on which graphics card you’re using, (AMD or NVIDIA), you might want to install proprietary drivers to unlock more features. There’s some excellent post I’ve made on Install AMD ATI proprietary driver (fglrx) in Kali Linux.

NVIDIA users can just stick to the official documentation for installing NVIDIA Drivers. In case, official documentation is not working or you’ve hit rock bottom, you can try following this other post I’ve written to install NVIDIA binary drivers manually.

 15. Install Recordmydesktop and Reminna Remote Desktop Client

Recordmydesktop gives you the ability to record and make a video of your activities in Kali Linux. Remmina is simialar to Windows Remote Desktop Client. Both very useful. Install them using the following command:
apt-get install gtk-recordmydesktop recordmydesktop remmina -y

16. Install GDebi Package Manager

dpkg is a powerful tool, but it doesn’t install dependencies automatically. What we need is some package installer that can go out and fetch all required dependencies while installing a .deb package. The best one out there is gdebi. Install it using the following command:
apt-get install gdebi -y

Enhancements and accessibility

17. Install a theme

Installing theme and revving up your desktop is a great idea. Kali default desktop is dull and boring. There’s two different ways you can change theme.

1. Manually install theme

2. Install theme via PPA repository

Read details here to and find out how to change or install GTK3 themes in Kali Linux.

18. Install a new desktop environment (I prefer XFCE).

I prefer XFCE Desktop, but you can try to install/remove different Desktop Environments or Window Manager in Kali Linux Depending on which one you need choose links below:

1. How to install/remove XFCE Desktop Environment in Kali Linux

2. How to install/remove different KDE Desktop Environments in Kali Linux

3. How to install/remove LXDE Desktop Environment in Kali Linux

4. How to install/remove GNOME Desktop Environment on Kali Linux

5. How to install/remove Cinnamon Desktop Environment in Kali Linux

6. How to install/remove MATE Desktop Environment in Kali Linux

Finally, follow follow these instructions to permanently switch Desktop Environments.(i.e. boot into XFCE instead of GNOME).


19. Enable Autologin user

It’s a simple change. Just open and edit the file called /etc/gdm3/daemon.conf, assuming you’re using GNOME Display Manager(gmd3) a your main Display Manager. You might want to try out other desktops as well. Here’s a link to Add/Remove different desktop Managers in Kali Linux.

root@kali:~# leafpad /etc/gdm3/daemon.conf

In the daemon section un-comment the 2 lines for automatic login. It should finally look like this
[daemon]
# Enabling automatic login
  AutomaticLoginEnable = true
  AutomaticLogin = root

That’s it. Too easy. In case you’re wondering how to use a different user than root, here’s how
[daemon]

# Enabling automatic login
  AutomaticLoginEnable = true
  AutomaticLogin = myanotheruser


Last but not the least, reboot to check if it worked. (which it will, cause it’s Linux and Kali is awesome)
reboot

You might want to follow up on this one or if you’re KDE user, then here’s the instructions to Auto login root user at system start in Kali Linux – GNOME and KDE. This article also shows how to auto-login a different non-root user… quite handy.

More Advanced stuffs:

This part explains how to get more out of your system, specially Graphics card.

20. Unlock GPU processing

Last but not the least, GPU processing is a lot faster when you’re trying to break a password. Depending on your Graphics card, you choose options as outlined below:

a. AMD

· Install AMD ATI Driver (fglrx) in Kali Linux 1.x

Then follow rest of the guides here

· Install AMD APP SDK in Kali Linux?

· Install Pyrit in Kali Linux?

· Install CAL++ in Kali Linux?

b. NVIDIA

NVIDIA users can just stick to the official documentation for installing NVIDIA Drivers.
In case, official documentation is not working or you’ve hit rock bottom, you can try following this other post I’ve written to install NVIDIA binary drivers manually.

· Install Nvidia Kernel Module Cuda and Pyrit in Kali Linux

Bypassing Windows Login using Backdoor trick

            

Locked out of your windows account or have a dire need to access one that your not supposed to have access to?
 Either way, these tricks can help you regain entry quick and simple.

Utilman.exe Backdoor trick

1# Boot up using a Windows 7 Installation CD or Flash drive

2# At the first splash screen click  “Repair your Computer”

3# Select the “Use recovery tools that can help fix problems….” and click Next.

4# Click “Command Prompt”

5# Type in the following commands:

cd /D c:

cd c:/Windows/system32

copy UtilMan.exe utilman.bak

copy cmd.exe Utilman.exe

So what does that do you ask? Well, the first two commands changed our current working directory to /Windows/system32.

 This location contains both cmd.exe (command prompt) and Utilman.exe (Ease of Access).

 Once we changed directories we then made a backup of the UtilMan.exe file and named it utilman.bak as we don’t want to permanently destroy the file.

 We then copied the cmd.exe program to Utilman.exe (essentially renaming the file)

6. Reboot your system and remove installation media.

7. At the login screen click the Ease of Access button in the bottom left hand corner. This should launch a command prompt.

8.  Run the following commands:

net user frank Replacesoon! /add

net localgroup administrators cracked /add

The first command creates a new user named frank and sets a password of Replacesoon!.

 The second command adds the new user to the administrators group.

9. Close command prompt.

10. Log in using your new credentials.

And your in, via your newly created administrator-rights enabled account where you should be free to access the user account system tool and change your password to access your original account.

Overwrite Sticky Keys Method

Now this next trick is similar in scope but slightly different that the last one, it starts exactly as did the other,

1# Boot up using a Windows 7 Installation CD or Flash drive

2# At the first splash screen click  “Repair your Computer”

3# Select the “Use recovery tools that can help fix problems….” and click Next.

4# Click “Command Prompt”

   Now, once command prompt comes up,

5# first, start off by typing in the following command to backup the original sticky keys file:

copy c:\windows\system32\sethc.exe c:\

6# Then you’ll copy the command prompt executable (cmd.exe) over top of the sticky keys executable:

copy c:\windows\system32\cmd.exe c:\windows\system32\sethc.exe

7# Now you can reboot the PC.

Resetting the Password

8# Once you get to the login screen, hit the Shift key 5 times, and you’ll see an administrator mode command prompt.

9# Now to reset the password—just type the following command, replacing the username and password with the combination you want:

net user geek MyNewPassword

10# That’s all there is to it. Now you can login.

OPTIONAL BUT RECOMENDED!  If you wish to put the original sethc.exe file back, you can do so by rebooting into the installation CD, opening the command prompt, and copying the c:\sethc.exe file back to c:\windows\system32\sethc.exe.

Enabling the built-in Administrator Account

If your default administrator account is not already activated (if it is you should see a administrator user on the login screen along with the usual user accounts you have) If not, then you can enable it by doing the following...

 To enable the hidden Administrator account

If you cannot access your user account so that you can enter into safe mode then Use a windows installation/recovery cd or recovery usb flash drive in order to access a command prompt and continue at step 4#

if not then read on and follow the steps,

1#

 Boot into safe mode

2#

 Click Start, type 'cmd',

3#

 right-click Command Prompt and select Run as Administrator

4#

. In the command prompt type:

Net user administrator /active:yes

5#

Hit Enter and you should see a message that says, "The command completed successfully".

Congrats, you have just enabled your built-in administrator account!

Well, thats all folks! till next time, spank the monkey here signing off and wishing you all a happy holiday!

check out my other sites here!

dynabyt3.p4o.net

howhedunit.com

flibflab.com

hackingbytes.com

this blog can be found out

The Shrine of the Golden Monkey

see my other blogs

the bird knows all

if it ain't wrong...

major swag 4 all!

the sultan of sha

Google dork query definition

A Google dork query, sometimes just referred to as a dork, is a search string that uses advanced search operators to find information that is not readily available on a website.

Google dorking, also known as Google hacking, can return information that is difficult to locate through simple search queries. That description includes information that is not intended for public viewing but that has not been adequately protected.

As a passive attack method, Google dorking can return usernames and passwords, email lists, sensitive documents, personally identifiable financial information (PIFI) and website vulnerabilities. That information can be used for any number of illegal activities, including cyberterrorism, industrial espionage, identity theft and cyberstalking.

A search parameter is a limitation applied to a search. Here are a few examples of advanced search parameters:

site: returns files located on a particular website or domain.
filetype: followed (without a space) by a file extension returns files of the specified type, such as DOC, PDF, XLS and INI. Multiple file types can be searched for simultaneously by separating extensions with “|”.
inurl: followed by a particular string returns results with that sequence of characters in the URL.
intext: followed by the searcher’s chosen word or phrase returns files with the string anywhere in the text.
Multiple parameters can be used, for example, to search for files of a certain type on a certain website or domain. The Public Intelligence website provides this example:

“sensitive but unclassified” filetype:pdf site:publicintelligence.net

Those search parameters return PDF documents on that website’s servers with the string “sensitive but unclassified” anywhere in the document text.

Access to internal documents can yield further sensitive information. For example, document metadata often contains more information than the author is aware of, such as revision history, deletions, dates and author / updater names.  Because an intruder with the requisite know-how and / or tools can access such information, it’s a good practice to ensure that it is actually removed from documents before they are published or shared. The practice of document sanitization is designed to make sure that only the intended information can be accessed.

Vulnerable software

Google hacking provides a number of basic footprinting methods to profile a website — server software, operating system and so on. But much of that information is more easily found through sites such as Netcraft.com. Where Google dorks really come into their own is when the software you’re running is know to have vulnerabilities.

Software often uses easily identifiable filenames that will turn up in URLs. For example, one Google dork from 2004 targeted the Comersus APS-based e-commerce package which had an XSS flaw in the file comersus_message.asp. This could be exploited with a specially crafted URL.

To find sites running this package all a hacker had to do was type the following into Google:

inurl:comersus_message.asp

Software identifies itself in other ways, too. There’s often a credit along the lines of “Powered by…”. Worse, some packages even include the version number. The second that version is known to contain a flaw, hackers worldwide will scour the web for vulnerable sites.

These credit lines are typically part of default installations and many publicly available templates or themes. It’s generally fairly easy to remove them, especially if you develop your own theme. Go through the code and remove everything that identifies the software, including any HTML comments or meta tags. But remember to check each time you upgrade the software that these lines haven’t been reintroduced.

Software credits also find they way into <title> tags sometimes. And even when they don’t say “powered by…”, the page title is often enough to identify your site — using Google’s intitle: operator — as running on a vulnerable version of the software because the text is so specific to that page. There is little you can do about that other than ensure that your software is always up to date.



Open directories

There is nothing a hacker loves more than an unprotected directory. If web server software receives a request that contains a directory name, rather than a specific file, it will look for a default ‘index’ file — called ‘index.html’ or any one of a number of other standard files depending on the server configuration. If it doesn’t find one, it will helpfully present a list of files and sub-directories in that directory, with each filename clickable.

Web servers use standard terms in the page or title when they does this, so such open directories are easily found. Here’s one way to find .txt, doc and .pdf files on the site www.example.com. The first section uses the negation modifier (‘-’) with the inurl: operator to tell the search to ignore .html, .htm and .php files.

-inurl:(htm|html|php) intitle:"index of" +"last modified" +"parent directory" +description +size +(.txt|.doc|.pdf)

That will find examples across the web. Add “site:www.example.com” to search a specific site.

It’s surprising how often such directories contain text files with configuration, even password, information. (Beware, however, if you experiment with this: the results generated by Google dorks aimed at password files often lead to honey traps.) Even if the directory contains only harmless files — images, for example — the fact that your site has an unprotected directory will draw hackers to it, who will have assumed that your security is shoddy. That’s not good.

It helps an attacker map the topography of your system. Some of those sub-directories, for example, might contain files that you don’t want people to know about (although keeping such files in a publicly accessible part of the directory tree is a bad idea to start with).

Google won’t necessarily find such directories if they are not referenced anywhere in your website, but that hardly counts as protection.

This problem is very easily fixed. Always have an index file in every directory. A simple index.html or index.htm (depending on server settings) will do it. It doesn’t even have to contain anything — so long as the server has something to grab and serve up, it won’t provide a directory listing. A sensible solution, though, is to have index.html contain a very basic web page, perhaps with a link to your home page.



Sensitive scripts

Some of the files left publicly available are there by mistake. Bizarrely, others are deliberate. Webmasters often allow scripts to output logs. For instance, the following gives interesting information about a specific piece of bulletin board software (just click through any messages that pop up):

inurl:CrazyWWWBoard.cgi intext:"detailed debugging information"

If you have administration software that reports on, perhaps, network performance, ask yourself if those reports need to be available online. If so, make the pages that contain the output of any scripts password-protected directory.



Error messages

Hackers really hit paydirt when your site goes wrong. Error messages often contain useful data for the hacker. Not long ago, The Register reported on a website that displayed a huge amount of PHP information due to an error. Google, of course, duly indexed this. It’s not unknown for some site developers to enable a debugging mode that displays the output of the phpinfo() function if there’s a problem. That function prints out a vast amount of information useful to a hacker. To see some sites with this issue, try:

intitle:phpinfo "PHP Version"

Various kinds of software display standard (and thus searchable) messages when they hit a problem. For example, try searching with:

"mySQL error with query"

These error messages may include database, table and field names — invaluable for SQL injection attacks — and even user names. PHP, ASP and other scripting systems may produce errors that reveal directory structures, names of otherwise obscure script files and other useful detail.

Even if the admin has since fixed the problem, so that the error message is no longer displayed, the fact that you’ve found this site with a search means that the problem page, including the error message, is still in Google’s cache. So, on the Google results page, you simply opt for the ‘Cached’ link.

Certain Google dorks will find default pages that might suggest a poorly installed or maintained site. Some of these will reveal interesting information, for example:

intitle:"Apache Status" "Apache Server Status for"

This can reveal data about virtual hosts, directory structure and files.

It’s therefore wise to turn off error reporting for live sites — in the database, scripting language, CMS and any other software you’re using. And to make sure that you have completed configuration for all installed software.



Security through obscurity

What Google dorks teach us is that there is no security through obscurity on the web — simply because there is no obscurity. You might think that you’re the only one that knows where the login page is for your CMS, or that a certain file is not linked from anywhere else and will not, therefore, be found by Google. But it’s a mistake to rely on this.

Even when a Google dork doesn’t reveal specific information, it can tell a hacker where to strat looking. For example, there are dorks that reveal the login pages for administrators — pages that may not be linked ordinarily from the public side of the site.

inurl:/admin/login.asp



Tools

This is just a taste of what Google dorks can achieve. Helpfully, there are tools available to automate Google hacking. One of them is produced by Google itself: GoogleHacks.4 It’s somewhat basic, but script kiddies will love it.

The Cult of the Dead Cow group — notorious for the Back Orifice trojan — has released a Windows-only tool, Goolag.5 This is rather more sophisticated. It comes with a database of Google Dorks, supplied in XML format, so it’s easily readable and amendable. You can also specify your own searches.

By automating groups of Google Dorks, Goolag is a useful first step in penetration testing of your own sites. But there’s no real substitute for working through the Google Dorks yourself, given that you will have some idea of where weaknesses may lie.



Countermeasures

We’ve already outlined some of the measures you can take to protect yourself. The best approach is to Google hack your own site, identify all those flaws that can be picked up by Google and fix them. Skilled hackers may still be able to use some of these tricks to survey your site if they have already targeted it. But at least you won’t be advertising your problems.





email spoofing - Email spoofing is the forgery of an email header so that the message appears to have originated from someone or somewhere other than the actual source.

buffer overflow - A buffer overflow occurs when a program attempts to write more data to a fixed length block of memory, or buffer, than the buffer is allocated to hold. Buffer overflow exploits may enable remote ex... (SearchSecurity.com)

private key (secret key) - A private (secret) key is an encryption key whose value should never be made public. The term may refer to the private key of an asymmetric key pair or a key shared by parties who are using symmetr...

Network security - Terms related to network security, including definitions about intrusion prevention and words and phrases about VPNs and firewalls.

Internet applications - This WhatIs.com glossary contains terms related to Internet applications, including definitions about Software as a Service (SaaS) delivery models and words and phrases about web sites, e-commerce ...

Power grid vulnerable to foreign hacks

SAN JOSE, Calif. — Security researcher Brian Wallace was on the trail of hackers who had snatched a California university's housing files when he stumbled into a larger nightmare: Cyberattackers had opened a pathway into the networks running the United States' power grid.

Digital clues pointed to Iranian hackers. And Wallace found that they had already taken passwords, as well as engineering drawings of dozens of power plants, at least one with the title "Mission Critical." The drawings were so detailed that experts say skilled attackers could have used them, along with other tools and malicious code, to knock out electricity flowing to millions of homes.

Wallace was astonished. But the breach was not unique.

About a dozen times in the last decade, sophisticated foreign hackers have gained enough remote access to control the operations networks that keep the lights on, according to top experts who spoke only on condition of anonymity due to the sensitive nature of the subject matter.

The public almost never learns the details about these types of attacks — they're rarer but also more intricate and potentially dangerous than data theft. Information about the government's response to these hacks is often protected and sometimes classified; many are never even reported to the government.

These intrusions have not caused the kind of cascading blackouts that are feared by the intelligence community. But so many attackers have stowed away in the systems that run the U.S. electric grid that experts say they likely have the capability to strike at will.

And that's what worries Wallace and other cybersecurity experts most.

"If the geopolitical situation changes and Iran wants to target these facilities, if they have this kind of information it will make it a lot easier," said Robert M. Lee, a former U.S. Air Force cyberwarfare operations officer.

In 2012 and 2013, in well-publicized attacks, Russian hackers successfully sent and received encrypted commands to U.S. public utilities and power generators; some private firms concluded this was an effort to position interlopers to act in the event of a political crisis. And the Department of Homeland Security announced about a year ago that a separate hacking campaign, believed by some private firms to have Russian origins, had injected software with malware that allowed the attackers to spy on U.S. energy companies.

"You want to be stealth," said Lillian Ablon, a cybersecurity expert at the RAND Corporation. "That's the ultimate power, because when you need to do something you are already in place."

The hackers have gained access to an aging, outdated power system. Many of the substations and equipment that move power across the U.S. are decrepit and were never built with network security in mind; hooking them up to the Internet over the last decade has given hackers new backdoors in. Distant wind farms, home solar panels, smart meters and other networked devices must be remotely monitored and controlled, which opens up the broader system to fresh points of attack.

Hundreds of contractors sell software and equipment to energy companies, and attackers have successfully used those outside companies as a way to get inside networks tied to the grid.

Attributing attacks is notoriously tricky. Neither U.S. officials nor cybersecurity experts would or could say if the Islamic Republic of Iran was involved in the attack Wallace discovered involving Calpine Corp., a power producer with 82 plants operating in 18 states and Canada.

Private firms have alleged other recent hacks of networks and machinery tied to the U.S. power grid were carried out by teams from within Russia and China, some with governmental support.

Even the Islamic State group is trying to hack American power companies, a top Homeland Security official told industry executives in October.

The attack involving Calpine is particularly disturbing because the cyberspies grabbed so much, according to previously unreported documents and interviews.

Cybersecurity experts say the breach began at least as far back as August 2013.

Calpine spokesman Brett Kerr said the company's information was stolen from a contractor that does business with Calpine. He said the stolen diagrams and passwords were old — some diagrams dated to 2002 — and presented no threat, though some outside experts disagree.

Kerr would not say whether the configuration of the power plants' operations networks — also valuable information — remained the same as when the intrusion occurred, or whether it was possible the attackers still had a foothold.

The hackers stole user names and passwords that could be used to connect remotely to Calpine's networks, which were being maintained by a data security company. Even if some of the information was outdated, experts say skilled hackers could have found a way to update the passwords and slip past firewalls to get into the operations network. Eventually, they say, the intruders could have shut down generating stations, fouled communications networks and possibly caused a blackout near the plants.

They also took detailed engineering drawings of networks and power stations from New York to California — 71 in all — showing the precise location of devices that communicate with gas turbines, boilers and other crucial equipment attackers would need to hack specific plants.

source- GARANCE BURKE and JONATHAN FAHEY Associated Press

The Republican National

just playin with it

you can type below here

<

How to finger someone...

 how-to-finger-someone
========================

   This document describes the GNU Finger program, a utility for
finding out useful information about users on the Internet network.

Introduction
************

   GNU Finger is a utility program designed to allow users of Unix
hosts on the Internet network to get information about each other.  It
is a direct replacement for the Berkeley 4.3 finger code, although it
produces different looking output and is designed to run on a wide
variety of systems.

Why Another Finger?
===================

   Originally, each host on the Internet network consisted of a single,
reasonably powerful computer, capable of handling many users at the same
time.  Typically, a "site" (physical location of computer users) would
have only one or two computers, even if they had 20 or more people who
used them.  If a user at site A wanted to know about users logged on at
site B, a simple program could be invoked to query the host at site B
about the users which were logged on.

   With the onset of more-power-per-person computing, the mainframe has
been set aside.  A modern computing facility usually consists of one
user per host, and many hosts per site.  This makes it a trial to find
out about logged on users at another site, since you must query each
host to find out about the single user who is logged on.  If the site
had 20 hosts, you would have to invoke a finger program 20 times just to
find out who was logged on!

   GNU Finger is a simple and effective way around this problem.  For
sites with many hosts, a single host may be designated as the finger
"server" host.  This host collects information about who is logged on
to other hosts at that site.  If a user at site A wants to know about
users logged on at site B, only the server host need be queried,
instead of each host at that site.  This is very convenient.

   GNU Finger is a direct replacement for existing finger programs.
Since the finger "protocol" (rules for communication) is very simple,
GNU Finger follows that protocol in responding to simple requests.  But
GNU Finger also implements another protocol which allows two finger
programs to exchange information in a predetermined way, which allows
faster and wider bandwidth communication.

   Finger delivers information about users in varying formats,
depending on how it is invoked.  `finger' invoked without any options
performs a *site wide* finger request, no matter which machine it has
been invoked from.  Switch arguments exist for getting the "long" form
of finger information and for getting information only about the local
machine.

   If a user on host A wants to know about a user on host B, finger must
make a network "connection" to host B.  If host B is running a finger
program, that program is asked to relay information about the user in
question through the connection back to host A, where finger can
display it.

   GNU Finger also runs a server "daemon" process on the "server" host,
whose job is to keep track of which users are logged in to local
machines.

   An optional and currently unsupported feature is passing of graphic
images. This is built on the new protocol.  A user at site A (e.g. MIT)
may see the picture of a user at site B (e.g. UCSB), by typing a finger
request.  The conversion of graphic data from one format to another is
done through GNU Finger; no site need know where or how such images are
stored on any other site to be able to display those images. You should
ask your system administrator to find out whether he has chose to
include this functionality on your network.

Using Finger
************

Arguments to GNU Finger
=======================

   The basic argument to Finger is a USER@HOST pair.  The USER portion
is the name of the user about whom you would like information.  The
HOST is a machine that the user has an account on.   When invoked in
this manner, GNU Finger displays the list of hosts that this user is
currently logged in on, or, if the user is not logged in, the last time
and location that he or she was.  HOST may be expressed as any valid
Internet address (i.e.  "dot-notation", "host.domain", etc).

   If HOST is non-existent, the local host is assumed.  If USER is
blank or unspecified, it is assumed that you want information about all
users.

   The content and format of the output of GNU `finger' depends on what
is being fingered:

USER
     Displays login information about USER. If `--info' or `--l' is
     also specified, `finger' will display the full name, home
     directory, shell, mail forwarding, and `.plan' and/or `.project'
     file. This is what the output will look like:

     `bash$ finger --info bson@gnu.ai.mit.edu'
     `[apple-gunkies.gnu.ai.mit.edu]'

     `Jan Brittenson (bson)'
     `Home: /home/fsf/bson'
     `Shell: /usr/local/bin/bash'
     `Mail forwarded to bson@ai.mit.edu.'
     `No mail.'
     `  User     Real Name         What    Idle  TTY  Host      Console Location'
     `bson     Jan Brittenson     fgrep          *p0 apple-gu (nutrimat.gnu.ai.)'
     `bson     Jan Brittenson              1:57  *sb nutrimat '

     `Plan:'
     `    To hack GNU Finger'

     The following is output, in the order listed, when asking for long
     information (`-l' or `--info') about a particular user:

        * Real and login names.

        * Home directory.

        * Login shell.

        * Mail forwarding.

        * Whether the user has any unread mail, and if so, when it was
          last read.

        * Current login information, in the same format as produced by
          a short finger (see below for an explanation). If the user
          isn't currently logged on, then the last login time and
          remote host (if known) is reported.

        * A `~/.plan' file. If the file isn't readable by everyone,
          then a message is printed to this effect.

        * A `~/.projects' file. This file, like `~/.plan', should be
          readable by everyone.


     `bash$ finger bson@gnu.ai.mit.edu'
     `[apple-gunkies.gnu.ai.mit.edu]'
     `  User     Real Name         What    Idle  TTY  Host      Console Location'
     `bson     Jan Brittenson     fgrep          *p0 apple-gu (nutrimat.gnu.ai.)'
     `bson     Jan Brittenson              1:57  *sb nutrimat '

     Here is an explanation of what each column contains in the short
     example:

    `User'
          The user login name.

    `Real Name'
          The real name of the user.

    `What'
          The current or last program run by the user, depending on the
          system in use. On System V Release 4, for instance, the
          current program is shown, but on BSD it will be the last
          terminated program.

    `Idle'
          The time the user has been idle, as HOURS:MINUTES, or the
          first 7 characters of a string such as "14 days".

    `TTY'
          The significant portion of the user's terminal connection.
          Exactly what portion this is is system dependent. For
          example, on System V Release 4, it might be `*40' for
          `/dev/pty/40', while on BSD it might be `*p0' for
          `/dev/ttyp0'. If preceded by an asterisk ("*"), then the user
          allows anyone to send messages to this particular terminal.

    `Host'
          The host the user is logged onto.

    `Console Location'
          Where the user's console is located. If logged in over the
          network, then this will be the most significant portion of
          the remote host name if known. A host name is always
          parenthesized.

     In the general short output (i.e. not for a particular host), GNU
     Finger lists the least idle login for a particular user on each
     host. A single user often has several logins, since on some
     systems each window opened creates its own login record. In
     addition to the least idle login, the console login is also always
     listed, regardless of how long it has been idle.

     To list "all" login records for a particular, host, use the special
     target `.local'. For example, while the following may be part of
     the general short finger listing for the host
     `mole.gnu.ai.mit.edu':

     `brendan  Brendan Kehoe               5:09  *p8 mole     (lisa.cygnus.com)'
     `info     InfoMaster                 12:12  *p4 mole     (hal)'
     `law      Jeffrey A. Law              3:52  *p7 mole     (128.110.4.17:0.0)'
     `rms      Richard Stallman   sendmai  1:34  *p1 mole     (unix:0.0)'
     `rms      Richard Stallman           6 days *co mole'

     The last line is the console. The following might be listed by the
     command `finger .local@mole.gnu.ai.mit.edu':

     `[mole.gnu.ai.mit.edu]'
     `  User     Real Name         What    Idle  TTY  Host      Console Location'
     `brendan  Brendan Kehoe               5:18  *p8 mole     (lisa.cygnus.com)'
     `info     InfoMaster                 12:22  *p4 mole     (hal)'
     `law      Jeffrey A. Law              4:01  *p7 mole     (128.110.4.17:0.0)'
     `rms      Richard Stallman   sendmai  1:44  *p1 mole     (unix:0.0)'
     `rms      Richard Stallman           23:08  *p0 mole     (unix:0.0)'
     `rms      Richard Stallman           1 day, *p2 mole     (unix:0.0)'
     `rms      Richard Stallman           6 days *co mole'

MAILING LIST OR ALIAS
     Expands the mailing list or alias and displays the recipients. You
     always have to use `--info' or (or `-l') when fingering a mailing
     list or mail alias, otherwise mail aliases won't be looked up due
     to the extra processing involved. This is what the output will look
     like:

          % finger --info postmaster@gnu.ai.mit.edu
          postmaster is an alias for the following:
              Roland McGrath <roland>,
              <tower@prep.ai.mit.edu>,
              Noah Friedman <friedman>,
              Michael I Bushnell <mib>

USER-DEFINED TARGET
     Allows the remote host to display specific information, such as
     price lists, literature, or weather forecasts. For example:

          % finger .site@gnu.ai.mit.edu
          
          This is the FSF GNU Project. For more information, please contact
          "postmaster". For information about guest accounts, please contact
          "request".

Command Line Options
====================

   There are a number of command line options that you can give to GNU
Finger:

`--face'
`-f'
     Ask Finger for the face of all users information has been requested
     about. An explicit user list has to be provided.

`--info'
`-l'
`-i'
     Display the "long" form of information for the users fingered. The
     exact information returned depends on what finger software is run
     on the remote host - GNU Finger, for instance, returns specific
     information.  `-l' is supplied for backwards compatibility;
     `finger' as distributed from Berkeley has this option.

`--brief'
`-b'
     Display the "short" form of information for the users fingered.
     This is the opposite of `--info'.

`--port PORT'
`-P PORT'
     Make a connection to PORT, which can be either a numerical port
     number or a service name from `/etc/services'.

`--help'
`-h'
     Print a description of all options.

Special User Names
==================

   You can give GNU Finger one of several "special" user names.  These
user names all begin with a period (`.') and instruct the receiving
finger daemon to do something that only a GNU Finger daemon can do.
Currently, the "special" names are:

`.free'
     Return a list of free machines.  `Free' machines are those that
     have no users logged in, or have been idle for a long time.  The
     information returned makes it clear which one is true.

`.all'
     Return the information about every machine that the Finger server
     knows about.  `.all' is equivalent to issuing the `finger' command
     without specifying the user name.

`.site'
     Returns information about the site, such as company and location.

`.clients'
     Returns a list of the clients that the GNU Finger server knows
     about.  Also lists who is logged onto the console.

`.faces'
     Return a list of the faces that this server has available.  The
     last line output tells you how many lines were listed previously.

`.local'
     Finger only at the specific machine. This allows finger to
     continue to be useful even in the event that the server is down.
     It also allows you to examine "all" the login records of a user.
     Normally, the server only keeps track of the most recently active
     login record for each user.

`.help'
     Describe services provided by the finger server.

Advanced Use
************

How Finger Works
================

   GNU Finger is the collective name for a set of programs:
`finger'
     Parses the command line and connects to the finger server,
     `in.fingerd', on the `finger' server. Returns the output from the
     server. `finger' connects to `in.fingerd' on the host specified in
     the command line. This is the only program you need to know
     anything about if you're a regular user. You should refer to this
     program as the "finger client" to avoid possible confusion.

`fingerd'
     Regularly connects to `in.cfingerd' on the clients specified in the
     `fingerdir/clients' file, to obtain finger data. This client data
     is saved in the file `fingerdir/userdata'. `fingerd' should run on
     the host specified in the `fingerdir/serverhost' file.  `fingerd'
     should be started at boot time.

`in.fingerd'
     Responds to `finger' connections through `inetd'. Should be
     attached to the `finger' service via `/etc/inetd.conf'.
     `in.fingerd' behaves somewhat differently depending on what host it
     runs on: on the server host it reads the `fingerdir/userdata'
     database, on all other hosts it forwards all requests (unless
     `.local' is the target) to `in.fingerd' on the host specified in
     `fingerdir/serverhost'.

     `in.fingerd' reads the `fingerdir/userdata' database, various
     system files, and makes SMTP connections to the host specified in
     the `fingerdir/mailhost' file.

`in.cfingerd'
     This is the program that responds to call-ins from `fingerd' by
     sampling the status on the client and forwarding it to `fingerd'.
     It should be configured to respond to the `cfinger' service
     specified in the `clients' configuration file, or port 2003 if
     nothing else is specified.

The `~/.fingerrc' Script
========================

   When the GNU Finger server receives a request for information about a
user it looks to see if the user has a `.fingerrc' file in the home
directory. If such a file exists, and is executable, then this file is
executed, and the normal finger output is passed to it as input.  Its
output becomes what is returned for the request. Thus, it can be used
to:

   * Disable fingering a specific user by linking `~USER/.fingerrc' to
     `/bin/true'.

   * Entirely replace the output of `finger' by ignoring its input.
     Below is a sample script which could be put in
     `~price-info/.fingerrc'.

          #! /bin/sh
          #
          # This sample script replaces the output of GNU Finger
          #
          echo Hack-O-Matic Consulting Services, Inc. "   " `date`
          
          cat <<ETX
          
          Hi, thanks for asking us about prices on our newly introduced support
          services for Free Software. Below is a list of new services; for a list
          of our previous services, please send mail to this address and someone
          will contact you. Please don't forget to tell us how to reach you.
          
          ETX
          cat ~/info/new-stuff

   * Filter the output to make changes. If the script below is put in
     `~bson/.fingerrc' on the finger server host for the domain
     `gnu.ai.mit.edu':

          #! /bin/sh
          #
          # This sample filter replaces the "Project:" tag with
          # "Working on:"
          #
          sed -e 's/^Project:$/Working on:/g'

     Then when `finger -l bson@gnu.ai.mit.edu' is run, the output could
     look something like:

          Jan Brittenson (bson)
          Home: /home/fsf/bson
          Shell: /usr/local/bin/bash
          No mail.
          
          Jan Brittenson (bson) is not presently logged in.
          Last seen at wombat.gnu.ai.mit.edu on Tue Sep  1 15:08:12 1992
          
          No plan.
          
          Working on:
                  1. Hacking GNU Finger
                  2. Making friends

User-defined Targets
====================

   Various special targets can be added as executable files in the
directory `fingerdir/targets'. Each file name in this directory starts
with a letter describing when to execute it, followed by a hyphen and
the target name. The three letters are:

`l'
     In response to a "long" finger; usually by typing `finger -l'.

`s'
     In response to a "short" finger; usually the default if no options
     are given.

`x'
     In response to either a "long" or "short" request.

   For instance, the special-target file `x-.help' is run for either
`finger .help' or `finger -l .help', whereas the special- target file
`l-prices' is run only for `finger -l prices'.

   The special-target file is run as super-user, and is given no input.
By convention, all GNU Finger sites should support at least:

`.help'
     Display message describing what features and special targets exist
     on this site.

`.site'
     Display message describing the site. This may include such things
     as the company name, its address, and how to contact the system
     manager.

How Finger Picks a Port
=======================

   When invoked, the GNU Finger client looks to see if a `--port'
option was specified on the command line. If so, then this becomes the
port number or service used. Otherwise, the client looks to see what
name it was started under, removes any leading directory path, and any
trailing suffixes. A suffix is the part of a filename that follows a
dot, including the dot itself. This is the service name used.  For
instance, if GNU Finger is installed as `/usr/local/bin/finger.new',
then the service `finger' is used. If it's installed as
`/usr/local/bin/gfinger', then the service `gfinger' is used. This
behavior can be changed by the system administrator during installation.

Security Issues
***************

   One question that often arises when installing networking software
which adds new functionality is whether it can be considered
sufficiently secure. The most significant new function in GNU Finger
with regard to security is the ability for a user to have a `.fingerrc'
in the home directory. The following are the precautions take by GNU
Finger:

   * Check whether `.fingerrc' is writable to anyone except the owner.
     Notice that check is not enabled by default, since FSF users like
     anyone to be able to write any file - enable this check during
     installation by editing `config.h'.

   * Check whether `.fingerrc' is owned by the user in whose home
     directory it's found. This, like the previous check, is disabled by
     default. It really only makes sense on systems where ordinary users
     can't give away their files.

   * Execute the script through the user's login shell, using the
     command "SHELL -c SCRIPT". This means that a user who has had his
     account disabled (i.e. shell set to a program that prints a notice
     or just dies) can't run a `.fingerrc' script. This behavior can be
     changed by hard-coding the shell in `config.h'.

Bug Reports
***********

   You are strongly encouraged to submit a bug report to
bug-gnu-utils@gnu.ai.mit.edu if you have problems with this beta
release of GNU Finger. Here are some things that are generally helpful
to mention, when relevant:

   * The GNU Finger version and where you obtained the distribution.

   * Your hardware.

   * Operating system.

   * C Compiler used.

   * The arguments you gave to `./configure'.

   * Changes you made to the GNU Finger configuration files.

   * Any changes you have made to the source code or installation
     procedures.

   * Your network configuration; don't forget to mention what hardware,
     operating systems, and C compilers are used on each node where the
     bug manifests itself.

   * Any problems you had during installation.

   If you're having problems compiling or installing GNU Finger, then
the following is particularly helpful to mention:

   * The command line used to invoke `configure'.

   * The current directory.

   * The command line used to invoke `make' and `make' version
     (particularly if you're using GNU Make).

   * A capture of the compiler output.

   Please feel free to include any patches, as well.

Installation
************

Basic Installation
==================

   Here are the steps that you will need to take in order to install
GNU Finger.

  1. Pick a machine which will be the local finger server for your
     network.  Create a `clients' file, and install it in
     `/usr/local/etc/fingerdir' (or the EtcDir as specified in
     `config.h'). Put the names of all hosts that should report to the
     finger server in this file. Don't forget to include the finger
     server itself.

  2. For each client (the designated server is also a client), do the
     following,

  3. Change your working directory to be the top of the GNU Finger
     sources.  For instance, if you have placed the source in
     `/src/gnu/finger' you would type `cd /src/gnu/finger'.

  4. In the source directory, type `make clean' and `./configure' if
     this host is different from the previous one.  If you're using
     `csh' on an old version of System V, you might need to type `sh
     ./configure' instead to prevent `csh' from trying to execute
     `configure' itself.

     The `configure' shell script attempts to guess correct values for
     various system-dependent variables used during compilation, and
     creates the Makefile(s) (one in each subdirectory of the source
     directory).  In some packages it creates a C header file containing
     system-dependent definitions.  It also creates a file
     `config.status' that you can run in the future to recreate the
     current configuration.

     Running `configure' takes a minute or two.  While it is running, it
     prints some messages that tell what it is doing.  If you don't
     want to see the messages, run `configure' with its standard output
     redirected to `/dev/null'; for example, `./configure >/dev/null'.

     To compile the package in a different directory from the one
     containing the source code, you must use a version of make that
     supports the VPATH variable, such as GNU make.  `cd' to the
     directory where you want the object files and executables to go
     and run `configure'.  `configure' automatically checks for the
     source code in the directory that `configure' is in and in `..'.
     If for some reason `configure' is not in the source code directory
     that you are configuring, then it will report that it can't find
     the source code.  In that case, run `configure' with the option
     `--srcdir=DIR', where DIR is the directory that contains the
     source code.

     You can tell `configure' to figure out the configuration for your
     system, and record it in `config.status', without actually
     configuring the package (creating `Makefile' and perhaps a
     configuration header file).  To do this, give `configure' the
     `--no-create' option.  Later, you can run `./config.status' to
     actually configure the package for a particular host.  This option
     is useful mainly in `Makefile' rules for updating `config.status'
     and `Makefile'.  You can also give `config.status' the `--recheck'
     option, which makes it re-run `configure' with the same arguments
     you used before.  This is useful if you change `configure'.

     `configure' ignores any other arguments that you give it.

     If you want to install the GNU Finger configuration files somewhere
     other than `/usr/local/etc/fingerdir', then you should edit the
     files `./config.h' and `include/fingerpaths.h' now.  You need to
     specify the alternate locations of where the configuration files
     will be kept. If you want to include the unsupported code for
     mugshots, then you should now also choose one of the face formats,
     as well as edit `lib/Makefile.in', `lib/site/Makefile.in', and
     `src/Makefile.in' to compile and link in the files necessary.

     If your system requires unusual options for compilation or linking
     that `configure' doesn't know about, you can give `configure'
     initial values for some variables by setting them in the
     environment.  In Bourne-compatible shells, you can do that on the
     command line like this:

          CC='gcc -traditional' DEFS=-D_POSIX_SOURCE ./configure

     The `make' variables that you might want to override with
     environment variables when running `configure' are:

     (For these variables, any value given in the environment overrides
     the value that `configure' would choose:)

    `CC'
          C compiler program. Default is `cc', or `gcc' if `gcc' is in
          your search path.

    `INSTALL'
          Program to use to install files. Default is `install' if you
          have it, `cp' otherwise.

     (For these variables, any value given in the environment is added
     to the value that `configure' chooses:)

    `DEFS'
          Configuration options, in the form `-Dfoo -Dbar ...'

    `LIBS'
          Libraries to link with, in the form `-lfoo -lbar ...'

  5. To build and/or install the GNU Finger executables and standard
     targets, issue one of the following commands:

    `make server'
          To build and install all executables, plus install the
          finger-specific server configuration files. Use this if the
          host is the designated finger server.

    `make client'
          To build all executables, but install only those used by the
          non-server clients. Use this unless the host is the
          designated finger server.

    `make all'
          To build all executables, but perform no installation.

     The above commands build `lib/libfinger.a' and the main programs in
     `src': `finger', `in.fingerd', and `in.cfingerd', as well as
     `fingerd' on the server.  If you want to, you can override the
     `make' variables `CFLAGS' and `LDFLAGS' like this:

          make CFLAGS=-O2 LDFLAGS=-s

  6. Modify the system configuration so that the client has (refer to
     the system documentation for details on how to do this on a
     particular system):

        * Entries in the system `services' file, or equivalent, which
          mentions the correct TCP port for `in.cfingerd' (port 2003)
          and `in.fingerd' (port 79). If port 2003 is already used by
          something else, then read the section on Configuration Files
          for details on how to specify a port other than 2003 in the
          `/usr/local/etc/fingerdir/clients' file. A good name for the
          service is `cfinger'.

        * Entries in the system `inetd.conf' file, or equivalent, which
          contains references to `in.cfingerd' and `in.fingerd'.
          `in.fingerd' needs to be run with UID `root'.  Consult your
          system documentation for details on how to do this.
          `in.cfingerd' should be run with UID `root' on System V
          derivatives.

        * a `/usr/local/etc/fingerdir/serverhost' file which contains
          the name of the GNU Finger server host,

        * a `/usr/local/etc/fingerdir/mailhost' file which contains the
          name of the mail server to ask for user mail forwarding
          information and mailing list expansion, and

        * the inetd daemon restarted, so that server and user requests
          can be answered.

  7. When you have performed the above steps for each client, log onto
     the designated GNU Finger server.

  8. Start the server daemon, `fingerd'. You should arrange to have
     `fingerd' started every time the server host is rebooted. For exact
     details on how to do this, please refer to the server host's system
     documentation.

  9. If you chose to include the mugshots option, now might be a good
     time to install the mugshots.  But first, try getting a face from
     another site running GNU Finger!  For example, you might try
          `finger --face bfox@aurel.cns.caltech.edu'

 10. Modify the files `x-.help' and `x-.site' in
     `/usr/local/etc/fingerdir/targets' for your site.


   Now you're all set! You might like to read through the section on
Configuration Files.

Configuration Files
===================

   This section describes the format of the GNU Finger configuration
files.

The `clients' file
------------------

   The `/usr/local/etc/fingerdir/clients' file contains a list of
clients that the GNU Finger server `fingerd' is supposed to poll.  You
can edit this file and then send the finger server a `SIGHUP' to tell
it that the configuration has changed. Each line in the file should be
either the name of a host or a comment. The name can be preceded by
`@PORT', to tell the finger server to poll the particular host by using
a port other than 2003. A comment is any line that starts with a hash
sign (#). Below is a sample `clients' file:

     # This file contains all GNU Finger clients on the gnu.ai.mit.edu
     # network. Apple-gunkies is the GNU Finger server (see ``serverhost'').
     apple-gunkies.gnu.ai.mit.edu
     
     # Albert is the mail exchanger (see ``mailhost'').
     albert.gnu.ai.mit.edu
     
     # Spiff is a Sony, so port 2003 is already used for `mbanks'.
     # Use port 2010 instead.
     @2010 spiff.gnu.ai.mit.edu
     
     churchy.gnu.ai.mit.edu
     mole.gnu.ai.mit.edu
     geech.gnu.ai.mit.edu
     wookumz.gnu.ai.mit.edu
     nutrimat.gnu.ai.mit.edu
     kropotkin.gnu.ai.mit.edu
     goldman.gnu.ai.mit.edu
     hal.gnu.ai.mit.edu
     wombat.gnu.ai.mit.edu

   Although this sample `clients' file contains the fully qualified
domain names of the hosts, it's usually enough to specify only the host
name portion. Explicit IP addresses can be used too, but this is a
practise strongly discouraged. Notice that the server is also in the
clients file and has a `in.cfingerd'; this is necessary in order for
the server to correctly poll itself.

The `serverhost' file
---------------------

   The `/usr/local/etc/fingerdir/serverhost' file holds the name of the
GNU Finger server host; this is as the name implies, the host that the
GNU Finger server `fingerd' runs on. Lines starting with a hash sign
(#) are treated as comments. Below is a sample `serverhost' file:

     # A-g does all the finger stuff
     apple-gunkies.gnu.ai.mit.edu

The `mailhost' file
-------------------

   The `/usr/local/etc/fingerdir/mailhost' file holds the name of the
mail exchanger host for the network. This host should know how to talk
SMTP; this file should never hold the name of a host that can't. It's
contacted to obtain mail forwarding information and to expand mailing
lists if a `.forward' file can't be found in the user's home directory.
GNU Finger always looks and reports on user `.forward' files regardless
of whether `mailhost' exists or not. Any lines in this file that start
with a hash sign (#) are treated as comments.

The `forwardhost' file
----------------------

   The `/usr/local/etc/fingerdir/forwardhost' file holds the name of
the host to forward finger requests to when the current finger server
can't find a matching user name or mail alias. No forwarding takes place
if this file doesn't exist. Any lines that start with a hash sign (#)
are treated as comments. This is a sample output of what it can look
like when a request is forwarded:

     % finger -l nosuchuser@gnu.ai.mit.edu
     [No user nosuchuser@apple-gunkies.gnu.ai.mit.edu, forwarding
      request to life.ai.mit.edu]
     Login name: nosuchuser            In real life: ???

The `ttylocs' file
------------------

   The `/usr/local/etc/fingerdir/ttylocs' file holds explanations for
the hosts or terminal lines that users have logged in from or through.
Each client host has its own copy of this file. Each line consists of a
host name followed by a description. The name and description are
separated by one or more blanks or TABs.

     spiff.gnu.ai.mit.edu            NE43 Hall
     susie.gnu.ai.mit.edu            NE43 Sony 427 x8568
     spike.gnu.ai.mit.edu            NE43 Sony 427 x8568
     apple-gunkies.gnu.ai.mit.edu    NE43 427
     sugar-bombs.gnu.ai.mit.edu      Elsewhere
     pogo.gnu.ai.mit.edu             NE43 447
     albert.gnu.ai.mit.edu           Noisy Machine Room
     128.52.46.42                    The salt mines
     churchy.gnu.ai.mit.edu          NE43 426
     mole.gnu.ai.mit.edu             NE43 430
     geech.gnu.ai.mit.edu            NE43 426
     wookumz.gnu.ai.mit.edu          NE43 427
     calvin.gnu.ai.mit.edu           NE43
     gnu.gnu.ai.mit.edu              NE43
     kropotkin.gnu.ai.mit.edu        Total anarchy

Site Specific Functions
=======================

   If you are interested in customizing GNU Finger's output, then the
`lib/site' directory is the right place to start.  If you would like to
add new code for displaying faces, or have a particularly interesting
"long" information output format, I would be glad to include it as
unsupported code in the next release of GNU Finger.  (I will direct
correspondence regarding your code to you.) You can find other
contributed code in `lib/site', most notably different user info
formats and code to handle different bit map file formats. The only
file supported in `lib/site' is `userinfo.c'.

Configuration Options
=====================

   The following definitions in `config.h' control the behavior of GNU
Finger:

`SUPPORT_FINGERRC'
     Undefine to prevent users from writing `.fingerrc' scripts. Defined
     by default.

`CHECK_OWNER_FINGERRC'
     Define to make sure `.fingerrc' is owned by the user in whose
     directory it's found.

`CHECK_RDONLY_FINGERRC'
     Define to make sure `.fingerrc' isn't writable by anyone other than
     its owner.

`FINGERRC_SHELL'
     The shell to use to execute `.fingerrc'. Undefine to use user's
     login shell.

`DEFAULT_POLL_INTERVAL'
     Define to be the delay between polls, in seconds, unless an
     interval is explicitly given to `fingerd' with the `--interval'
     option.

`




BASENAME_IS_SERVICE'
     Undefine if you always want the finger client to use the `finger'
     service. Otherwise the service is deduced from the basename of the
     client. Defined by default.

`INFO_IS_DEFAULT'
     Define if you prefer `finger --info' to be the default, undefine if
     you prefer `finger --brief' to be the default.

GNU Finger Quick Reference
**************************

     finger OPTIONS USER@HOST

   Finger obtains information about USER on the remote system HOST. It
can also be used to obtain information about mailing lists and special
site-specific services.

   OPTIONS can be one or more of:

`--info'
`-i'
`-l'
     Return as much information as possible about USER.

`--brief'
`-b'
`-s'
     Only display current login info.

`--face'
`-f'
     Display a mugshot of USER. Not supported.

`--port PORT#'
`-P PORT#'
     Connect to the finger server using port or service PORT#.