Let Anyone In with Anonymous FTP
Question: We have two files that we would like everyone in our company and several of our customers who can connect to us through our firewall to be able to download. We thought that this would be a good use for anonymous FTP, so we created a user profile called ANONYMOUS, with password *NONE. However, when I try to log on with profile ANONYMOUS and use either my IP address or my email address as the password, I get an FTP error “530 Log on attempt by user ANONYMOUS rejected.” Does the AS/400 even support anonymous FTP, or am I doing something wrong?
Answer: Yes, IBM enabled the AS/400 to support anonymous FTP, but, because an unmonitored anonymous FTP ability could potentially open a big back door to your system, IBM did not automatically activate anonymous FTP. The bad news is that you have to do a little programming yourself, but the good news is that it is an easy program to write and can even be done in CL.
First, let me give you some background on anonymous FTP. Anonymous FTP is best used when you want to disperse information via batch download and are not concerned about who can access that information. Typical files that you might want to make available via anonymous FTP are your inventory catalog (so customers can purchase from you more easily), your readme file, your help documents, and any non-sensitive document that you care to disperse to a wide audience.
Anonymous FTP lets users download selected files from your system without requiring them to have a valid user profile and password on your system. The standard is that the requester would log on with a profile such as ANONYMOUS or GUEST and that the password would contain either the remote requester’s email address or his IP address. As you can guess, there is little or no enforcement of the password requirements, so it is very important that, when you enable anonymous FTP, you strictly limit the data that the anonymous user can access.
The first step in enabling anonymous FTP is to create a library for transferring objects from. Call it ANONYMOUS. Give *PUBLIC *USE authority to the library and make the default create authority (CRTAUT) to the library *USE. Next, create a user profile called ANONYMOUS, with password *NONE, and a default current library called ANONYMOUS. It’s also a good idea to set the profile as limited capability user (LMTCPB(*YES)) and set the profile storage threshold to a fixed amount (the default is
*NOMAX) as an extra precaution. You definitely do not want to assign any special authorities or group profile enrollments for the anonymous user.
You are now ready to write exit programs. Anonymous FTP is enabled on the AS/400 through the FTP Logon Server (exit point QIBM_QTMF_SVR_LOGON). The FTP Logon Server passes the server request, user ID, password validation information, and client IP address to the FTP Logon Server exit program, which then determines whether to accept or reject the request. If the request is accepted, the exit program sets the environment for the anonymous FTP request.
Figure 1 lists input parameters and recommended output parameters for an anonymous FTP Logon Server program. It’s important that you set the return code to 5 to indicate to the FTP server that you’re implementing anonymous FTP.
You also need an exit program for the FTP Server Request Validation (QIBM_QTMF_ SERVER_REQ) exit point, which is used to restrict the FTP commands that user ANONYMOUS can execute. Figure 2 contains input and output parameters for the FTP Server Request Validation exit point. It’s very important that these anonymous users not be able to create, delete, or modify existing OS/400 objects. It’s equally important that they not be permitted to run CL commands through FTP. The FTP Server Request Validation exit program can prevent this activity and restrict the remote user to simply listing (FTP operation 4) and sending (FTP operation 6).
If you’re going to implement anonymous FTP, you’ll want to experiment with these programs and, certainly, enhance them considerably. Still, they should provide a decent foundation and set you on your way to anonymous FTP serving.
Exit Programs Tighten AS/400 Security
Question: I’ve heard and read a lot lately about AS/400 exit programs as a security tool. What is an exit program? How would you use it for security? Does this security replace the security that came with our enterprise resource planning (ERP) package?
Answer: Exit programs are a concept that has been around since the AS/400 was the S/38. With the introduction of more network interfaces to the AS/400 in V3R1, in 1995, exit program capability was expanded tremendously. At its most basic, an exit program is simply an opportunity to “exit” an IBM routine and execute your own code before the routine continues. Exit programs typically are registered to an existing exit point through the Work with Registration Information (WRKREGINF) command.
When an IBM process detects an exit program registered to its exit point, it calls the exit program and passes parameters that identify the transaction. For example, when a Windows 98 PC requests to do an FTP “Get File,” the AS/400 FTP server program sends to the exit program the request type (FTP Get File), the user ID of the user making the request, the IP address of the Windows 98 PC, and the actual data request (e.g., get prodlib/payroll a:payroll.txt). With this information, the exit program can determine whether or not to honor the request and return either an “accept” or a “reject” return code. If the exit program issues a “reject” return code, processing ends and the user is denied access.
Exit programs can be written for many (but certainly not all) IBM processes; you hear them mentioned most often in conjunction with protecting network interfaces to the AS/400. They are often used to enhance application security and regulate network access. Traditional AS/400 security models rely all too often on “menu security,” which works great at protecting green-screen access but does nothing to guard against the more than 170 client/server and TCP/IP access methods that the AS/400 supports.
Exit points complement, rather than replace, your ERP security. Most ERP packages rely on some form of menu security that, in conjunction with a database “security” file, determines which users are allowed access to which menu options. However, most of these security designs have a fatal flaw: When the user profile that owns
the application is also the group profile to which all users of the application belong, every user of the application has OS/400 ownership rights. Within the confines of the application menu, security can be enforced, but tools that bypass the menu security—such as Client Access File Transfer, ODBC, and FTP—give the user complete (and even delete!) access to that application database. By using exit programs, you can enhance your ERP software so network tools such as ODBC and FTP are controlled as tightly as the menu interfaces. For more information on exit programs, check out “Understanding Exit Programs” by Paul Culin on page 57.
REFERENCES AND RELATED MATERIALS
• OS/400 TCP/IP Configuration and Reference V4R4 (SC41-5420-03, CD-ROM QB3ANL03)
Description Attributes Allowable Input Values Recommended Output Values
Application Identifier Binary (4) 1(FTP server) N/A User Identifier Char(variable) ANONYMOUS N/A User Identifier Length Binary (4) 9 N/A Authentication String Char(variable) Email address N/A Authentication String Binary (4) Variable binary number N/A
Length Remote IP Address Char(variable) Decimal format N/A Remote IP Address Binary (4) Variable binary number N/A
Length Return Code Binary (4) N/A 5 Return User Profile Char (10) N/A ANONYMOUS Return Password Char (10) N/A Ignored Return Initial Library Char (10) N/A Ignored
Description Attributes Allowable Input Values Recommended Output Values
Application Identifier Binary(4) 1(FTP server) N/A Operation Identifier Binary(4) 4(list), 6(send) N/A User Profile Char(10) ANONYMOUS N/A Remote IP Address Char(variable) Decimal format N/A Remote IP Address Binary (4) Binary number N/A
Length Request data Char(variable) Actual request N/A Length of Request data Binary (4) Binary Number N/A Return Code Binary (4) N/A 1(accept)
Figure 1: Use these input parameters and output parameters for your anonymous FTP Logon Server program.
Figure 2: Use these input and output parameters for the FTP Server Request Validation exit point.
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online