____\\\\/________ _________________ | | \\| _/ _/ | 99999999999999 |_______|___\\ | __| | | 9999990 99999999 | _| \\___|_____|________|_________ 999990 999999999 |_____ \\ | | _| | _ | 999990 99999999 | | | | | | | __/ 9999999999 \\________/________|____|______ |_______| 999999999 |_______| 999999999 .. : :......................... :. .......................: :.............................. : : .: Official Web Site - http://infosurge.rendrag.net : : : : Official Submissions - phase5@cmdrkeen.net : : Issue Editor - lym@thepentagon.com :. `: : : Issue #9: Tuesday, April 10th, 2001 ......: : ..:... :..................................שש..............: : :....... `שש' : ...:..................................... : : : .........................:............ :... : ..contents : ....שש.............:...........:...... : : `שש' : ..:.. : : :.:.; : : : : : 001 An Overview of OpenBSD Security Satyricon : : 002 Intel's x86 CPU Maticles : : 003 Iptables for Linux 2.4 Technion :. : 004 Advanced JavaScript Methods lymco : : 005 IIS Security black-hand : : 006 Overview of Recent and Future Hardware Maticles ..: : 007 Tunnelling SSH via HTTP tengu : : 008 HP-UX and the HP-9000/800 Series Unix server Kayjay : .: 009 Phreaks, Geeks, and the inbetweens Rendrag : .:., :. : : TOTAL (113kb) : : : : `..: .....:.. . :..................שש............................................:..: ; .; `שש' :..; : :... ..:............................................ : : : 001 An Overview of OpenBSD Security : : ...:. . :.:.. by Satyricon : : :.:.;................;........................:.: : ;. . .. . ..;. . : ; ; ; OpenBSD is often noted for its code auditing and integrated crypto, but the security features go far beyond this. OpenBSD was built from the ground up on the model of being a fabric woven with security in mind, not a patchwork of bug fixes and security updates. This has led to OpenBSD finally being recognized today for what it is: the most secure operating system on earth. This article aims to illustrate these features and provide practical examples of their implication on production machines. Encryption One of the most astounding things about the information superhighway is the number of people driving down it with their doors unlocked. Users and even administrators still commonly employ systems where sensitive information such as financial records and personal details are thrown over public networks as clear text. This is largely due to the proliferation of cleartext protocols such as telnet, rlogin, and http. OpenBSD solves these issues by containing encrypted replacements by default: OpenSSH for telnet and rlogin and https (OpenSSL). One of the first configuration tasks for an OpenBSD administrator should be the correct setup of ssh and ssl to ensure system security. OpenSSH is configured via two primary configuration files; some useful excerpts of those files follow: /etc/ssh_config (OpenSSH client configuration): UseRsh no FallBackToRsh no # OpenSSH will never fall back # to the cleartext RSH protocol. ForwardX11 no # Do not allow X windows forwarding # through the SSH session. /etc/sshd_config (OpenSSH server configuration): Port 22 ListenAddress 0.0.0.0 # Listen on all active interfaces HostKey /etc/ssh_host_key # Store the key in the default location ServerKeyBits 1664 # Generate a 1664 bit key (stronger # crypto than by default) LoginGraceTime 600 # Allow 600 seconds for a client to login KeyRegenerationInterval 3600 # Generate a new key every 3600 # seconds (hourly) PermitRootLogin no # Do not allow clients to login directly as # root, must use su X11Forwarding no # Do not allow X windows forwarding through # the SSH session. PermitEmptyPasswords no # A password MUST be issued - no passwordless # logins allowed. With SSH configured using these or similar options, the next step in enabling OpenBSD crypto is to set up OpenSSL-based https. This is a good replacement to cleartext http when sensitive information is being parsed through CGI POSTs or similar methods. The official documentation for mod_ssl (located by default in /var/www/htdocs/manual/mod/mod_ssl/ on OpenBSD systems) provides more detailed configuration information, but the process is three relatively simple steps: 1. Generate a server key and self-signed x.509 certificate: * Generate a server.key: openssl genrsa -des3 -out server.key 1024 Place this file in /etc/ssl * Generate a CSR (Certificate Signing Request): openssl req -new -key server.key -out server.csr Place this file in /etc/ssl * Generate an RSA key for your CA (Certificate Authority): openssl genrsa -des3 -out ca.key 1024 Place this file in /etc/ssl * Generate an x.509 certificate for your CA: openssl req -new -x509 -days 365 -key ca.key -out ca.crt Place this file in /etc/ssl * Sign your CSR: * Sign your CSR: ./sign.sh server.crt sign.sh comes packaged with the OpenSSL source distribution. 2. Edit /var/www/httpd.conf: In the main section: Listen 80 Listen 443 AddType application/x-x509-ca-cert .crt AddType application/x-pkcs7-crl .crl A tag for your domain: # General setup for the virtual host DocumentRoot /home/www/vhost/www.mydomain.net/htdocs ServerName www.mydomain.net ServerAdmin admin@mydomain.net ErrorLog logs/error_log TransferLog logs/access_log # SSL Engine Switch: # Enable/Disable SSL for this virtual host. SSLEngine on SSLCertificateFile /etc/ssl/server.crt SSLCertificateKeyFile /etc/ssl/server.key 3. Edit /etc/rc.conf to enable https: * httpd_flags="-DSSL" Code auditing One of the largest problems with systems such as Linux is the inclusion of unchecked third party software. If a vulnerability or security issue arises, the third party must release a patch and the operating system vendor must then redistribute this patch to their users. Not only this, but the third party software is not in any way audited or checked for quality by the operating system vendors and as such can be vulnerable for a long time before any sort of fix is available to users (as happened numerous times with wu-ftpd). One of the major steps forward for OpenBSD was when the entire source tree was audited for buffer overflows and vulnerabilities. This has been constantly maintained and has resulted in a product unparalleled in terms of security and system integrity. In saying this, third party software is usually necessary for the operation of a functional system, so OpenBSD makes it available via the ports tree (http://www.daemonnews.org/200006/ports.html), a mechanism for downloading, installing, and configuring third party software known to work under OpenBSD or modified to do so. I won't go into details here of configuring the ports tree -- this has been broadly documented elsewhere. Security updates As opposed to the majority of commercial vendors and even some other open source projects, OpenBSD takes a "full disclosure" approach to any bugs or vulnerabilities found in the source tree. This means that bugs are reported immediately to users in their entirety, generally with a patch or workaround included. The outcome of this is a system with no hidden bugs or "features" shielded from the users, a prime example of which is the +.htr bug recently in Microsoft IIS. Users wishing to monitor security updates as they occur can subscribe to the security-announce (http://www.openbsd.org/mail.html) mailing list, or monitor the patches posted to the OpenBSD errata page (http://openbsd.org/errata.html). The patches provided are generally a source tarball, which can be simply installed over the top of an existing system. An example of this is the installation of the recent ftpd remote-root exploit patch: 1. Download the patch: wget ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.7/common/019_ftpd.patch 2. Place the patch in your source root directory (usr/src): mv 019_ftpd.patch /usr/src 3. Apply the patch to the source tree: patch -p0 019_ftpd.patch 4. Recompile ftpd: cd libexec/ftpd make obj && make depend && make && make install 5. Restart ftpd (which in this case has been started from inetd): ps aux | grep inetd root 19983 0.0 0.4 72 264 ?? Ss 29May00 3:03.68 inetd kill -1 19983 As has been demonstrated, OpenBSD's "Secure by default" slogan holds merit in all aspects of the system. Hopefully other open source projects (or -- dare I suggest it -- commercial vendors) will start to take onboard this holistic security approach to their own systems. by David Jorm . .... ..:............................................ : : : 002 Intel's x86 CPU : : ...:. . :.:.. by Maticles : : :.:.;................;........................:.: : ;. . .. . ..;. . : ; ; ; The Intel x86 started with the 8086, with a whole (not one more, or one less) 4.7MHz or 8Mhz, my TI-83 is more powerful then that :) These CPU's were 16-bit (External and internal mind you), and didn't require any cooling at all. Then the 8088 came along, with the same speed at the 8086, but featured a much cheaper 8-bit external bus. Then came the 80186, it was just an embedded (i.e. ram + rom + supportchips onboard) version of the 80286. The next update was the most significant in the x86 series, the humble 286. Released in 1982, the 286 had 6, 8, 10, and 12 MHz varieties, was still 16-bit, and featured a technologie called 'Protected mode' this meant that various programs could share the memory without the fear of the CPU crashing, but once in protected mode, the CPU wouldn't get out of it. NEXT! - The 80386 was evolutionary, not revolutionary as people say, it featured a 32-bit architecture, true multi-tasking and was in 12.5, 16, 20, 25 and 33 MHz flavours. There was also the 386SX which had a cheaper external 16-bit bus, sort of the 8088 of the 386. :) Next up on the podium, is the 486, it came in 2 types, the 486 SX and the 486 DX, the difference was is that the DX included a FPU, and ranged from 20, 25, 33 and 50MHz. The 486 is what started the popularity in PC's. Then the DX2 and DX4 were released with something not seen before, a 'clock multiplier' which allowed the system bus to be multiplied to allow faster CPU speed, this made 66MHz and 100MHz respectivly. The Pentium and Pentium Pro were introduced in 1993, the Pentium featured a brand new core with 64-bit transfers. The original Pentiums came in 60MHz and 66MHz varieties, and the 2nd generation pentiums ranged from 75MHz to 200MHz. Just for a reference, Soundblaster Live has the same MIPS processing power of a Pentium 75MHz. The 3rd Pentium generation (Not Pentium 3 - 3rd inclination of the Pentium) featured MMX, and this varied from 266 to 233MHz, MMX is MultiMedia eXtensions, and this CPU was considerably faster then the non-MMX version. In 1995, the Pentium Pro was released which was designed for the NT server market, it was alot faster for multi-tasking then the original Pentium and did true 32-bit calculations. Next up was the Pentium II and Celeron family, the Pentium II was released in a slot format, which was not compatible with earlier Pentiums, the P2 ranged from 233MHz to 450MHz. Released in 1998, the P2 Xeon was the 'Pentium Pro' of the P2, it was basically a Pentium II in a large cartridge, and had over 1MB of cache on the darn thing. In 1999 Intel released the Celeron which was a Pentium II, but with no on-die cache and ran on a 66MHz bus. Because of the Celerons low heat levels, it was a great success with overclockers. Next is the PIII it was released in 1998 with 450MHz, and it appears to be stabilzing at 1000MHz, there were different types of the PIII including the 'E'and the 'EB', and naturally, there was a PIII Xeon which was quite the beast. In 2000 Intel released the Celeron II which was a Celeron based on the PIII core, but still had a 66MHz bus. Later on in the year, Intel released the Celeron 800 with a 100MHz FSB. Pentium 4 is Intels latest baby, starting at 1.3GHz going to a whooping 1.5GHz, it runs on a 400MHz bus (100QDR) with the ailing RAMBUS, RAMBUS is a type of ram which runs at speeds of 400MHz, but it is extremly expensive because of licensing fees put on by RAMBUS Inc. . .... ..:............................................ : : : Iptables for Linux 2.4 : : ...:. . :.:.. by Technion : : :.:.;................;........................:.: : ;. . .. . ..;. . : ; ; This article is for people who have been using ipchains for some time and are looking at moving towards iptables. It's more about principles of stateful firewalling than iptables syntax, though it is covered. *BSD people who have been using ipf for years will probably find nothing new here. If you have a look at any attempt at a secure ipchains script, you'll notice that it still has to leave many ports open simply for local services. Here's the reason. The outside world makes connections to your machine, and of course, some of the ports that connections can be made on will be open with a service. Other will be firewalled off as part of your script. But there's something else that utilises ports, and that's your local browsing habits. Fire up lynx, netscape, some ftp client, and you all know it opens a port on a remote server. Where some people get confused is realising that it needs to open a port on the local machine in order to get an answer. There's nothing considered BOUND to that port, it's still not a bad security risk as only the server you connected to can talk to that port. But the fact remains that any script you write was going to have to open a large range of ports. The default range for local ports is 1024:65535. This range is chosen because it happens to be the range of ports that a process not running as root can work with. Opening a large range of ports isn't really that bad. If nothing runs inside that range there is still no hacking potential. Once you try logging everything however that looks like a connection or scan however, you find yourself adding close to a hundred firewall rules just to get the effect you desire. Larger firewall rules may create the illusion of more security, but if you can gain the same effect from smaller sets of rules you do better for two reasons: -The more complicated a script is, the more you'll find you left something out. -Before your computer can process a packet, it needs to traverse the whole chain. If you are getting lots of connections, very large firewall scripts can take up more CPU than you may want to waste. The ipchains script I worked on attempted to minimise this a little by using the proc filesystem to close this gap a little.. like this: echo "32768 61000" >/proc/sys/net/ipv4/ip_local_port_range Few services run inside this range, so only allowing input here is one possibility. Iptables turns the tables on all this by what is called stateful firewalling. It allows you to set a rule up according to the state of the packet. For example, observe the following: $IPTABLES -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT Placing this as one of your first input rules will allow any input to your machine if it is already associated with a connection, such as part of a connection request you created, or any icmp - unreachable packets which may be in response to a request you sent. It also means that once a connection is established, further packets in that stream won't have to traverse your whole chain, alleviating that CPU usage issue I talked about. It also means with one line, we've sorted out the issue of opening any ports- there's no need. If netscape opens a port to browse, replies on that stream will be allowed. If it uses port 1025 to get a web page, we don't need to explicitly open port 1025 to let it work correctly. This allows for simple rules to accomplish big things. All we have to do now is allow connections to specific ports we want a service run on. A few other things to note about iptables. The main one is that packets on the forward chain (now FORWARD they have all been capitalised) will no longer traverse first through the input chain. This means that an input rule denying input on port 21 won't stop you forwarding ftp connection requests. This is good... we can deny more on our sever without worrying about affecting those behind it. Now let's go through a simple firewall. Despite its simplicity, it's plenty enough for something like a web server sitting behind a more advanced firewall, such as the script I'll talk about later. I can't emphasise enough that despite what you usually read, good firewall scripts involve sysctl (/proc filesystem) as much as humanly possible. There are many options which can be set to reduce DoSing abilities and so forth. First, let me go through the syntax differences so you know what I'm doing. Find what you need at: This script assumes that the netfilter code was either built into the kernel or the modules are already loaded. If not, you can load them with these commands: /sbin/insmod ip_tables /sbin/insmod ip_conntrack /sbin/insmod ip_conntrack_ftp The rest will be dynamically loaded by the above as necessary. #!/bin/bash #Firewall script for iptables #By Technion > #First, we aren't a router. We could use iptables to reject forwarding, #but the command below will work at a lower level. echo "0" > /proc/sys/net/ipv4/ip_forward #Don't respond to broadcast pings. Again, this is just stronger than using #a iptables rule- which we could also do. echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts #Flush all rules /sbin/iptables -F #Accept anything on an established connection /sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT #Acept local traffic /sbin/iptables -A INPUT -i lo -j ACCEPT #Accept icmp. /sbin/iptables -A INPUT -p icmp -j ACCEPT #Accept connections to port 80 for web usage /sbin/iptables -A INPUT -p tcp --dport 80 -j ACCEPT #Alow SSH from some address or address range /sbin/iptables -A INPUT -p tcp --dport 22 -s -j ACCEPT #Reject the rest /sbin/iptables -A INPUT -j REJECT And that is it! It doesn't really log anything, and its DoS'ing prevention abilities are poor. Yet a web server behind a more advanced script, maybe with an internal address and its firewall doing DNAT to get web requests to it, has no reason to require any more than this. It's important to finish with a "reject all" rule. This doesn't mean everything will be rejected, just that which has not been allowed or dropped by an earlier rule. Now to the "ip_always_defrag" issue. Not many people really understood this. It doesn't matter anyway, because it doesn't appear to exist in the 2.4.x kernel, and instead appears to be default. It's memory usage in doing so can be tweaked, but until I learn more about it, I'll suggest leaving it at its default. And what script should you run on your firewall? Well the answer is you should always write one best suited to you. But for a "skeleton" script, head to my web page and you'll find the most recent version of a script I have been working on. I'd post it here, but by the time you finish reading it there will be a newer version on the site. There's also an ipchains script there if you're interested. Many thanks to all those that helped out. . .... ..:............................................ : : : 004 Advanced JavaScript Methods : : ...:. . :.:.. by Lymco : : :.:.;................;........................:.: : ;. . .. . ..;. . : ; ; This article is intended to expand your knowledge of JavaScript methods. We will cover: i) String Handling, ii) Preloading Images, iii) Mouseover Imageswapping, iv) Browser Compatibility, v) Resolution Compatibility and then finally, an introduction to Dynamic HTML Visibility. Before we get started, I will quickly note that if you are unfamiliar with JavaScript, I recommend the following sites: 1) http://hotwired.lycos.com/webmonkey/programming/javascript/tutorials/tutorial1.html 2) http://www.htmlogoodies.com/beyond/js.html 3) http://www.javascript.com Once you're familiar with the basics of JavaScript, continue reading this text. (i) - String Handling ----------------- 1. variable.length This returns the string length of 'variable'. Example: var your_name = prompt("What is your name?"); your_name_length = your_name.length document.writeln("Hello "+your_name); document.writeln("Your name is "+your_name_length+" charecters long"); 2. variable.indexOf("x"); indexOf() returns the charecter index of 'x'. Example: email_address = prompt("What is your e-mail address?"); if (email_address.indexOf("@") == -1) { document.writeln("Sorry, invalid e-mail address."); } else { document.writeln("Thankyou."); } Note: As you should know, -1 means that the function 'didn't return true'. 3. variable.charAt(x); charAt() returns the charecter at the index of 'x' in the variable. Example: variable_a = "Hello"; variable_b = "Irene"; variable_c = variable_a.charAt(0)+variable_b.charAt(0); document.writeln(variable_c); Note: This function works like an array. ie: 0 returns the first letter, 1 the second, etc. 4. variable.substring(x, y); substring() copies text from 'x' to 'y' in a variable. Example: string_a = "Hello how are you?"; first_word = string_a.substring(string_a.charAt(0), string_a.indexOf(" ")); document.writeln("The first word of \\""+string_a+"\\" is:"); document.writeln(first_word); 5. variable.split(":"); split() puts a variable, which has a delimiter (read: divider, so to speak) between each index word, and places it into an array. Example: cities = "Perth, Sydney, Melbourne, Adelaide, Darwin, Hobart, Canberra" var cities_array = cities.split(","); document.writeln("The capital cities in Australia are as follows:
"); for (i=0;i"); } (ii) - Preloading Images ----------------- All that is required is the use of the new Image() function. Example: How it works: The above is the equivalent to: However, it does not include it inside the tag. It merely downloads the image, and does not display it on the active document. (iii) - Mouseover ImageSwapping ----------------- Basically, you have an image with an ID name, and you set an event to rewrite the value to another image. Making it dynamically change. To my knowledge this feature is only functional in IE and NS versions 4 and higher. . the javascript (this belongs in the tag) . the images First, download the two images: dev.spanner.net/scripts/image1.jpg dev.spanner.net/scripts/image2.jpg and then: (In the tag) . finishing up Well, that should work fine. Of course the first image uses image1.jpg as it's source, and image 2 uses image2.jpg. By the way, YES, you can edit these. (iv) - Browser Compatibility ----------------- JavaScript can be a hard language to write for at times because of this issue. For those whom are un-aware, JavaScript was created by Netscape. Since the initial creation, alot of modifications have been applied, and syntax can differ from browser to browser. The core JavaScript syntax is handled the same with Netscape to Internet Explorer, however new features, such as Dynamic HTML can be hard to implement to be adaptable browser wide. In this section of the article, I will show a few methods in how to write adaptable code. 1. Lynx Lynx is a UNIX text-only browser. It does not support JavaScript. So how do we write compatible JavaScript for Lynx? We don't. Instead, we have to make our website viewable for Lynx users. Method 1: Before, and after your JavaScript code, an option is to insert the tags. What this does is 'comment' out all of the code. This way, browsers which don't support JavaScript won't return a bunch of errors upon loading. Example: Method 2: Most text-only (and old) web browsers support the HTML tag