Logo Background

Unexpected results when port scanning AS/400

  • Penetration testers often use port scanning as a first step to discover active hosts and to map-out active network services. This is often done without any hesitation once the written formalities are completed. That’s exactly what I did in one of my assignments that included AS/400 (now iSeries) systems, and things did not turn out as expected.

    I issued an nmap service version and OS detection scan on the target network:

    nmap -sV -O -iL case_4301_hosts_1.txt

    All seemed to go well and I got my results, until about an hour later when the test subjects started to crawl and did not accept new requests. The system administrator ended up rebooting the affected systems which restored everything back to the way it was supposed to be. Good for me that it was a planned activity and no one was affected by it.

    After some research, I found out that the problem faced was a known issue related to the Distributed Data Management (DDM) server and a PTF (Program Temporary Fixes) was issued by IBM. Here is the description of the problem provided with PTF SI12889:

    DESCRIPTION OF PROBLEM FIXED FOR APAR SE14576 :
    -----------------------------------------------
    Port scanner causes DDM server for port 446 to not respond. Port scanners connect, then send RST. This wakes up select(), the application comes down to do the accept(), but the connection has already been reset, and there is nothing there to accept, so the accepts() blocks. When the problem occurs with port 446 not working anymore, it is because QRWTLSTN listens on multiple ports, 446, 447, 448. The accept got blocked waiting for a connection on either port 447 or 448, which will never come or never come for a long time. The accept() should be a non blocking accept, then this problem would not occur.

    During my research I came across others who faced similar issues but did not relate to the specific issue I faced. Was a robust TCP/IP stack an after thought for the OS/400? …

    If you would like to share your experiences, please feel free to do so by leaving your comment below.

    Share / Save

Advertisement

  1. #1 ohess fourhundred
    December 16, 2008 pm30 8:08 pm

    OS/400 has this problem for years. I opened a ticket with IBM in the V4Rx days and it’s still not resolved. At the they didn’t know what nmap is, and in fact their front line OS/400 support technicians still don’t know what nmap is. I port scanned a V6R1 system which caused a DoS of the TCP service. The system couldn’t accept new connections, but existing TCP connections remained active. Anyways, the quick fix is not to reboot, but to simply issue these commands:
    endtcp
    strtcp

    I am surprised that the OS/400 controller you mentioned above rebooted the server. He should really learn the OS.

    Post ReplyPost Reply
Leave a Comment