Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

FTP Security

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • FTP Security

    We use an adopted authority model on the AS/400. No user has direct authority to the application tables? How can I allow users I specify to GET one of these secured tables using FTP. I was told by two security software vendors that profile swapping can not be done via the FTP exit point. Does anybody have a suggestion?

  • #2
    FTP Security

    John, I don't know that it makes any difference what kind of authority a user/client has. If they have a valid profile in the AS/400 they can FTP GET/PUT anything in the system, whether they are authorized to the object or not. It's one of the security holes in FTP in the AS/400. Put up a test profile, *USER type, in your 400 without any authority, no command line privileges. Open a DOS prompt, open an FTP session into the 400, signon with the test profile, and do a get of something. It will come down. That profile can even delete the lib. I don't know if this common to FTP in general, or just to the AS/400. I haven't tried it anywhere else. If it's particular to the AS/400, I hope IBM has a fix real soon. Regards.

    Comment


    • #3
      FTP Security

      I just tried to get a file through ftp that had public authority of *exclude and I got a message that I wasn't authorized to that file. I don't believe it is true that ftp bypasses OS/400 object level authority. Scott Mildenberger

      Comment


      • #4
        FTP Security

        FTP does in fact use OS/400 Security. If you want to restrict/allow access to specific files, libraries, ability to run remote commands and various other sundry FTP services, what you should really do is create an FTP exit program to control access. This is in addition to a rational, well thought out and implemented security policy which you should have in any case. For a very good starting point on rolling your own, go to: Introduction to Anonymous FTP

        Comment


        • #5
          FTP Security

          Jack, FTP is not opening up your system, most likely it is public authority. All you need is read access to a file to download it using FTP. There are a lot of things you can do to prevent this. The manual "AS/400 Tips and Tools for Securing Your AS/400" describes how you can prevent unnecessary access via FTP. The main problem is that menu level security and adoption do not work well with these new ways of accessing your system. David Morris

          Comment


          • #6
            FTP Security

            Shannon, One thing my devious mind pictures when following the instructions at this site is someone uploading enough data to power down the system. I haven't tried this on my system, but to prevent it I set a maximum storage limit for annonymous. I also upload (write only) and download (read only) in seperate directories. David Morris

            Comment


            • #7
              FTP Security

              Good point David. Actually, I don't know that I'd recommend allowing anonymous FTP anyway. I mostly just wanted to point anyone who didn't know about this site, to it, for the example code posted there. It can easily be modified to make it site specific.

              Comment


              • #8
                FTP Security

                Shannon, I am being mostly hypothetical (it would take about a while at 56k to overrun my system's storage), but I suspect there are systems out there supporting unlimited annonymous access through a T1 line. David Morris

                Comment


                • #9
                  FTP Security

                  Thanks to all for the tips you contributed. Thanks to John for opening the thread. Actually I was parrotting a sales pitch from a software outfit. They have software I tried for 30 days to secure FTP and report on the activity. It looked good but it gave me some problems with being excessively secure. It locks out everyone until you identify who can do what, and then you have end and start the QSERVER subsystem to make changes active, each and every time you make a change. Anyway I argued with the sales guy over the phone that my object level (40) security and object authorization settings provided sufficient protection. He had me run the drill I described. I was surprised when it worked, at least against my systems. It appears I have to do some more work. I had read the manual on AS/400 Tips and Tools for Security about 4 yrs. ago. I guess I have to read it again Dave. Strange what you don't remember anymore.

                  Comment


                  • #10
                    FTP Security

                    We had the same issue using adopted authority. The solution we used was to create an additonal user profile for "remote" access to data. (i.e. data access not using our application programs - ODBC or FTP) This profile was added to the data objects as *USE access and also added to the user profiles of specific users as a supplemental group profile. Our issue was the use of the "Showcase" product for downloads of data, and this solution satisfied the issue. Paul.

                    Comment


                    • #11
                      FTP Security

                      Paul, thank you for your input, that is a good solution as long as the number of files is managable. It could get to be very cumbersome to maintain if there are a large number of files. If I wanted user JDOE to access file ORDERS and I wanted user MSMITH to access file PAYROLL but didn't want either to access the other, I would have to create two profiles. Everytime I wanted to grant access to a file I would have to create another profile. Practically speaking in my current situation this will probably work since I am dealing with a small number of files. I really don't understand why IBM won't allow profile swapping through an exit point for FTP. This would easily solve the problem. I would make an entry for the user or group in a table giving them access to the file and tell it to swap to the application profile when performing the GET. I see this as a form of adopted authority. They are already doing a profile swap internally and this overrides any swapping the user exit program might try to do.

                      Comment


                      • #12
                        FTP Security

                        Jack, fortunately that is not the case. FTP doesn't ignore OS/400 resource security. If the user doesn't have access to the file through a private authority, *ALLOBJ special authority, a group profile, *PUBLIC authority, etc. they won't be able to download the file. Maybe the security level of the system you were working on was 20 which gives everyone *ALLOBJ authority. This is my dilema, my users don't have direct authority to the files. The application programs run as USRPRF(*OWNER) when executing, the owner of the program DOES have authority to the file. This is known as an application authorization (adopted authority) model. What I need is a way of giving the user or group authority to *USE the file for the FTP application. Unfortunately I know of no way to do that under the current implementation. This is not unique to the IBM implementation.

                        Comment


                        • #13
                          FTP Security

                          We use an adopted authority model on the AS/400. No user has direct authority to the application tables? How can I allow users I specify to GET one of these secured tables using FTP. I was told by two security software vendors that profile swapping can not be done via the FTP exit point. Does anybody have a suggestion? <
                          John, I know that product promos are not allowed on this forum, but we have a product that does exactly this. Contact me privately if you please. johnearl@400security.com jte

                          Comment


                          • #14
                            FTP Security

                            We use DetectIt from Softscreen System and it works neat (the ODBC security is a bit shaky though).

                            Comment


                            • #15
                              FTP Security

                              You are correct that the adopted authority model can not be used in the server environment. However you can swap the user profile. There are several vendors in the security market that offer products that can swap the user profile. Rather than swapping the user profile I like to swap the group profile. That wway the audit records track back to the user but the user gets access from the group profile (much like adopted authority). The following is some code that can be used to swap the group profile. If you have questions or want additional informantion please contact me. Wayne O. Evans WOEvans@AOL.com /************************************************** **/ /* SWAPGROUP -- Swap Group profile */ /* This program changes the group profile. */ /* Swap the process to use the new group profile */ /* */ /* Installation instructions */ /* 1. Compile program */ /* CRTCLPGM PGM(LIB/SWAPGROUP ) */ /* SRCFILE( ) USRPRF(*OWNER) */ /* 2. Change owner of the program to user QSECOFR. */ /* Adopted authroity allows the program to swap */ /* user profiles without providing a password */ /* CHGOBJOWN OBJ(LIB/SWAPGROUP) */ /* OBJTYPE(*PGM) NEWOWN(QSECOFR) */ /************************************************** **/ PGM &NEW_GROUP DCL &NEW_GROUP *CHAR 10 DCL &OLD_GROUP *CHAR 10 DCL &USER *CHAR 10 DCL &STATUS *CHAR 10 DCL &HANDLE *CHAR 12 RTVJOBA USER(&USER) /* single stream the job */ ALCOBJ SWAP *DTAARA *EXCLUSIVE WAIT(500) RTVUSRPRF USRPRF(&USER) STATUS(&STATUS) + GRPPRF(&OLD_GROUP) CHGUSRPRF USRPRF(&USER) STATUS(*ENABLED) + GRPRPF(&NEW_GROUP) CALL QSYGETPH (&USER '*NOPWD' &HANDLE) CHGUSRPRF USRPRF(&USER) STATUS(&STATUS) + GRPPRF(&OLD_GROUP) /* End single stream */ DLCOBJ SWAP *DTAARA *EXCLUSIVE CALL QWTSETP (&HANDLE) ENDPGM

                              Comment

                              Working...
                              X