The dangers of proliferation of shared FTP accounts

In a medium sized education organization which shall remain anonymous; FTP and windows file sharing is the file transport of choice for distributing small reports and data chunks. For a long time when a ftp account was needed the person would simply call up the first person who maintained a server that came to mind and had one created. The new ftp account was then fed into a script on the database server (mainframe or AS/400) which then once a day/month/year it spit out a report and uploaded it to the server where (someone/something/every one) picked it up and either loaded it into a different script, or dumped it into a spread sheet, did their business then deleted it and went to lunch.

This has gone on for decades with out some one pointing out that there is something wrong with this process.

Let me count the ways this is wrong:
1. It's not encrypted.
Packet sniffers are very easy to implement even on a switched LAN.
2. There is no way to prove that the remote host is what it says it is.
Server spoofing via DNS or Denial of Service.
3. Access control (in this case) isn't managed.
Static user names and passwords being passed in the clear.
4. Proliferation of potentially sensitive data
Just about every industry is required by law to protect certain kinds of data.
5. Use of old and un-maintainable server for warehousing information.
No warranty, use of old 3rd party software which is unmaintained, End-of-life OS.
It's potential for being 0wned is pretty high.
6. Total disregard of Intranet and Internet facing status of server.

Why? You ask has this issue been allowed to even occur?

Reason #1 Impending retirement. Why would some one who is retiring in 5 or so years would want to learn something new? Ftp and windows file sharing is well known. Ftp has been used on open systems since their inception so everybody supports it. (I mean the standard supports 7 bit file transfers, from the time when bits were expensive, really when is the last time you NEEDED to transfer something using 7 bits as opposed to 8bits?).

Reason #2 Bypassing the chain of command. Why follow protocol and make an official request when you can call the person maintaining the server and have them do it for you.

Reason #3 Maintainers versus dedicated IT staff. In most small and medium organizations, they cant afford dedicated IT staff so they give the position to some one who already does something else. The problem is that the person just puts out fires and performs maintenance. They don't keep up on industry issues and so long as the server limps along everything is fine.

Conclusion:
Because the chain of command is bypassed the Network Administrator isn't aware of it. And the only way he or she will find out about it is either an audit, if it fails or if the server is totally Pwned and now is now selling generic Viagra. Should the latter be the case, a pile of finger pointing ensues and you can guess the rest.

Alternatives:

The solution is finding a suitable replacement technology which is secure and possesses controls on access and availability yet is similar to an existing process so you take advantage of the users existing habits instead of putting them into an uncomfortable situation of learning some "NEW" computer process.

1. Pre configuring the email client to use encryption. Email is one of those skills that every one knows or should know.
   
2. Implement Ftp over SSL on a managed file server .(Windows, Linux, Novell ...etc) Most of them have some form of secure drive mapping or mounting which is done transparently to the user. This really is the best choice because most modern server platforms possess some form of auditing features which allow you to track access to resources and or files.
   
3. Secure web application for reports and data. Automate the process and load it into a database then generate the reports on a web page or make it available as a download. A well designed web system can contain all of the controls to keep data safe. Surfing the web is a national pastime, provided you make a usable web interface.

Perhaps in conjunction with...

1. Controlling movement of data. Prevention of use of external storage devices.
   
2. Encrypting file contents using authentication. Smart cards, public/private keys, hardware keys...etc

Information security is not about being perfectly secure, it's about maintaining a good balance of security vs. usability.

IP Subnetting - more fun with newLISP

I decided it would be fun to try to make an IP subnet calculator with newLISP.

Thanks to Elica and Lutz on the newLISP discussion boards. I needed some help with the logic. There's probably a way to compact this code down to about 3 lines somehow, but I'm still a newLISP n00b. I stuck with the logic examples that I have a firm understanding of, but the discussion yielded some interesting results.

Here's what I came up with

#!/usr/bin/newlisp
# newLISP IP Address calculator by ax0n
# ax0n (at) h-i-r.net
(define (iptostr ip4)
# Converts an integer to an IP in dotted decimal notation
(string
  (mod (/ ip4 0x1000000) 0x100) "."
  (mod (/ ip4 0x10000) 0x100) "."
  (mod (/ ip4 0x100) 0x100) "."
  (mod ip4 0x100))
)

(define (iptonum ip4str)
# Converts an IP string to an integer
 (map set '(one two three four) (parse ip4str "."))
 (+ (* 0x1000000 (float one)) (* 0x10000 (float two))
  (* 0x100 (float three)) (float four))
)

(cond(
 (< (length (main-args)) 3)
 # Display usage if no args passed
 (println "usage: ipcalc.lsp ip-address/maskbits")
 (println "ex:    ipcalc.lsp 192.168.1.20/24")
 )
 (true
  (set 'ipstr (last(main-args)))
  (map set '(ipaddr bits) (parse ipstr "/"))
  (set 'binip (iptonum ipaddr))
  (set 'netmask (& 0xffffffff ( << 0xffffffff (- 32 (int bits)))))
  (set 'netaddr (& binip netmask))
  (set 'bcast (& 0xffffffff (| binip (~ netmask))))
  (println "host IP:    " ipaddr )
  (println "netmask:    " (iptostr netmask) )
  (println "network:    " (iptostr netaddr) )
  (println "broadcast:  " (iptostr bcast))
  (println "Host range: " (iptostr (+ netaddr 1))" - "(iptostr (- bcast 1)))
 )
)
(exit)

Running it by itself gives you a syntax help page.

-bash-3.2$ ./ipcalc.lsp
usage: ipcalc.lsp ip-address/maskbits
ex: ipcalc.lsp 192.168.1.20/24

You have to provide an IP Address and mask in CIDR Notation. It does the rest!

-bash-3.2$ ./ipcalc.lsp 192.168.0.49/24
host IP:    192.168.0.49
netmask:    255.255.255.0
network:    192.168.0.0
broadcast:  192.168.0.255
Host range: 192.168.0.1 - 192.168.0.254

You can download the script here:
http://stuff.h-i-r.net/blogstuff/ipcalc.lsp

IP subnetting

This really isn't that hard, but I had someone ask for help on one of the forums I participate in, and thought I'd share the answer here.

The person needed to determine the following given an IP/Mask of 146.141.219.47/18

• Subnet Mask
• Network Address
• First usable host address
• Last usable host address

The answer is to use binary math and boolean logic to solve the problems.

/18 means there is an 18 bit subnet mask on that IP address. This is neither a Class C (24 bit subnet mask) or Class B (16 bits). Although, "Classes" are kind of obsolete these days. It's just an 18 bit subnet mask. Straightforward.

In binary, it looks like this (decimal underneath):

11111111 11111111 11000000 00000000
    255      255      192        0

To get the network address, you take the IP Address in binary, and do a boolean AND against the subnet mask. A boolean AND will only return a 1 where both numbers have a 1, and return a 0 everywhere else.

11111111 11111111 11000000 00000000 <-- subnet mask      255.255.192.0
10010010 10001101 11011011 00101111 <-- IP Address       146.141.219.47
======== ======== ======== ========
10010010 10001101 11000000 00000000 <-- Network Address  146.141.192.0

The first usable host IP address is always the first IP after the network address, in this case, 146.141.192.1.

To get the broadcast address, you simply change all of the non-masked bits from the network address (in this case, the last 14 bits) to 1.

10010010 10001101 11111111 11111111 <-- Broadcast        146.141.255.255

You need to know the broadcast address to come up with the last usable host IP address, which is always one IP below the broadcast address. The last usable IP in the network for this example is 146.141.255.254.

Zero Configuration IP

*** Note from Asmodian X : This was written over a year ago but the
information is still viable from an educational standpoint. ***

HiR
Zero Configuration IP

-=-=-=-=-
Introduction
-=-=-=-=-

Welcome Back! It is good to be writing again after the 5+ year hiatus. The target audience of this article are people who are of intermediate experience with networking. Almost all certificates and IT related programs have TCP/IP as a goodly sized chunk of their curriculum, therefore I should expect that a reader would know what TCP/IP was and how it works. For more general information on TCP/IP see: http://en.wikipedia.org/wiki/TCP/IP.

Shout outs to Axon, Frogman and Methodic.

-=-=-=-=-
ToC
-=-=-=-=-

0x01 ................... Objective
0x02 ................... Definition of Zero Configuration Networking
0x03 ................... How ZCN works
0x04 ................... The who's who of implementations
0x05 ................... Works Cited

-=-=-=-=-

----Part 0x01 Objective

The objective for this discussion is to gain familiarity with a part of the TCP/IP implementations called Zero Configuration Networking. Most notably Apple's newest operating system (OS 10) contains Apple's implementation of ZCN called Bonjour (also known as "Rendezvous"). Bonjour allows apple computers or any other computer using the Zero-Conf standard to immediately be able to use a network with out the use of manual network configuration or some form of DHCP http://en.wikipedia.org/wiki/DHCP). Windows XP implements some form of Zero-Conf networking for their wireless applications. Even MacOS 9 had this automatic configuration feature. The goal for Apple was to replace their Appletalk protocol with something that is more scalable. Zero configuration networking also has a specification for service broadcasting using parts of the DNS protocol called multi-cast-DNS and unicast-DNS.

----Part 0x02 Definition of Zero Configuration networking

Zero configuration networking is the ability for an un-administrated network node to be able to auto negotiate a network configuration requiring little or no user configuration. This configuration system is optimal for Ad-Hoc wireless networks, home networks and for emergency relief stations (Williams, 2002). A zero configuration network system should include the ability to configure itself in a fashion that allows it to talk to other similar hosts using the TCP/IP protocol. The randomly chosen addresses are checked to make sure that nodes do not collide with one another on the network. Part of this networking structure is to implement a service location capability. The reasoning for using a service location protocol is that the end user does not know what address the zero configuration system has chosen and therefore cannot easily find shared resources (Guttman, 2001)(Cheshire, Kochmal, 2004). Other networking protocols which require auto configuration are Multicast IP and IPv6 (Octavian, 2002).

----Part 0x03 How ZCN works

ZCN in most cases consists of a default behavior of a network interface. (Though some OS's have a separate utility for doing it which is not a fail-over condition.) The behavior first starts with the interface being in an automatic mode, such as either DHCP being selected or zero Conf mode being enabled. The interface shall then try to configure itself via DHCP. IF that fails then it will default to zero configuration mode that chooses an IP address on the 169.254/16 subnet. The 169.254/16 subnet being a private address space reserved for ZCN. If ARP detects an address collision (using an ARP broadcast) then it will back off and choose another random place on the network until it has found a suitable unused address. Assuming all hosts on this network follow the same procedure every one is now able to talk to each other. If at any time the interface is configured to use a rout-able address it must leave the link-local addressing scheme (Cheshire, et al. 2004). There are, of course, exceptions such as Un*x's virtual networking interface but because this is a link-local addressing system the addresses used are not rout-able unless something like network address translation (NAT) is used.
The catch at this point is that each computer is now able to speak to each other, but no one at this point realizes that any one else is on the network. In order to find resources on this new improvised network requires some form of advertisement protocol. There are many was to do service location, one way to do service location is NetBIOS. Microsoft originally used NetBIOS, to facilitate the creation of local area networks. Apple computers came from a similar desire to make local area networks and they called their protocol set Appletalk. Both NetBIOS and Appletalk broadcast over a subnet to advertise services. Both Apples Appletalk protocol and NetBIOS had issues when scaling into a large network with its high overhead (Cheshire, Stuart. Krochmal, Marc., August 2004). The newest method for ZCN service location consists of each workstation transmitting a special Multicast DNS broadcast to advertise its services to all of the other connected clients. Aggressive caching of these requests and responses keeps the overall service location traffic low (Cheshire, et al. 2004).
Multicast service broadcasting relies on several key items. Each station must have a mDNS responder that listens for requests and responds with a list of applicable services. The response is via Multicast so that all stations on a given subnet may hear and record this service. Unicast DNS can also be used to do this when crossing subnets. Since this system is designed for small implementations the need for routability is not acute. Recently a draft is being worked on by Apple that defines a NAT-Portmaping protocol so that a router can be added in a ZCN environment and all users can auto-magically gain access to that Internet connected device.(Apple, "Network Address Translation ...", 2004)(Apple, "Rendezvous FAQ", 2005).

----Part 0x04 The who's who of implementations

First and foremost the Apple Computer Corporation has an advanced implementation of zero configuration networking called "Bonjour." ZCN is implemented in various forms since Mac-OS 9 in whatever extent it's full implementation may be found as a part of Mac-OS 10.1 and newer. Apple has released C source for use on any other platform including windows.
(http://developer.apple.com/macosx/rendezvous/index.html)

A sketchy implementation for Linux and the BSD's called "HOWL"
is available for almost all flavors via source.
(http://www.porchdogsoft.com/products/howl/)

The sourceforge ZCN implementation for the link-local addressing
portion is the Zero-Conf project at sourceforge. It does not have the
Multicast DNS portions in working order, instead suggesting the use of
OpenSLP. (http://www.openslp.org/) (http://zeroconf.sourceforge.net)

Avahi Multicast DNS client.
http://avahi.org/

One of the stronger Linux/BSD implementations currently implemented in
many distributions including Ubuntu and more.

----Part 0x05 Works Cited

Apple Corp. (December 2004). Rendezvous
http://developer.apple.com/macosx/rendezvous/index.html

Apple Corp. (January 2005). Rendezvous FAQ.
http://developer.apple.com/macosx/rendezvous/faq.html

Apple Corp. (July 2004). Network Address Translation Port Mapping
Protocol. http://files.dns-sd.org/draft-nat-port-mapping.txt

Cheshire, Stuart. Aboba, Bernard. Guttman, Erik. (July 2004).
Dynamic Configuration of IPv4 Link-Local Addresses.
http://files.zeroconf.org/draft-ietf-zeroconf-ipv4-linklocal.txt

Cheshire, Stuart. Krochmal, Marc. (February 2004). DNS-Based Service
Discovery
http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt

Cheshire, Stuart. Krochmal, Marc. (August 2004).
Requirements for a Protocol to Replace AppleTalk NBP.
http://files.dns-sd.org/draft-cheshire-dnsext-nbp.txt

Guttman, Erik. (July 2001). Zero-Conf Host Profile Applicability
Statement.
http://files.zeroconf.org/draft-ietf-zeroconf-host-prof-01.txt

Octavian, Catrina. Thaler, Dave. Aboba, Bernard. Et al. (October 2002).
Zero-Conf Multicast Address Allocation Protocol (ZMAAP).
http://files.zeroconf.org/draft-ietf-zeroconf-zmaap-02.txt

Open SLP Website. (January 2005).
http://www.openslp.org/

Porchdog software inc. (January 2005). Howl Project Website.
http://www.porchdogsoft.com/products/howl/

Williams, A. (September 2002) Zero Configuration Networking.
http://files.zeroconf.org/draft-ietf-zeroconf-reqts-12.txt

Zero-Conf sourceforge website. (January 2005).
http://zeroconf.sourceforge.net