                                THE MWP FILES
                                -------------
                                 File #2 of
                                  Issue #2

                                Summer of '97
                                -------------
                                

                            By StealthChip[MWP]
                                  6-10-97

                        "Protocols and Port Attacks."
                        -----------------------------
The TCP/IP suite, are trust worthy protocols. Meaning, they're easily lied to.
One common attack based off of TCP/IP suite is, "IP-Spoofing." Daemon9 |
route | infinity, wrote an article in Phrack about that very subject. If you
wish to see the article visit our www page-links section. But, in this article
speaking on protocols, I felt it important to skim the surface of IP-Spoofing.
You will get a glimse of how it works in this article. The rest of this paper
contains information about protocols and ports. This article was meant to
arouse the interest of the reader about the very subject. I do not go into
detail on seperate attacks.

Also Note:This is directed to novice areas of hacking, using protocols and
ports.

Excerpt of RFC #1060
The following is a list of protocols.

ip           IP       // Internet protocol
icmp         ICMP     // Internet control message protocol
ggp          GGP      // Gateway-gateway protocol
tcp          TCP      // Transmission control protocol*
egp          EGP      // Exterior gateway protocol
pup          PUP      // PARC universal packet protocol
udp          UDP      // User datagram protocol*
hmp          HMP      // Host monitoring protocol
xns-idp      XNS-IDP  // Xerox NS IDP
rdp          RDP      // "reliable datagram" protocol
rvd          RVD      // MIT remote virtual disk

A "conversation" between two protocols.
---------------------------------------
Protocols "speak" to eachother in packets. Packets can be assembled by us,
therefor resembling a 2-way connection when really there is only a 1-way
connection.
Situation:Site 1 wants to access site 2. Site 2 is checking if they have a
valid account on the system. They check the packet to see if they're from
a valid site, and they see the packet says they're from a valid site and
have access to root. So site 2 lets Site 1 access the system as root. 

The following are protocol MAN files. The purpose of these are to give you
an idea of how they work. The man files can do a far better job of that than
I can.

IP
--
SYNOPSIS
     #include <sys/socket.h>
     #include <netinet/in.h>
 
     s = socket(AF_INET, SOCK_RAW, proto);
 
     t = t_open ("/dev/rawip", O_RDWR);
 
DESCRIPTION
     IP is the internetwork datagram delivery  protocol  that  is
     central  to  the Internet protocol family.  Programs may use
     IP through higher-level protocols such as  the  Transmission
     Control  Protocol (TCP) or the User Datagram Protocol (UDP),
     or may interface directly to IP.  See tcp(7P)  and  udp(7P).
     Direct  access may be via the socket interface (using a "raw
     socket") or the Transport Level Interface (TLI).  The proto-
     col  options  defined  in the IP specification may be set in
     outgoing datagrams.
 
     The STREAMS driver /dev/rawip is the TLI transport  provider
     that provides raw access to IP.
 
     Raw IP sockets are connectionless and are normally used with
     the   sendto()   and  recvfrom()  calls  (see  send(3N)  and
     recv(3N)), although the connect(3N) call may also be used to
     fix  the destination for future datagrams (in which case the
     read(2) or recv(3N) and write(2) or send(3N)  calls  may  be
     used).   If proto is IPPROTO_RAW or IPPROTO_IGMP, the appli-
     cation is expected to include  a  complete  IP  header  when
     sending.   Otherwise,  that  protocol  number will be set in
     outgoing datagrams and used to filter incoming datagrams and
     an  IP header will be generated and prepended to each outgo-
     ing  datagram.   In  either  case,  received  datagrams  are
     returned with the IP header and options intact.
 
     The socket options supported at the IP level are:
 
     IP_OPTIONS               IP options for outgoing  datagrams.
                              This  socket  option may be used to
                              set IP options to  be  included  in
                              each outgoing datagram.  IP options
                              to  be  sent  are  set  with   set-
                              sockopt()   (see   getsockopt(3N)).
                              The getsockopt(3N) call returns the
                              IP  options  set  in  the last set-
                              sockopt()  call.   IP  options   on
                              received  datagrams  are visible to
                              user programs  only  using  raw  IP
                              sockets.   The format of IP options
                              given in setsockopt() matches those
                              defined  in  the  IP  specification
                              with one exception:   the  list  of
                              addresses  for  the  source routing
                              options must include the  first-hop
                              gateway  at  the  beginning  of the
                              list of  gateways.   The  first-hop
                              gateway  address  will be extracted
                              from the option list and  the  size
                              adjusted  accordingly  before  use.
                              IP options may  be  used  with  any
                              socket type in the Internet family.
 
     IP_ADD_MEMBERSHIP        Join a multicast group.
 
     IP_DROP_MEMBERSHIP       Leave a multicast group.
 
     These options take a struct ip_mreq as the  parameter.   The
     structure  contains  a multicast address which has to be set
     to the  CLASS-D  IP  multicast  address,  and  an  interface
     address. Normally the interface address is set to INADDR_ANY
     which causes the kernel to choose the interface to join on.
 
     IP_MULTICAST_IF          The outgoing interface  for  multi-
                              cast  packets.  This option takes a
                              struct in_addr as an  argument  and
                              it  selects that interface for out-
                              going IP multicast packets.  If the
                              address  specified is INADDR_ANY it
                              will use the unicast routing  table
                              to  select  the  outgoing interface
                              (which is the default behavior).
 
     IP_MULTICAST_TTL         Time   to   live   for    multicast
                              datagrams.   This  option  takes an
                              unsigned character as an  argument.
                              Its  value  is the TTL that IP will
                              use    on    outgoing     multicast
                              datagrams.  The default is 1.
 
     IP_MULTICAST_LOOP        Loopback for  multicast  datagrams.
                              Normally  multicast  datagrams  are
                              delivered to members on the sending
                              host.  Setting the unsigned charac-
                              ter argument to 0  will  cause  the
                              opposite behavior.
 
     The multicast socket options can be used with  any  datagram
     socket type in the Internet family.
 
     At the socket level, the socket option SO_DONTROUTE  may  be
     applied.   This option forces datagrams being sent to bypass
     routing and forwarding by forcing the IP Time To Live  field
     to  1  (meaning  that  the  packet  will not be forwarded bu
     routers).
 
     Raw IP datagrams can also be sent and received using the TLI
     connectionless primitives.
 
     Datagrams flow through the IP layer in two directions:  from
     the  network  up  to  user processes and from user processes
     down to the network.  Using this orientation, IP is  layered
     above  the network interface drivers and below the transport
     protocols such as UDP and TCP. The Internet Control  Message
     Protocol (ICMP) is logically a part of IP. See icmp(7P).
 
     IP provides for a checksum of the header part, but  not  the
     data  part  of the datagram.  The checksum value is computed
     and set in the process of sending datagrams and checked when
     receiving datagrams.
 
     IP options in received datagrams are  processed  in  the  IP
     layer  according  to  the protocol specification.  Currently
     recognized IP options include:  security, loose  source  and
     record  route (LSRR), strict source and record route (SSRR),
     record route, and internet timestamp.
 
     The IP layer will  normally  act  as  a  router  (forwarding
     datagrams that are not addressed to it etc) when the machine
     has two or more interfaces that are up. This behavior can be
     overridden  by  using ndd(1M) to to set the /dev/ip variable
     ip_forwarding.  The value 0 means do not  forward,  1  means
     forward  and  2 gives you the default behavior of forwarding
     when there are two or more "up" interfaces.
 
     The IP layer will send an ICMP message back  to  the  source
     host  in many cases when it receives a datagram that can not
     be handled.  A "time exceeded" ICMP message will be sent  if
     the  "time  to live" field in the IP header drops to zero in
     the  process  of  forwarding  a  datagram.   A  "destination
     unreachable"  message  will be sent if a datagram can not be
     forwarded because there is no route to  the  final  destina-
     tion,  or  if  it can not be fragmented.  If the datagram is
     addressed to the local host but is destined for  a  protocol
     that is not supported or a port that is not in use, a desti-
     nation unreachable message will also be sent.  The IP  layer
     may  send an ICMP "source quench" message if it is receiving
     datagrams too quickly.  ICMP messages are only sent for  the
     first  fragment  of  a  fragmented  datagram  and  are never
     returned in response to errors in other ICMP messages.
 
     The  IP  layer  supports   fragmentation   and   reassembly.
     Datagrams are fragmented on output if the datagram is larger
     than the maximum transmission  unit  (MTU)  of  the  network
     interface.  Fragments of received datagrams are dropped from
     the reassembly queues if the complete datagram is not recon-
     structed within a short time period.
 
     Errors in sending discovered at the network interface driver
     layer are passed by IP back up to the user process.
 
SEE ALSO
     ndd(1M),  read(2),  write(2),  connect(3N),  getsockopt(3N),
     recv(3N),   send(3N),   routing(4),   icmp(7P),  if_tcp(7P),
     inet(7P) tcp(7P), udp(7P)
 
     Postel, Jon, Internet Protocol - DARPA Internet Program Pro-
     tocol  Specification,  RFC  791, Network Information Center,
     SRI International, Menlo Park, Calif., September 1981.
 
DIAGNOSTICS
     A socket operation may fail with one of the following errors
     returned:
 
     EACCES              An IP broadcast destination address  was
                         specified  and  the  caller  was not the
                         privileged user.
 
     EISCONN             An attempt was made to establish a  con-
                         nection  on  a  socket which already had
                         one, or to send a datagram with the des-
                         tination   address   specified  and  the
                         socket was already connected.
 
     EMSGSIZE            An attempt was made to send  a  datagram
                         that was too large for an interface, but
                         was not allowed to be  fragmented  (such
                         as broadcasts).
 
     ENETUNREACH         An attempt was made to establish a  con-
                         nection  or send a datagram, where there
                         was no matching  entry  in  the  routing
                         table,   or   if  an  ICMP  "destination
                         unreachable" message was received.
 
     ENOTCONN            A datagrem was sent, but no  destination
                         address  was  specified,  and the socket
                         had not been connected.
 
     ENOBUFS             The system ran out of memory  for  frag-
                         mentation buffers or other internal data
                         structure.
 
     EADDRNOTAVAIL       An attempt was made to create  a  socket
                         with  a local address that did not match
                         any  network   interface,   or   an   IP
                         broadcast destination address was speci-
                         fied and the network interface does  not
                         support broadcast.
 
ERRORS
     The following errors may occur when setting  or  getting  IP
     options:
 
     EINVAL         An unknown socket option name was given.
 
     EINVAL         The IP option field was improperly formed; an
                    option  field  was  shorter  than the minimum
                    value or longer than the option  buffer  pro-
                    vided.
 
NOTES
     Raw sockets should receive ICMP error  packets  relating  to
     the protocol; currently such packets are simply discarded.
 
     Users of higher-level protocols such as TCP and  UDP  should
     be able to see received IP options.

TCP
---
NAME
     tcp, TCP - Internet Transmission Control Protocol
 
SYNOPSIS
     #include <sys/socket.h>
 
     #include <netinet/in.h>
 
     s = socket(AF_INET, SOCK_STREAM, 0);
 
     t = t_open("/dev/tcp", O_RDWR);
 
DESCRIPTION
     TCP is the virtual circuit protocol of the Internet protocol
     family.   It  provides  reliable, flow-controlled, in order,
     two-way transmission of data.  It is a byte-stream  protocol
     layered  above the Internet Protocol (IP), the Internet pro-
     tocol family's internetwork datagram delivery protocol.
 
     Programs can access TCP using  the  socket  interface  as  a
     SOCK_STREAM socket type, or using the Transport Level Inter-
     face  (TLI)  where  it  supports   the   connection-oriented
     (T_COTS_ORD) service type.
 
     TCP uses IP's host-level addressing and adds  its  own  per-
     host collection of "port addresses."  The endpoints of a TCP
     connection are  identified  by  the  combination  of  an  IP
     address  and  a  TCP port number.  Although other protocols,
     such as the User Datagram Protocol (UDP), may use  the  same
     host and port address format, the port space of these proto-
     cols is distinct.  See inet(7P) for details  on  the  common
     aspects of addressing in the Internet protocol family.
 
     Sockets utilizing TCP  are  either  "active"  or  "passive".
     Active  sockets  initiate  connections  to  passive sockets.
     Both types of sockets must have their local IP  address  and
     TCP  port  number  bound with the bind(3N) system call after
     the socket is created.  By default, TCP sockets are  active.
     A passive socket is created by calling the listen(3N) system
     call after binding the socket with bind().  This establishes
     a  queueing  parameter  for the passive socket.  After this,
     connections to the passive socket can be received  with  the
     accept(3N)  system call.  Active sockets use the connect(3N)
     call after binding to initiate connections.
 
     By using the special value INADDR_ANY, the local IP  address
     can  be left unspecified in the bind() call by either active
     or passive TCP sockets.  This feature is usually used if the
     local  address  is  either  unknown  or irrelevant.  If left
     unspecified, the local IP address will be bound  at  connec-
     tion  time  to  the address of the network interface used to
     service the connection.
 
     Once  a  connection  has  been  established,  data  can   be
     exchanged using the read(2) and write(2) system calls.
 
     TCP supports one  socket  option  which  is  set  with  set-
     sockopt()  and  tested with getsockopt(3N).  Under most cir-
     cumstances, TCP sends data when it is presented.  When  out-
     standing  data  has  not  yet  been acknowledged, it gathers
     small amounts of output to be sent in a single  packet  once
     an  acknowledgement  is  received.   For  a  small number of
     clients, such as window systems that send a stream of  mouse
     events  which  receive  no  replies,  this packetization may
     cause significant delays.
 
     Therefore,  TCP  provides  a  boolean  option,   TCP_NODELAY
     (defined in <netinet/tcp.h>), to defeat this algorithm.  The
     option level for  the  setsockopt()  call  is  the  protocol
     number for TCP, available from getprotobyname(3N).
 
     Options at the IP level may be used with TCP. See ip(7P).
 
     TCP provides an urgent data mechanism, which may be  invoked
     using  the  out-of-band  provisions of send(3N).  The caller
     may mark one byte as  "urgent"  with  the  MSG_OOB  flag  to
     send(3N).   This  sets  an "urgent pointer" pointing to this
     byte in the TCP stream.  The receiver on the other  side  of
     the  stream  is notified of the urgent data by a SIGURG sig-
     nal.  The SIOCATMARK ioctl() request returns a  value  indi-
     cating  whether  the  stream is at the urgent mark.  Because
     the system never returns data across the urgent  mark  in  a
     single read(2) call, it is possible to advance to the urgent
     data in a simple loop which reads data, testing  the  socket
     with  the  SIOCATMARK  ioctl() request, until it reaches the
     mark.
 
     Incoming connection requests that include an IP source route
     option  are  noted,  and the reverse source route is used in
     responding.
 
     A checksum over all data helps  TCP  implement  reliability.
     Using  a  window-based flow control mechanism that makes use
     of  positive  acknowledgements,  sequence  numbers,  and   a
     retransmission   strategy,  TCP  can  usually  recover  when
     datagrams are damaged, delayed, duplicated or delivered  out
     of order by the underlying communication medium.
 
     If the local TCP receives no acknowledgements from its  peer
     for  a  period  of  time, as would be the case if the remote
     machine crashed, the connection is closed and  an  error  is
     returned to the user.  If the remote machine reboots or oth-
     erwise loses state information about a TCP  connection,  the
     connection is aborted and an error is returned to the user.
 
SEE ALSO
     read(2),  write(2),   accept(3N),   bind(3N),   connect(3N),
     getprotobyname(3N),  getsockopt(3N),  listen(3N),  send(3N),
     inet(7P), ip(7P)
 
     Postel, Jon, Transmission Control Protocol - DARPA  Internet
     Program Protocol Specification, RFC 793, Network Information
     Center, SRI International,  Menlo  Park,  Calif.,  September
     1981.
 
DIAGNOSTICS
     A socket operation may fail if:
 
     EISCONN             A connect() operation was attempted on a
                         socket  on  which  a connect() operation
                         had already been performed.
 
     ETIMEDOUT           A connection was dropped due  to  exces-
                         sive retransmissions.
 
     ECONNRESET          The remote peer forced the connection to
                         be  closed  (usually  because the remote
                         machine has lost state information about
                         the connection due to a crash).
 
     ECONNREFUSED        The remote peer actively refused connec-
                         tion  establishment  (usually because no
                         process is listening to the port).
 
     EADDRINUSE          A bind() operation was  attempted  on  a
                         socket  with a network address/port pair
                         that has already been bound  to  another
                         socket.
 
     EADDRNOTAVAIL       A bind() operation was  attempted  on  a
                         socket  with a network address for which
                         no network interface exists.
 
     EACCES              A bind() operation was attempted with  a
                         "reserved" port number and the effective
                         user ID  of  the  process  was  not  the
                         privileged user.
 
     ENOBUFS             The system ran out of memory for  inter-
                         nal data structures.
 
UDP
---
NAME
     udp, UDP - Internet User Datagram Protocol
 
SYNOPSIS
     #include <sys/socket.h>
 
     #include <netinet/in.h>
 
     s = socket(AF_INET, SOCK_DGRAM, 0);
 
     t = t_open("/dev/udp", O_RDWR);
 
DESCRIPTION
     UDP is a simple datagram protocol which is layered  directly
     above  the  Internet Protocol (IP).  Programs may access UDP
     using the socket interface, where it supports the SOCK_DGRAM
     socket  type,  or using the Transport Level Interface (TLI),
     where it supports the connectionless (T_CLTS) service type.
 
     Within the socket interface, UDP is normally used  with  the
     sendto(),  sendmsg(),  recvfrom(),  and recvmsg() calls (see
     send(3N) and recv(3N)).  If the connect(3N) call is used  to
     fix the destination for future packets, then the recv(3N) or
     read(2) and send(3N) or write(2) calls may be used.
 
     UDP address formats are  identical  to  those  used  by  the
     Transmission  Control  Protocol (TCP).  Like TCP, UDP uses a
     port number along with an IP address to  identify  the  end-
     point  of  communication.   The  UDP  port  number  space is
     separate from the TCP port number space (that is, a UDP port
     may  not  be  "connected" to a TCP port).  The bind(3N) call
     can be used to set the local address and port  number  of  a
     UDP socket.  The local IP address may be left unspecified in
     the bind() call by using the special value  INADDR_ANY.   If
     the  bind()  call  is  not done, a local IP address and port
     number will be assigned  to  the  endpoint  when  the  first
     packet is sent.  Broadcast packets may be sent (assuming the
     underlying  network  supports  this)  by  using  a  reserved
     "broadcast  address";  This  address  is  network  interface
     dependent.  Broadcasts may only be sent  by  the  privileged
     user.
 
     Options at the IP level may be used with UDP; see ip(7P).
 
     There are a variety of ways that a UDP packet can be lost or
     corrupted,  including a failure of the underlying communica-
     tion mechanism.  UDP implements a  checksum  over  the  data
     portion of the packet.  If the checksum of a received packet
     is in error, the packet will be dropped with  no  indication
     given  to the user.  A queue of received packets is provided
     for each UDP socket.  This queue  has  a  limited  capacity.
     Arriving  datagrams which will not fit within its high-water
     capacity are silently discarded.
 
     UDP processes Internet Control Message Protocol (ICMP) error
     messages  received  in  response to UDP packets it has sent.
     See icmp(7P).  ICMP "source quench"  messages  are  ignored.
     ICMP "destination unreachable," "time exceeded" and "parame-
     ter problem" messages disconnect the socket from its peer so
     that  subsequent  attempts to send packets using that socket
     will return an error.  UDP will not guarantee  that  packets
     are  delivered in the order they were sent.  As well, dupli-
     cate packets may be generated in the communication process.
 
SEE ALSO
     read(2),   write(2),   bind(3N),   connect(3N),    recv(3N),
     send(3N), icmp(7P), inet(7P), ip(7P), tcp(7P)
 
     Postel, Jon, User Datagram Protocol, RFC 768, Network Infor-
     mation Center, SRI International, Menlo Park, Calif., August
     1980
 
DIAGNOSTICS
     A socket operation may fail if:
 
     EISCONN             A connect() operation was attempted on a
                         socket  on  which  a connect() operation
                         had  already  been  performed,  and  the
                         socket could not be successfully discon-
                         nected before making the new connection.
 
     EISCONN             A sendto() or sendmsg() operation speci-
                         fying  an  address  to which the message
                         should be sent was attempted on a socket
                         on   which  a  connect()  operation  had
                         already been performed.
 
     ENOTCONN            A send()  or  write()  operation,  or  a
                         sendto()   or  sendmsg()  operation  not
                         specifying an address to which the  mes-
                         sage  should be sent, was attempted on a
                         socket on which  a  connect()  operation
                         had not already been performed.
 
     EADDRINUSE          A bind() operation was  attempted  on  a
                         socket  with a network address/port pair
                         that has already been bound  to  another
                         socket.
 
     EADDRNOTAVAIL       A bind() operation was  attempted  on  a
                         socket  with a network address for which
                         no network interface exists.
 
     EINVAL              A sendmsg() operation  with  a  non-NULL
                         msg_accrights was attempted.
 
     EACCES              A bind() operation was attempted with  a
                         "reserved" port number and the effective
                         user ID  of  the  process  was  not  the
                         privileged user.
 
     ENOBUFS             The system ran out of memory for  inter-
                         nal data structures.
 
ICMP
----
NAME
     icmp, ICMP - Internet Control Message Protocol
 
SYNOPSIS
     #include <sys/socket.h>
 
     #include <netinet/in.h>
 
     #include <netinet/ip_icmp.h>
 
     s = socket(AF_INET, SOCK_RAW, proto);
 
     t = t_open("/dev/icmp", O_RDWR);
 
DESCRIPTION
     ICMP is the error and control message protocol used  by  the
     Internet  protocol family.  It is used by the kernel to han-
     dle and report errors in protocol processing.  It  may  also
     be  accessed  by  programs using the socket interface or the
     Transport Level Interface (TLI) for network  monitoring  and
     diagnostic  functions.  When used with the socket interface,
     a "raw socket" type is used.  The protocol number for  ICMP,
     used  in  the  proto  parameter  to  the socket call, can be
     obtained from getprotobyname(3N).  ICMP file descriptors and
     sockets  are  connectionless, and are normally used with the
     t_sndudata / t_rcvudata and the sendto() / recvfrom() calls.
 
     Outgoing packets automatically  have  an  Internet  Protocol
     (IP)  header  prepended  to them.  Incoming packets are pro-
     vided to the user with the IP header and options intact.
 
     ICMP is an datagram protocol layered above IP.  It  is  used
     internally  by the protcol code for various purposes includ-
     ing  routing,  fault  isolation,  and  congestion   control.
     Receipt  of  an ICMP "redirect" message will add a new entry
     in the routing table, or modify an existing one.  ICMP  mes-
     sages  are  routinely  sent  by the protocol code.  Received
     ICMP messages may be reflected back to users of higher-level
     protocols  such  as  TCP or UDP as error returns from system
     calls.  A copy of all ICMP message received by the system is
     provided  to  every  holder  of  an  open ICMP socket or TLI
     descriptor.
 
SEE ALSO
     getprotobyname(3N),  recv(3N),   send(3N),   t_rcvudata(3N),
     t_sndudata(3N), routing(4), inet(7P), ip(7P)
 
     Postel, Jon,  Internet  Control  Message  Protocol  -  DARPA
     Internet  Program  Protocol  Specification, RFC 792, Network
     Information Center, SRI International, Menlo  Park,  Calif.,
     September 1981.

DIAGNOSTICS
     A socket operation may fail with one of the following errors
     returned:
 
     EISCONN             An attempt was made to establish a  con-
                         nection  on  a  socket which already has
                         one, or when trying to send  a  datagram
                         with  the  destination address specified
                         and the socket is already connected.
 
     ENOTCONN            An attempt was made to send a  datagram,
                         but no destination address is specified,
                         and the socket has not been connected.
 
     ENOBUFS             The system ran  out  of  memory  for  an
                         internal data structure.
 
     EADDRNOTAVAIL       An attempt was made to create  a  socket
                         with a network address for which no net-
                         work interface exists.
 
NOTES
     Replies to ICMP "echo" messages which are source routed  are
     not  sent  back  using inverted source routes, but rather go
     back through the normal routing mechanisms.
 
Importance of host files.
-------------------------
Consider the following. Your quite popular on BBSes and various machines. You
constantly rlogin-Remote Login-to remote systems daily. But there appears to
be a very annoying Login daemon popping up whenever you login to the remote
system. So, in response you add to your .rhosts file and make it so no
more Login Daemons pop up on remote systems.(Expecting your Username and
Password are the same on all systems your logging into. AND, the system allows
you to rlogin without verification.)
As mentioned above, it's possible to use the *r commands without Login Daemons
popping up. But, in order to due so, the host your logging into MUST have
your account information saved in the /etc/hosts.equiv file.
When IP-Spoofing a system(remember, we're not going into detail here, just
skimming the surface)your attack relies in forging packets.

.rhosts file--The .rhosts file is setup so users don't always have to put in
their login and password. It lets them straight onto the system.

/etc/hosts.equiv file--This file is used by all the users on the system. It
contains login information about users on friendly hosts. In some cases an
account is setup for use by users of a friendly network.
This file is like giving your friend a key to your house.

 
 
Ports.
------
Ports are set up areas for daemons. When using Telnet, you can connect
to a certain port by typing the following,

Prompt>telnet (domainname or IP address) (port)

Open ports or channels leave backdoors available for us. Most ports are
left off, or run certain daemon programs on them. Making a "backdoor" is done
when you get root and then leave another port-that's being unused or is just
sharing the port with another daemon- open for later use by us.

The command "netstat" contains information about ports. ie, on or off. You
can turn a port back on when logged on as root; therefor leaving it open for
later use by yourself.

Some commonly used port attacks are the sendmail bug, rdist, and Protocol
-Spoofing techniques. These attacks may still work today but are quickly
becoming unused due to the CERT-Computer Emergency Response Team-.(But like
always, lazy sysadmins do not always follow these warnings.)

The best port attacks come from remote commands, ie rdist, rlogin, rmail, etc.

The following is a list of ports and their service/protocol being used on
it.

Format:
<service name>  <port number>/<protocol> <program/server> <//comment>  
*=Very useful.

echo                7/tcp
echo                7/udp
discard             9/tcp    
discard             9/udp    
systat             11/tcp
systat             11/tcp    
daytime            13/tcp
daytime            13/udp
netstat            15/tcp
qotd               17/tcp    
qotd               17/udp    
chargen            19/tcp    
chargen            19/udp    
ftp-data           20/tcp
ftp                21/tcp
telnet             23/tcp                  //Connects you to Login daemon.
smtp               25/tcp    mail          //Mail port.
time               37/tcp    timserver
time               37/udp    timserver
rlp                39/udp    resource      //resource location
name               42/tcp    nameserver
name               42/udp    nameserver
whois              43/tcp    nicname       //usually to sri-nic
domain             53/tcp    nameserver    //name-domain server
domain             53/udp    nameserver
nameserver         53/tcp    domain        //name-domain server
nameserver         53/udp    domain
mtp                57/tcp                  //deprecated
bootp              67/udp                  //boot program server
tftp               69/udp
rje                77/tcp    netrjs
finger             79/tcp
link               87/tcp    ttylink
supdup             95/tcp
hostnames         101/tcp    hostname      //usually from sri-nic
iso-tsap          102/tcp
dictionary        103/tcp    webster
x400              103/tcp                  //ISO Mail
x400-snd          104/tcp
csnet-ns          105/tcp
pop               109/tcp    postoffice
pop2              109/tcp                  //Post Office
pop3              110/tcp    postoffice
portmap           111/tcp
portmap           111/udp
sunrpc            111/tcp
sunrpc            111/udp
auth              113/tcp    authentication
sftp              115/tcp
path              117/tcp
uucp-path         117/tcp
nntp              119/tcp    usenet        //Network News Transfer
ntp               123/udp    ntpd ntp      //network time protocol (exp)
nbname            137/udp
nbdatagram        138/udp
nbsession         139/tcp
NeWS              144/tcp    news
sgmp              153/udp    sgmp
tcprepo           158/tcp    repository    //PCMAIL
snmp              161/udp    snmp
snmp-trap         162/udp    snmp
print-srv         170/tcp                  //network PostScript
vmnet             175/tcp
load              315/udp
vmnet0            400/tcp
sytek             500/udp
biff              512/udp    comsat
exec              512/tcp
login             513/tcp
who               513/udp    whod
shell             514/tcp    cmd           //no passwords used*
syslog            514/udp
printer           515/tcp    spooler       //line printer spooler
talk              517/udp
ntalk             518/udp
efs               520/tcp                  //for LucasFilm
route             520/udp    router routed
timed             525/udp    timeserver
tempo             526/tcp    newdate
courier           530/tcp    rpc
conference        531/tcp    chat
rvd-control       531/udp    MIT disk
netnews           532/tcp    readnews
netwall           533/udp                  //-for emergency broadcasts
uucp              540/tcp    uucpd         //uucp daemon*
klogin            543/tcp                  //Kerberos authenticated rlogin
kshell            544/tcp    cmd           //and remote shell****
new-rwho          550/udp    new-who       //experimental
remotefs          556/tcp    rfs_server rfs//Brunhoff remote filesystem
rmonitor          560/udp    rmonitord     //experimental
monitor           561/udp                  //experimental
garcon            600/tcp
maitrd            601/tcp
busboy            602/tcp
acctmaster        700/udp
acctslave         701/udp
acct              702/udp
acctlogin         703/udp
acctprinter       704/udp
elcsd             704/udp                  //errlog*
acctinfo          705/udp
acctslave2        706/udp
acctdisk          707/udp
kerberos          750/tcp    kdc           //Kerberos authentication--tcp
kerberos          750/udp    kdc           //Kerberos authentication--udp
kerberos_master   751/tcp                  //Kerberos authentication
kerberos_master   751/udp                  //Kerberos authentication
passwd_server     752/udp                  //Kerberos passwd server*
userreg_server    753/udp                  //Kerberos userreg server*
krb_prop          754/tcp                  //Kerberos slave propagation
erlogin           888/tcp                  //Login and environment passing*
kpop             1109/tcp                  //Pop with Kerberos
phone            1167/udp
ingreslock       1524/tcp
maze             1666/udp
nfs              2049/udp                  //sun nfs
knetd            2053/tcp                  //Kerberos de-multiplexor
eklogin          2105/tcp                  //Kerberos encrypted rlogin*****
rmt              5555/tcp    rmtd
mtb              5556/tcp    mtbd          //mtb backup
man              9535/tcp                  //remote man server*
w                9536/tcp
mantst           9537/tcp                  //remote man server, testing
bnews           10000/tcp
rscs0           10000/udp
queue           10001/tcp
rscs1           10001/udp
poker           10002/tcp
rscs2           10002/udp
gateway         10003/tcp
rscs3           10003/udp
remp            10004/tcp
rscs4           10004/udp
rscs5           10005/udp
rscs6           10006/udp
rscs7           10007/udp
rscs8           10008/udp
rscs9           10009/udp
rscsa           10010/udp
rscsb           10011/udp
qmaster         10012/tcp
qmaster         10012/udp

RFC 1140 SunOS Network style.
tcpmux          1/tcp
echo            7/tcp
echo            7/udp
discard         9/tcp           sink null
discard         9/udp           sink null
systat          11/tcp          users
daytime         13/tcp
daytime         13/udp
netstat         15/tcp
chargen         19/tcp          ttytst source
chargen         19/udp          ttytst source
ftp-data        20/tcp
ftp             21/tcp
telnet          23/tcp
smtp            25/tcp          mail
time            37/tcp          timserver
time            37/udp          timserver
name            42/udp          nameserver
whois           43/tcp          nicname         //usually to sri-nic
domain          53/udp
domain          53/tcp
hostnames       101/tcp         hostname        //usually to sri-nic
sunrpc          111/udp         rpcbind
sunrpc          111/tcp         rpcbind
ident           113/tcp         auth     tap
netbios-ssn     139/tcp
netbios-ns      137/udp
tftp            69/udp
rje             77/tcp
finger          79/tcp
link            87/tcp          ttylink
supdup          95/tcp
iso-tsap        102/tcp
x400            103/tcp                         //ISO Mail
x400-snd        104/tcp
csnet-ns        105/tcp
pop-2           109/tcp                         //Post Office
pop3            110/tcp                         //Post Office 3
uucp-path       117/tcp
nntp            119/tcp         usenet          //Network News Transfer
ntp             123/tcp                         //Network Time Protocol
ntp             123/udp                         //Network Time Protocol
NeWS            144/tcp         news            //Window System
exec            512/tcp
login           513/tcp
shell           514/tcp         cmd             //no passwords used
printer         515/tcp         spooler         //line printer spooler
courier         530/tcp         rpc             //experimental
uucp            540/tcp         uucpd           //uucp daemon
biff            512/udp         comsat
who             513/udp         whod
syslog          514/udp
talk            517/udp
ntalk           518/udp
route           520/udp         router routed
new-rwho        550/udp         new-who         //experimental
rmonitor        560/udp         rmonitord       //experimental
monitor         561/udp                         //experimental
pcserver        600/tcp                     //ECD Integrated PC board srvr
kerberos        750/udp         kdc             //Kerberos key server
kerberos        750/tcp         kdc             //Kerberos key server
ufsd            1008/tcp        ufsd            //UFS-aware server
ufsd            1008/udp        ufsd
ingreslock      1524/tcp
radacct         1646/udp                        //more RADIUS
listen          2766/tcp                        //System V listener port
nfsd            2049/udp        nfs             //NFS server daemon (clts)
nfsd            2049/tcp        nfs             //NFS server daemon (cots)
lockd           4045/udp                        //NFS lock daemon/manager
lockd           4045/tcp
dtspc           6112/tcp                        //CDE subprocess control
fs              7100/tcp                        //Font server
pmd             1642/tcp
hylafax         4559/tcp                //HylaFAX client-server protocol
snpp            444/tcp         //Simple Network Paging Protocol
noclog          5354/udp
hostmon         5355/tcp
radius          1645/udp
------------------------
TCP and UDP are like delivery service. They carry things around the network to
perform tasks and make sure things are delivered on time and to the right
place. But they do not worry if anyones there to recieve their message. They
just drop it off where they were told to and leave.

Best Ports to attack are r* commands. They answer back to eachother based
on trust-relationship's. Meaning, they're easily lied to. You can forge
packets to (R)emote your way around systems. It's good to have root on the
system your attacking from.

An example of a port exploit.
-----------------------------
Telnet to port 25 of the machine you want to send mail from, and type,

 HELO <host name>(The name you want the mail to appear from.)
 MAIL FROM:<handle@hostname>
 RCPT TO:<person@hostname>*The person you want to mail.
 DATA
     <You write what you want to appear.>
 .   (Make sure the period is on a line by itself.)
 QUIT

*That exploit is quite old and may not work on *all systems.

Books you should get up and get now.
------------------------------------
TCP/IP Illustrated volume(s) 1, 2, 3.
TCP/IP Administration hand book.

Now that you have a list of ports and possible attack ideas, I suggest you use
your coding skills and write up some exploits on ports and protocols.
If I would've given you my code for port exploits you wouldn't truly be a
hacker, you'd just be a nobody using StealthChip's(my) code.

StealthChip@juno.com

EOF






