Lo esencial del artículo de Edwards:
Security is one of the AS/400’s strong points. The architecture of OS/400 makes it immune from the kind of malicious executable code which often spreads over the Net – viruses, worms and Trojan horses. The hackers who have caused havoc on Windows NT and Unix systems can’t do anything with the AS/400, even assuming they know it exists. Even on the Internet, there are no back doors into an AS/400: thanks to OS/400’s native security, every approach is blocked by user-level access control. In short, security worries can be left to the Windows crowd: AS/400 users don’t even need a security policy.
The first sentence of the previous paragraph is true: whether in the office or on the Net, OS/400 is preferable to almost any other operating system in security terms, and vastly preferable to Windows NT. Unfortunately, the rest of the paragraph contains three half-truths and a lie. The time to put your feet up and forget about security hasn’t yet come. The AS/400 is good, but it’s not quite that good.
Tres verdades a medias: "a prueba de virus", "los hackers no conocen al AS/400", "el AS/400 no tiene puertas traseras".
Virus:
The world of Windows is infested with ever more sophisticated viruses: blocks of code which attach themselves to other files when an infected file is executed or opened. Before there were viruses, Unix administrators were familiar with worms (programs which copy themselves when executed) and Trojan horses (programs which imitate normal functionality while carrying out other tasks). All of these are peculiarly difficult to achieve under OS/400.
However, ‘difficult’ doesn’t mean ‘impossible’. OS/400 is harder to fool than Unix (which in turn is more secure than Windows NT), but techniques for bypassing its internal security measures are known. (...). To create a Trojan horse program, for instance, a malicious programmer would only need access to the CRTCMD command and authority over a product library. If a command run from a product library calls a second command with an unqualified name, the system will look for the command in the product library. A command could thus be created in the product library with the same name as a system command. The duplicate command would run every time the command was invoked by a program running from the product library; when the command was run normally, the original version would be used.
Preventing this from happening is a simple matter of restricting access to CRTCMD and CHGCMD, and perhaps also ensuring that commands are called using fully qualified names. However, the risk is real. Even the creation of a worm or a virus for OS/400 cannot be entirely ruled out, although it would be orders of magnitude more difficult than doing the same thing under Unix.
It’s also possible for the AS/400 to store virus-infected PC documents and Domino documents containing macro viruses in the Integrated File System. The viruses will not be activated under OS/400, but they will be sent unchanged to Windows clients.
Los hackers:
“Other than the default accounts that tend to use the same password as the username (which any admin worth the title will have changed), I would recommend [the AS/400] to anybody running a web server.” - ThePsyko (thepsyko@itookmyprozac.com), writing in newsgroup alt.hackers.malicious
The menace of hackers is often overstated; many security specialists regard most hackers as a nuisance rather than a serious threat to business. “If hackers do get into your system they’re more likely to want to use your machine time and storage space than steal your data. Mostly they’re joyriders rather than industrial spies,” says John Earl of PowerTech. Either way, to date hackers seem to have largely steered clear of the AS/400, as ThePsyko’s comment suggests. The web site http://www.attrition.org records 2,825 web sites ‘defaced’ by hackers between January and the end of July 2000. No attacks on AS/400 sites are recorded, compared with 1,831 sites running Windows NT, 476 running Linux and 416 running mainstream variants of Unix (including one AIX site).
However, this lack of attention in itself shouldn’t be seen as proving that the AS/400 is hackproof. “If you’re in business on the web, you aren’t exposing your system to a user here and a user there - you’re open to the world,” says IBM’s Carol Woodbury. “And you’re probably going to be attacked: there are some odd people out there who get their jollies from doing that kind of thing. Even if all your data is secure, your site could still be brought down by a denial of service attack (in which a web site is overloaded with dummy connection requests). That means lost business, the same as any other crash.”
Nor does the lack of information on successful hacks of the AS/400 mean that there have been no successful hacks. Information on IT security breaches is published by the Computer Emergency Response Team (CERT). However, as Woodbury told NEWS/400 in 1999, “We take a different tack than CERT does, which describes the problem and then says, ‘here are the patches.’ We just say, ‘here are the patches.’”. Security breaches are addressed by HIPER (HighImpact Pervasive) PTFs; the problem addressed by the PTF is described in one or two lines of laconic IBM tech-speak.
Puertas traseras:
“OS/400 is a highly secure operating system,” says Earl. “Rochester really started taking security seriously with OS/400 V3R7, and since then they’ve done an outstanding job.” Login in to an AS/400 requires a valid user name and password; user passwords are encrypted and cannot be cracked. Once logged in, access to data is rigidly controlled by the operating system, which enforces object-level authorities and access rights. The problem is that, in practice, these two forms of access control are usually supplemented by a third, dating from the pre-V3R7 days when level 10 security was the default: the menu system, which steers users through a range of permissible actions. The more emphasis your applications place on the menu system, the more vulnerable you are to unauthorised activity.
Earl explains. “Most AS/400 applications have one user profile which owns all the objects used by the application, and one group profile for all users. That’s fine in itself; the problems start when those two are the same profile. That means that every user has access to everything: access is controlled by the menu system. The trouble is, if you’re accessing the AS/400 using FTP you won’t see those menus.”
FTP (File Transfer Protocol) is a standard protocol for transferring data over TCP/IP. It is implemented on the AS/400 as a ‘service’, a program which is started up at IPL, remains continually available in the background and can be invoked by a user session or an application program. There are three points at which control is transferred to and from FTP:
· QIBM_QTMF_SVR_LOGON (FTP Server Logon)
· QIBM_QTMF_CLIENT_REQ (FTP Client Request Validation) and
· QIBM_QTMF_SERVER_REQ (FTP Server Request Validation)
Each of these exit points represents a potential hole which needs to be plugged. The way to do this is with “exit programs”: dedicated programs, registered with WRKREGINF for use with a specific exit point, which handle the transfer of control to FTP, validating the username and the requests made. There are two reasons for taking exit programs seriously. Firstly, they give the administrator detailed, fine-grained control over FTP: programs can be written to restrict certain users to particular directories or functions, to reject login attempts from unknown IP addresses, or even to extend the capabilities of FTP by permitting controlled login by anonymous users (not permitted by the AS/400, but near-essential if you’re using FTP on a web site). Secondly, if you don’t implement an exit program somebody else may do it for you. An exit program receives parameters from the user, executes some code to process them, then passes a request to the - and that second step is open to abuse. The sample code printed in phrack would enable any hacker with access to the AS/400 to run system-level commands in the guise of an attempted FTP login: the log file would record a failed login by a user called CRTDTAARA, for instance, while in fact the system was running a CRTDTAARA command under another user name.
Increased levels of complexity within the organisation also create security exposures. “A firewall – a box which sits between your server and the Internet and vets Net traffic – is a good thing to have, but it’s only effective at a single point,” warns Ian Kilpatrick of Wick Hill. “Many companies have multiple user departments using Internet connections to link up directly with different business partners – suppliers, distributors, outsourcing agencies. Addressing the security implications of all those connections requires an understanding of the whole of the company’s business. The old AS/400 network model is dissolving within the company as well: with more and more interconnected systems, there are more and more security exposures. As intranets become more pervasive, we’re starting to see companies implementing departmental firewalls. It may sound like overkill, but who do you want to protect your payroll database from – the teenage hacker outside the organisation or the disaffected employee inside it?”
Even traditional AS/400 applications are now raising security issues. “People have an ERP application, and suddenly they’re not looking at green screens any more,” says Jan Juul of PentaSafe. “They support ODBC querying, they have webbased intranet interfaces, they have print jobs routed through PCs for WYSIWYG formatting. All of those leave back doors open into the AS/400.” ODBC and JDBC enable PC users to run SQL commands against DB2/400; Client Access and even DDM open up the AS/400 to external clients. Exit point programs can be implemented for all of these access points. “You can’t rely solely on OS/400 security,” says Andy Coates of R/Utility. “Users can easily bypass the menu and application program security by using a PC connection. The problem is becoming widespread with more power users in organisations using spreadsheets and so on. Users are becoming adept at accessing the data they require; quite often this gives them access to data they should not have access to.”
It’s also worth noting that, as the references to FTP and TCP/IP suggest, OS/400 itself has changed. “As the AS/400 has progressively moved further into the world of ‘open systems’ it’s become progressively less secure,” says Juul. Nor is this progression over yet. “Future releases of WebSphere on the AS/400 are going to be based on the open source web server Apache,” says Juul. “It won’t be a simple port of Apache to the AS/400: it will be an AS/400 web server, encapsulated within the operating system. But there is a high level of knowledge about Apache in the hacker community, and having an HTTP server based on Apache has to create some additional exposures.”
The AS/400’s days as a closed, departmental network server are gone - and its status as a proprietary island of secure information with it. “Security on the AS/400 is built on the model of an internal network where everyone knows who everyone is,” comments Juul. “The design doesn’t cater for unknown users.”
Por supuesto, Edwards es optimista en cuanto a la posibilidad de controlar el riesgo:
The good news is that, even on the Internet, the AS/400 is securable to a higher level than Windows NT or most variants of Unix. Ironically, the inflated fears which have encompassed the growth of e-business may have made it harder to consider how to address the real issues of security, on and off the Net. “Security isn’t that hard,” says Earl. “It just needs a bit of attention. The main thing is not to be scared of thinking about it. There are identifiable risks, and there are things you can do to minimise them: the point is to quantify the risk and the expenditure, and find the point at which the cost of taking precautions is more acceptable than the potential cost of the exposure.”
(...)“The key requirement for information security policy is, simply, to have a policy,” says Kilpatrick. “A security policy worthy of the name needs to be detailed: ‘Don’t give away company secrets’ isn’t a policy. And it needs to be live. That means it’s up to date – those paragraphs about the secure disposal of typewriter ribbons can go – and it’s in force throughout the organisation: there’s no point formulating a security policy if it’s going to sit in a ring-binder on somebody’s shelf. Information security needs to be taken as seriously – and managed as formally – as physical security.” This point is echoed by Spencer Pratt of Internet security specialists Defcom. “As well as monitoring intrusion attempts, you need procedures for dealing with potential intrusions, including an escalation procedure. When do you talk to the press about a security breach and when do you try to keep it quiet? If your systems are hacked, do you want to prosecute or do you just want to make sure it doesn’t happen again?” Taking security seriously means treating it as an issue affecting the whole business.
So, what can you do? Focusing specifically on the AS/400, there are three main recommendations: deploy objectlevel security; limit non-AS/400 access; and implement a monitoring system.
No hay comentarios.:
Publicar un comentario