And More Tips for Securing FTP on your IBM i

By Rich Loeber

For the last few months, I’ve been writing about the security exposure from FTP server running on your IBM i box (Power System i/i5/iSeries/AS400).  I started by describing FTP as being the access weapon of choice by many hackers, especially those just starting out.  This was confirmed by our most recent Hacker Report.  Last time around, I talked about a couple of simple suggestions on how to get this situation under control.  Today, I’ll add a couple more tips into the mix to help keep a lid on safeguarding your system from an FTP intrusion.

First, there are lots of good reasons why you want to allow FTP access to your system.  It is an easy way to upload and download data to and from your system from remote locations.  You can also use it for program maintenance from one IBM i to another by moving save files between systems.  Many IBM i software vendors, including my company, distribute software updates using some form of an FTP connection to your system.  So, don’t be afraid of it, but use it wisely.  You can see my last two articles on FTP here and here.

One thing to keep in mind when thinking about FTP is that all the rules of OS security apply to someone connecting to your system.  In order to gain access, they must have a valid user profile and password.  Once they sign on, your current OS security plan will be in place.  So, having a good security implementation tied in to your established user profiles will go a long way towards keeping your data safe.  One additional fact to add into your mix is that in order for data to be accessible to FTP, it must have a minimum security setting of *USE.  If you have a user profile that is regularly using FTP and there are concerns about access, make sure that they do not have a minimum setting of *USE for any objects you do not want them working with.

A problem can easily come up, however, when a user profile is used in different contexts.  By this, I mean when a user has access to certain sensitive objects for their daily work flow that are accessed by program control.  But, that user is also an FTP user and logs in to do file transfers using FTP.  Having different contexts could create a security exposure.  When this user signs on using FTP, they will still have access to the sensitive data files that they are authorized for from their daily work flow.  If this situation exists, you need to address a way to deal with it.

One method, as discussed last time around, might be addressed by implementing controls through the FTP server exit point.  You might also think to issue a second user profile to the user for FTP use.  This solution is not great since the user can still, by choice, establish an FTP connection under their primary user profile and gain access to sensitive data that way.  Far and away, the best solution is through additional exit point controls.  This could be set up to disallow an FTP connection under certain known profiles, thereby forcing the user to make their FTP connection through a secondary profile that you provide.  If you don’t want to tackle implementing your own exit point programming, there are several products available on the market from IBM i developers, including SafeNet/i from my company.

The Sytem i OS also supports profile swapping, which could be another solution to this problem.  Using swapping, the user signs on with one profile, but then the OS swaps their profile to look and act like a different profile.  Information about this technique can be found at the IBM Information Center and has been a part of the OS since V4R5.

If you have any questions about this topic you can reach me at rich at kisco.com,  I’ll try to answer any questions you may have.  All email messages will be answered.

Hacking Report For Our IBM i – 3rd Qtr 2013

By Rich Loeber

In January of this year, Kisco Information Systems issued our first Hacking Report for our IBM i system.  At that time, I promised to publish additional reports of what we are seeing on this test server.  This is our report for the third quarter of 2013 and represents activity observed from July 1st through the end of September.

During this three month period, we observed a slight decrease in the volume of network transactions on our system, less than 1% in total.  At the same time, we saw a drop in the number of illegal access attempts that were rejected by our SafeNet/i software.  From 1,417 rejections last quarter, we saw an 8.4% decrease down to 1,209.  This represents an average of 14 unauthorized access attempts every day, down from 16 last quarter.

Life on the Internet continues to be unsafe.  Having someone knock on the door of my primary server 14 times a day trying to get in is not my idea of fun.  But this is what passes for “normal” in today’s internetworked world.

Some interesting things to note ….

On our server, the unauthorized access attempts continue to fall into two categories.  The miscreants attempt to access the system by FTP and Telnet.

SafeNet/i on our FTP Server on the IBM i OS rejected 792 access attempts which represents a decrease from last quarter.  During this time, the number of legitimate FTP access attempts was 746, so the unauthorized attempts exceeded the legitimate attempts.  We serve client requirements and software development needs using FTP, so we have to keep the FTP server active.  This is a clear warning message, however, that if you are keeping the FTP server active on your system, you really need to have access controls in place like those provided by SafeNet/i.

During this quarter, however, we saw that brute force FTP attacks using a large number of different common user profiles disappeared.  In its place, we are seeing repeated attempts to gain access using very common user profiles but cycling through multiple passwords on each attempt.  Using this method, the most popular user profiles used were ADMINISTRA, MYSQL, APACHE, TEST, TEST1, TEST12, TEST123 and WWW-DATA.  All of these profiles are common in the Unix world, so it appears that the IBM i platform is still not well recognized.

For unauthorized Telnet access attempts, we saw an increase in activity, nearly doubling, back to the level we observed during our first quarter report.  The access attempts via Telnet tend to come in single attempts or at the most, two or three successive attempts.  SafeNet/i captures these before an actual signon screen is presented, so they never get to the feature in IBM’s i OS that forces a profile to go inactive.  (The same is true for the way we are intercepting unauthorized FTP attempts.)

We also continue to see certain IP addresses with repeated access attempts.  The leading violator for this quarter traced back to Bright House Networks in Florida.  The next three highest all traced back to the Asia Pacific Network Information Center in Australia.

Another trend that we note that is disturbing is that for the 92 days covered by our study, there were only 5 days with no malicious activity.  That means that almost every day our server sits out there, someone is trying their hand at gaining access illegally.

We will continue to review our server’s status on a quarterly basis and report the results on our blog space.  If you have questions about details of the report, feel free to contact me directly by email (rich at kisco.com).

More Tips for Securing IBM i FTP

By Rich Loeber

A few weeks ago, I published a tip about the security exposure that FTP represents on your IBM i platform.  That tip has generated some interesting feedback along with some ideas from readers on how they address the issue.  This tip features some additional ideas for you to protect yourself from FTP abusers.

First and foremost is this.  If you don’t use FTP, or you only use it on rare occasions, then don’t leave the FTP server active on your system.  You can check to see if the FTP server function is active on your system by running the following command:

WRKACTJOB SBS(QSYSWRK) JOB(QTFT*)

Look for jobs listed named QTFTPnnnnn.  If FTP is active, you will find several of these jobs shown.  To turn the FTP server off, run the ENDTCPSVR command specifying the *FTP server option.  Most systems come from IBM with the FTP server set to start automatically whenever TCP/IP is started.  You can change this by running the Change FTP Attributes (CHGFTPA) command.  Prompt it with the F4 key and check the first parameter.  If it is set to *YES, then FTP is going to start automatically at every IPL.  Changing this to *NO will stop this from happening.

In our shop, we use FTP enough during the course of the day that we keep the FTP server up and active.  But, we have job scheduler entries in the system to turn it off at the end of the day and then restart it every morning.  That way, for 24 hours of possible exposure, 16 of those hours are completely protected.  On the rare occasion when we need FTP during off hours, it is a simple matter to log in and start it again manually.

If the FTP server is inactive, then it cannot be misused.

The other good way to protect yourself from FTP abuse is through the implementation of exit point programs.  The FTP server has an exit point that can be used to filter incoming requests.  This is also true of the Telnet server, another point of possible abuse.  One reader of my last tip suggested implementing the freeware SECTCP utility written by the former IBMer Giovanni B. Perotti.  This utility is available for free download, after a simple registration process, from the following website:

http://www.easy400.net/easy400p/downloads.html#d09

I have downloaded and reviewed this code, but have not implemented since I have my own exit point software already active.  But, the reader swears by the code and Mr. Perotti certainly has a terrific reputation in the IBM i family of users.  So, if you’ve been thinking about implementing exit point controls, this might be any easy entry point for getting started.  The source code is all included with the download and, in fact, everything needs to be compiled in order to install the software.  The user instructions on getting started all appear to be fairly simple.

Also, if you don’t want the bother of maintaining your own exit point code, there are quite a few very good products available from reputable IBM i software developers today.  FTP and Telnet controls are just the tip of the iceberg where exit programming for security is concerned.  I, of course, recommend my own product: SafeNet/i.

If you have any questions about this topic you can reach me at rich at kisco.com,  I’ll try to answer any questions you may have.  All email messages will be answered.

Watch Out For FTP On Your IBM i

By Rich Loeber

FTP (File Transfer Protocol) is a nice and easy way to communicate between systems.  With FTP on your IBM i, you can transfer files to other systems, including other IBM i’s, with ease.  You can also use it to move programs and files between systems, all with relative ease.  But, increasingly, FTP is also becoming the hackers weapon of choice when cruising the Internet.  And, with FTP’s QUOTE command (among others), a knowledgeable hacker could do some serious damage to your system.

I tell you this based on personal experience with my own IBM i.  In a recent 7 day period, I identified more than 1,500 attempts to sign-on to my system from people not authorized.  All of these were malicious hacking attempts.  When I did a Trace Route on many of these, they pointed back to source IP addresses in The Netherlands, China, Colombia, Russia and other parts unknown.  Some attempts would not even trace back successfully.

I initially thought that nobody would bother my system since it is just a numbered address with no DNS entry to make it easy to find.  But, this is clearly not the case.  Some hackers use automated attack programs to just cycle through entire IP address ranges, and these are the folks who regularly stop in at my system.

The method used, from my personal observation, is to break in using the same user profile, usually ADMINISTRATOR, trying a different password every few seconds.  They will often cycle through and retry the same password more than once.  I’ve observed one break-in artist try this 850 times in a row over a period of several hours.

I know all this about my system because I monitor all network traffic and track it using our exit point software.  We have our system configured to only permit FTP access from trusted IP addresses.  The list is, necessarily, very small.  This protects our system from malicious remote access via FTP.  Also, if a hacker were to get past this check (which they never have so far), our system has no default passwords, so trying to cycle through known IBM i profiles and default passwords will also end up in failure.

So, what can you do to protect your system from FTP attackers?

First, make sure that you don’t have any default passwords set up on your system.  Use the Analyze Default Passwords (ANZDFTPWD) command from the SECTOOLS menu for this.  Initially, run it with the *NONE option for the ACTION parameter just to get a listing.  Then, when you’ve reviewed the list, make sure that the profiles with default passwords have their passwords reset to either a different, unique password or are set to *NONE.

Next, implement some sort of IP packet testing to only accept FTP connections from trusted IP addresses.  You can do this like we do using an exit program attached to the FTP sign-on server.  Or, if you have a fairly recent version of the OS, you can use the IP packet filtering capabilities in IBM i Navigator.  This will let you allow known IP addresses, or address ranges, to access your system while keeping everyone else out.  When setting this up, make sure you keep an active connection to your system while you are testing so that you don’t accidentally shoot yourself in the foot and lock out all access to your system.  Remember, the IP packet filtering will apply to all users connecting to your system, not just FTP users, so this will be a bigger job than you may think starting out.

If you have any questions about this topic you can reach me at (rich at kisco dot com),  I’ll try to answer any questions you may have.  All email messages will be answered.

Tracking User Profile Changes

By Rich Loeber

In response to a recent tip, I heard from a reader who suggested a good technique that they use for managing a large base of user profiles on their system.  They submitted this suggestion and I’ve been playing with it and it really does give you the basis for managing your user profile base quite nicely.

What this security officer does is to periodically create a database file of the basic information set up for the entire user profile base.  They then compare this to a version of the database to one created a couple of weeks earlier.  Through a series of Query reports, they are able to list activity in the user profile base that gives them exception reports to review.

To get started, with this approach, you need to create your baseline or historical database.  This is done using the Display User Profile (DSPUSRPRF) command.  Select all profiles for basic information and specify an *OUTFILE.  Then sit back and wait a few days, or as my reader suggested, two weeks.  You may want to wait longer depending on how much time you have and how large your user profile base is.

Then, after the selected time period, run the Display User Profile (DSPUSRPRF) command again, but specify the output to a different *OUTFILE database.  Once you have these two files, you can then run a series of Query reports that compare the two files.

My reader recommends at least four reports, but when you get the hang of this, additional reports may be helpful.  The four reports that they work with are:

•    New User Profiles Added
•    Old User Profiles Deleted
•    User Profiles with no Sign-on Activity
•    User Profiles with changes to their Special Authorities

Using IBM i Query, this is really quite easy.  You can match the two files on the user profile field and select different key match criteria depending on the exact report that you are going to create.  In some cases, you’ll want records on one file but not on the other and vice versa.  In other cases, you will want to look at profiles that are on both files but have field mismatches.

Then, when you’re all done with your reporting, copy the current user profile database over into your historical user profile database and wait another couple of weeks to repeat the process.

These exception reports will show you significant change areas in your user profile base.  You can verify that new profiles added are valid and the same for deleted profiles.  For profiles with no sign-on activity, you can check to see if the users are just on vacation or are actually gone from the company.  For users whose special authorities have changed, you can verify that the changes were warranted.

Other reports you might want to consider are users with group profile changes, users with expired passwords and much more, limited only by your imagination.

If you’re interested, I’ve created the four query reports and a CL program that ties this all together.  If you’d like a copy of these in a save file so you can load them directly onto your system, just ask.  If you have any questions about this topic you can reach me at rich at kisco.com,  I’ll try to answer any questions you may have.  All email messages will be answered.

Custom Password Validation Program

By Rich Loeber

While the IBM i operating system has very good features for controlling password selection, sometimes your password policy just can’t be enforced without additional checking.  You may have a list of reserved words that you specifically do not want anyone using as a password.  Or, you may have some very stringent requirements that are just not covered by the system values that control password assignment in IBM’s i/OS.

When this happens, the only solution is to code your own password validation routine.  This can be coded in any high level language.  The operating system passes four parameters to your program, one of which is a single character return code.  Once you’ve had a chance to complete your validation testing, just set the return code to the value you want and exit your program.  If you set the return code to zero (‘0′), then the operating system will assume that your password is acceptable and the password is updated.  The parameters passed are, in order, the new password, the old password, the return code and the user profile for a total of 31 characters.

To tell the operating system that you now have your own password validation program in place, you need to update the system value “Password validation program” (QPWDVLDPGM).  It is shipped from the factory set to *NONE.  To use your own program, just change this value to your program name and library name.  It is recommended that you store this program object in the QSYS library so that it is always saved when you backup your operating system.

Once your program is in place, test it to make sure that it is getting called.  Use the CHGPWD command and intentionally use a password that will cause your routine to fail.  You will see that a message is displayed indicating that the password rules are not met along with the value of the return code that you used.  By varying the return code for different situations, you can give your support team a heads up as to the exact reason for the password failure.  While you’re completing your testing, make sure that you process a valid password change to make sure that normal changes are not adversely affected by your new validation routine.

Registering your specific program with the QPWDVLDPGM system value will only work if you are using default 10 character user profiles and passwords.  If you are using the newer long passwords, then you will have to write an exit program and register it using the exit point registration facility.  If you take this path, then the QPWDVLDPGM system value must get set to the special setting of *REGFAC and the exit program is registered by the WRKREGINF command.  Beware, however, that the parameters for the exit point are very different.  There is a good example of the format needed for this exit program in the IBM security guide.

One thing to watch out for in this process is that the passwords, both old and new, are passed to your program without any encryption.  So, do not store any values received in a database file as this will compromise security on your system.  In fact, you should periodically check this system value to make sure that it does not change and that the program processing additional validation rules remains unchanged.  This could easily be abused on your system, so lock up the program object.

If you’d be interested in receiving a sample program for default 10 character password validation, I’ve written one just to test how this works on my system.  Let me know and I’ll send the program shell to you.  If you have any questions about this topic you can reach me at rich at kisco.com,  I’ll try to answer any questions you may have.  All email messages will be answered.

Strengthen Your Passwords

By Rich Loeber

Secure access to your system often starts with your user profile and password policy.  If you’ve been working in the IBM i world for any length of time, this is very familiar territory for you.  You may even have this task assigned to an underling who maintains your user profile base without any instruction or interaction from you.

Sign-on passwords are your first line of defense in your approach to security.  Your password policies are important tools in securing your system.  If you’ve been around a while, you may not be aware of the latest controls that are now available in IBM’s i/OS to help implement stronger password controls.  Over the years, additional controls have been implemented and strengthened.  This tip will review the system values that you can use to implement your password policy.

For starters, you should not have any permanently assigned passwords on your system.  While this is technically possible, it is NEVER recommended.  The system value QPWDEXPITV lets you enforce how often your users need to change their password to continue valid access to your system.  IBM recommends that you do this every 60 days.  Since users have to change their passwords often, some users may want to just alternate between two favorite passwords.  Another system value control in place is QPWDRQDDIF, which defines how many password iterations can go by before a password can be reused.  IBM recommends you set this to level 5 which will enforce 10 iterations.  I recommend a higher number to discourage this practice altogether.

To control how your password is constructed, you want to eliminate common words and names from use so that password guessing is ruled out.  One easy way to do this is to exclude all vowels from use in passwords, which can be done using the QPWDLMTCHR system value.  This lets you specify up to 10 characters (letters or numbers) that must be excluded from passwords.  By using the string “AEIOUY”, you will exclude all vowels from use in passwords.  One thing to note is that the QPWDLMTCHR is not enforced when you are using long passwords at password level 2 or 3 (QPWDLVL).  Another system value that controls password content is QPWDRQDDGT.  When this value is set to ‘1′, then each password must include at least one numeric digit, again making guesswork that much more difficult.

There are three more password system values that help to control password content.  QPWDLMTAJC lets you disallow repeated adjacent numerical digits in the password when the value is set to ‘1′.  Similarly, for characters, the QPWDLMTREP does the same function for alpha characters.  For this value, using ‘1′ will disallow the use of the same character anywhere within the password.  The value of ‘2′ will disallow consecutive use of the same character.  Lastly, the QPWDPOSDIF system value controls password changes.  When this value is set to ‘1′, a new password cannot have any character in the same position as the previous password.  This prevents the user from changing their password by just changing one or two characters.

Two system values control the minimum and maximum length of your passwords.  QPWDMINLEN defines the minimum number of characters required by your password.  IBM recommends a setting of 6, and I concur.  QPWDMAXLEN defines the maximum number of characters.  IBM recommends that you set this to 8, but I really don’t know why.  It depends on the type of passwords you are using as defined by the QPWDLVL setting.  Depending on how this is set, your system might support password lengths up to 128 characters of mixed case values (but that is a different discussion).

Lastly, if none of these settings will adequately implement your password policy, you can write your own exit program.  The system value QPWDVLDPGM will let you register your exit program.  When there is a program registered to this exit point, it will be called whenever a new user is added or when a password is changed.  Your program can do any additional validation testing, returning a pass/fail indicator to the exit point.

This seems like a lot to consider, but with the system values set properly, you can let the operating system enforce your password policies without a second thought.  You only have to set them up once and they will do the job faithfully from that point on.

If you have any questions about this topic you can reach me at rich at kisco.com,  I’ll try to answer any questions you may have.  All email messages will be answered.

Lock Up Your System Values

By Rich Loeber

When you implement your company’s security policy on your IBM i, often the first thing you do is review your system values.  System values define global, system-wide settings on your IBM i platform.  Many of these system values pertain to how you want to implement system security.  This tip will review how to look at these settings and then, how to lock them in place so that they cannot be changed.

So many of these system values are security related that the OS designers provided an easy way for you to review and work with the security settings.  This is by using the “Work with System Values” command (WRKSYSVAL) with the “System value” (SYSVAL) parameter set to the special value of *SEC.  Like this:

WRKSYSVAL SYSVAL(*SEC)

Setting the OUTPUT parameter to *PRINT will produce a listing of the security system values for you.  Or, you can just run the command with the OUTPUT parameter blank and the system will bring the security system values up for you to review.  A similar review function is available from iSeries Navigator, but the security functions are spread out over several different selection tabs (at least on my version) and you have to go several places to find everything that is available from the single *SEC review ability of the WRKSYSVAL command.

When working with the values interactively, you can review the current setting using option 5 or you can change the value using option 2.  The list of system values displayed shows the name of the value and a text description.  Often, this is not enough information for you to determine exactly what you’re looking at.  When I find myself in this situation, I put a 5 next to it, then position the cursor over the current value displayed and press the HELP (or F1) key.  The help text that comes with this command is quite comprehensive and very helpful.

Changing any of your security system values should not be done on a whim.  Planning and preparation are the watchwords for this process.  It is all too easy to shoot yourself in the foot by making a security change in the fly and then losing, for example, the ability to log into your system.  All security changes should be researched in advance to determine the exact impact on your system.  If you’re not sure, do the work to find out rather than just trying it out without knowing the impact.

Once you have your security system values set along with the other system values (and there are loads of them), it is a good idea to lock them in place.  On too many systems, there are just too many users with all object (*ALLOBJ) and security administrator (*SECADM) permissions in their user profiles.  By locking the system values, this will prevent casual changes to the system values and thereby preserve the security policies that you’ve designed and implemented.

To lock your security system values in place, you can use the System Service Tools.  To lock the settings, start up the System Service Tools from a display session using the Start System Service Tools (STRSST) command.  You will need to supply your service tools user ID and password to complete the start of the tools.  Once started, choose option #7 from the menu (Work with system security).  Then, from the next screen, use option 2 to lock the security system values in place.

Once these are locked in place, you can only unlock them to make changes by first going back into the System Service Tools and unlocking them from the same screen where you locked them.  The unlock option is done by entering option 1.  These settings can also be manipulated during IPL time by running the Dedicated System Tools (DST).  Once locked, even users with *SECADM or *ALLOBJ cannot make capricious changes to the security system values so your security policy decisions will remain in force without worry.

If you have any questions about this topic you can reach me at (rich at kisco dot com),  I’ll try to answer any questions you may have.  All email messages will be answered.

Watch Your System Values

By Rich Loeber

Since the system values control how your system works, it is important that they be set correctly and that you know what those settings are.

When we installed a new IBM i server in our office, it was an exciting time and we normally rush to get the system set up so we can move operations onto the new hardware as soon as possible.  Since we do this kind of changeover infrequently (this was our 4th system since 1988), we are not really what you consider to be experts in this field.

We got our new system up and running and then unplugged our venerable, now antique, server.  We found that some things seemed to be working differently.  It took us a little while to sort it out, but some of the issues we were having could be traced back to the fact that several system values were now set up differently from our old system.  And, to our dismay, the old server was now on a truck on its way back to the leasing company.  So, we were left to sift through the system value listing and see if we could remember what our old system was configured for and get it reset.  Shame on us, we should have thought about this before releasing our former system.

I’m sure that we are not alone with this problem.  In fact, system values are so critical to how a system behaves, that having a current inventory of their authorized settings should be an  important part of your security plan.

The easy way out of this is to just run a complete listing of the current system values using the Work with System Value (WRKSYSVAL) command.  If you prompt this command, there is an output parameter that will allow you to run a complete listing to a print spool file.  This report will show you all of the system values on your system along with the current value,  the value as it was shipped from the factory and a description of the value.  Then, just print the simple 3 page report and keep it in an active file.  While you’re at it, take a look at those values that are different from the factory defaults on your system and make sure you understand why the changes have been made.  Those system values that are different are identified by a > character on the report between the system value and the current value setting.

If you’re like me, however, it would be nice if you could automate this process, even just a little.  One way to help with this is to keep the report in a physical file on your system.  You could create a separate member for each day when you run the report and then see if system values are changing.  I set this up on my system by creating a simple physical file in library QUSRSYS named QSYSVALUES using the following command:

CRTPF FILE(QUSRSYS/QSYSVALUES) RCDLEN(132)
MBR(*NONE) MAXMBRS(*NOMAX)

Then, run the report with the output going to an output queue that will not print right away.  You can do this with the following command:

WRKSYSVAL OUTPUT(*PRINT)

Lastly, save the report in your database file with the following command:

CPYSPLF FILE(QSYSPRT) TOFILE(QUSRSYS/QSYSVALUES)
SPLNBR(*LAST) TOMBR(V20130517)

In this case, the member name gives the year, month and date when the values were stored (May 17, 2013).

If you set this up to run once a month, you can then build up a collection of system value reports that you can check against each other.  This will help you to know that the values are not changing over time and, if they are changing, get you started on back tracking as to when they got changed.  If you’re feeling adventurous, you could even create some database query programming to check for changes from one member to the next.

System values are critical to how your system works.  Keeping them under control will keep your system running smoothly.

If you have any questions about this topic you can reach me at (rich at kisco dot com),  I’ll try to answer any questions you may have.  All email messages will be answered.

The Case For Better User Profile Names

By Rich Loeber

Ever since I started working in an environment where I needed a user profile and password (yes, there was a time when these were foreign concepts), I have always used a simple profile based on my first name.  As I moved from System/34 to System/36 to AS/400 to iSeries to IBM i on PowerServer, I just kept that same simple profile name.

But …. no longer.  I am now a firm believer that first name profiles are a very bad idea.  There are several reasons for this change.

First, recent studies show that people are really bad about picking secure passwords.  Current studies show that, unbelievably, the most commonly used password is “password”!  Check this for a recent list of the most commonly used passwords.

Since people are so bad about choosing passwords, having a user profile that is easy to guess makes a scripted attack very possible.  In a scripted attack, a hacker attempts to gain access to your system by trying a typical user profile in combination with the list of commonly used passwords.  If your system has simple first name profiles, then it could be at risk.  Even if the hacker does not gain access to your system, they could easily end up disabling a lot of your user profiles because of multiple logon failures.

There are two ways that a scripted attack is normally mounted.  The most obvious is via FTP.  In the scripted attack, a series of logon attempts is done using an automated FTP client.  Common profiles are coupled with common passwords and repeatedly tried to see which combination works.  When a match is found, the profile/password is reported back to the hacker so they can explore further at their leisure.

On our IBM i test box, FTP scripted attacks are all stopped before they get to the point where a logon is run.  This is because we use our SafeNet/i exit point security software that only lets FTP connections in from known and trusted IP addresses.  We collect the profiles used, however, so we can report to you on the most commonly used profiles that we are seeing.  From these FTP attempts, the most common user profiles used are:

ADMINISTRA
ADMIN
TEST
ALAN
ALBERTO
ALEX
AMANDA
ANGELA
ANNA
ANONYMOUS

Since we are protected by SafeNet/i, we were not too worried about the few common user profiles we had until a recent attack resulted in two profiles being disabled.  We quickly turned to our exit point log, but there was no record of the activity.  We also checked the system log (DSPLOG) but nothing reported there shed any light on why the profiles, including my trusted personal profile, got shut down.  As a last attempt to discover what happened, we turned to the system security audit journal.  What we found there was an eye opener.

We run the POP server on our IBM i.  We use it, in combination with the SMTP server, for sending outbound email from the system with our WebReport/i software.  This lets us send email without depending on any other office servers.  What we discovered from the system audit journal was that another form of scripted attack was taking place under the covers on the system with no knowledge on our part.  A little research revealed that we were being subjected to what is known as a “Brute Force POP3 Attack”.  It is like an FTP scripted attack, but broader in scope.

An analysis of the T-PW records recorded in the security audit journal showed that over a one month period, more than 20,000 attempts had been made to log into POP3 accounts.  Fortunately for us, we were protected by quite a few other best practices for IBM i security, not the least of which is that we do not use the POP server on our IBM i for inbound mail, so none of the mailboxes actually exist.  That, however, does not stop the hacker from trying.  And, since people tend to use the same password in all places, a user profile/password combination found at the POP server level could easily be tried to gain access to the system by other means.  From our analysis of these break-in attempts via the POP server, the most common user profiles are:

ADMIN
INFO
DATA
TEST
ROOT
MARK
SERVER
MAIL
MARY
SUPPORT
ORACLE
GUEST
DANIEL
GEORGE
ALEX

By looking at these, it is clear that the hacker or hackers are not aware of the type of system that they are trying to access.  None of these profiles are commonly used on the IBM i platform.  But, you can see some profiles that might easily be in existence on a normal system deployment which gives cause for concern.

What can you do?

Here are some simple ideas in brief:

  • Don’t keep the POP server active on your system if you don’t need it.
  • Don’t keep the FTP server active on your system if you don’t need it.  If you do need it, only have it active during hours when you expect it will be used and shut it down during other times.
  • Implement enforced password rotation if it is not already active.
  • Implement the user profile password rules to always require a numeric digit as a component of the password.
  • Review the active profiles on your system for simple first names and get them changed.
  • Check the common profiles used on most IBM i systems and make absolutely certain that their passwords are complex and hard or impossible to guess.
  • Implement exit point controls, check out our SafeNet/i product.
  • Consider disallowing vowels in your passwords.  IBM i system value password controls will let you do this.  At a minimum, rule our the letters E and A.
  • Check your system security audit journal regularly for T-PW records to see if you are getting unexpected password denials.

If you have any questions about this, or you need help with implementing any of these recommendations, feel free to contact me by email at rich @ kisco.com.  All email inquiries will be answered.