ip.buffer App Note AN009 : Security Considerations

Transcription

1 ip.buffer App Nte AN009 : Security Cnsideratins

2 Date Authr Release MP Initial draft UK 2008 Scannex Electrnics Limited. All rights reserved wrldwide. Scannex Electrnics Ltd, UK t: +44(0) f: +44(0) Scannex LLC, USA t: BUFFER ( )

3 Table f Cntents 1.Intrductin Prtecting the PBX Using the mdem in the ip.buffer Prtecting the ip.buffer cnfiguratin Prtecting pass-thrugh prts Prtecting delivery sckets push (SMTP client) HTTP pst t web server FTP Server FTP Push TCP Server (passive) TCP Push Legacy Emulatin Netwrk Services...10

4 Scannex ip.buffer AN009 : Security Cnsideratins UK 2008 Scannex Electrnics Ltd. All rights reserved wrldwide. 1. Intrductin Since the ip.buffer ften needs t exist in the cntext f a netwrk, cnsidering the security implicatins f using the ip.buffer is ften a requirement fr the installatin. The ip.buffer uses a rugged real-time perating system, called INTEGRITY by Green Hills Sftware ( Green Hills Sftware takes security very seriusly, and the perating system is built with security in mind. Fr example, they have recently annunced a versin f INTEGRITY that is the wrld's first perating system t achieve NSA's EAL6+ certificatin ( certified t prtect classified infrmatin and ther high value resurces at risk f attack frm hstile and wellfunded attackers ). The TCP/IP stacks are als by Green Hills Sftware. Scannex are supprted by Green Hills Sftware in maintaining the security f the ip.buffer. Hwever, given the flexibility f the ip.buffer, there are still issues that shuld be cnsidered when deplying the ip.buffer. The aim f this dcument is t utline the main issues 1. 1 This dcument cvers features that are available in versin Hwever, nly a few features are new t v2.30 mst f the security features are available in earlier versins. Page 1

5 Scannex ip.buffer AN009 : Security Cnsideratins UK 2008 Scannex Electrnics Ltd. All rights reserved wrldwide. 2. Prtecting the PBX Usually the ip.buffer is cllecting data frm the PBX and frwarding this data t a central system fr prcessing. Smetimes end users can be nervus abut the link between the PBX and their netwrk. They may wnder if peple wh telephne in can access their netwrk systems. Obviusly the PBX itself has a pivtal rle t play in terms f security. Here are sme general guidelines: If the PBX is cnnected with a serial, RS232, cable t the ip.buffer, n ne phning in can gain access t the netwrk. It is impssible fr the serial cable used fr data lgging t carry netwrk traffic. Sme PBX mdels accept prgramming infrmatin thrugh the data lgging prt. If the PBX is cnnected with a serial cable t the ip.buffer, then a custm cable can be made that has n cnnectin between the ip.buffer's transmit line and the PBX's receive line it is then impssible t send anything back t the PBX. Mst PBXs can disable this feature. When disabled inside the PBX, there is nthing anyne, r the ip.buffer, can d t change the PBX, r make calls. If the ip.buffer is being used as a gateway t allw netwrk-based mves and changes (i.e. reprgramming the PBX remtely), then the ip.buffer prvides several mechanisms t increase security. See sectin 6. If the ip.buffer is nt being used as a gateway t allw mves and changes t the PBX, there is n link between the ip.buffer's delivery mechanism and the PBX. (e.g. an FTP-Push frm the ip.buffer will nt prvide a means t write back t the PBX). The ip.buffer des have a pass-thrugh TCP/IP scket that allws fr mves and changes cnnectin. This can be disabled cmpletely in the prgramming f the ip.buffer. Page 2

6 Scannex ip.buffer AN009 : Security Cnsideratins UK 2008 Scannex Electrnics Ltd. All rights reserved wrldwide. 3. Using the mdem in the ip.buffer Sme versins f the ip.buffer have a built-in mdem that prvides access t the ip.buffer cnfiguratin web-pages and ther services. The internal firmware design f the ip.buffer was built with security in mind: When dialling int the ip.buffer frm the utside: The ip.buffer uses CHAP (r PAP) authenticatin t authenticate the incming caller. Withut a crrect lgin, the caller will be discnnected. The incming PPP caller has n access t the LAN. The TCP/IP stacks in the ip.buffer have had the packet-frwarding stripped at cmpilatin time. Cnsequently, it is impssible t dial-in and use the ip.buffer as a ruter nt the LAN. The nly device a caller has access t is the ip.buffer itself. When the ip.buffer dials ut t deliver data, alerts, r lgs via the mdem: The ip.buffer is firewalled t prevent traffic frm entering the ip.buffer while n a (pssibly) untrusted PPP netwrk. The ip.buffer maintains cntrl f the mdem link when the data transfer is cmplete the mdem will be hung-up and reset. It is nt pssible fr anyne f the remte netwrk t keep the mdem link active. If the abve is nt sufficient: The ip.buffer can be prgrammed t abrt all incming calls (by setting a zer secnd answer time). The ip.buffer will never be able t accept an incming call, r establish a netwrk link (withut being reprgrammed). The utbund telephne numbers can be blanked ut in the prgramming. Then the ip.buffer will never attempt t dial ut. The mdem lead can simply be unplugged! Page 3

7 Scannex ip.buffer AN009 : Security Cnsideratins UK 2008 Scannex Electrnics Ltd. All rights reserved wrldwide. 4. Prtecting the ip.buffer cnfiguratin The ip.buffer includes ptins t increase security fr prtecting the cnfiguratin parameters in the ip.buffer. The specifics are cvered in the ip.buffer manual. Hwever, these are sme f the features available: There is SSL/TLS firmware available fr free dwnlad frm ur website 2. The SSL/TLS firmware adds high strength AES encryptin t all services including the web-access. Yu can prgram the ip.buffer t frce the use f https cnnectins. All traffic between the PC web-brwser and the ip.buffer web-server is cmpletely prtected. The ip.buffer can be laded with an SSL certificate either generated by the ip.buffer, r by the custmer. Any web-brwsers that cnnect t the ip.buffer can then prve whether they are cmmunicating with the crrect ip.buffer (this prtects against man-in-the-middle attacks). When authenticating with a web-brwser the PC will pass the username acrss the netwrk t the ip.buffer. If the cnnectin is https then neither the username, nr passwrd, can be seen by anyne. The ip.buffer can enfrce Digest authrizatin. In this mde, the brwser will nly pass an MD5 signature f the passwrd never the actual passwrd. This effectively prtects the administratin passwrd frm sniffing attacks n the netwrk 3.!The user shuld be careful nt t stre the username/passwrd cmbinatin n the PC they are using especially if the PC is accessible by thers!!when nt using RADIUS there is nly a single username/passwrd fr the administratin f the ip.buffer. Obviusly this shuld be prtected! The ip.buffer des als include a WebLck feature that prvides a limited time windw fr the username t wrk. The user must btain a temprary unlck cde frm the persn hlding a secret that has been previusly laded int the ip.buffer. This allws fr safe telephne activatin, r temprary engineer access. The ip.buffer can authenticate back t a central RADIUS server: 2 Please nte that the cuntry yu are using the ip.buffer in may have strict legislatin n the use f cryptgraphic firmware it is yur respnsibility t make adequate checks in this regard! 3 The username is visible. Page 4

8 Scannex ip.buffer AN009 : Security Cnsideratins UK 2008 Scannex Electrnics Ltd. All rights reserved wrldwide.!nte that Digest authrizatin is technically impssible when authenticating back t RADIUS. Fr maximum security, https cnnectins shuld be enfrced by the ip.buffer. The central RADIUS server can maintain a large list f username/passwrd cmbinatins fr the ip.buffer(s). Nt giving the same username & passwrd t every persn is a prtectin any passwrd that is cmprmised can be immediately disabled at the RADIUS server (withut affecting the ther users). The ip.buffer can generate several different frms f ntificatin when the cnfiguratin is changed, r when an attempted access has been made: SNMP traps are sent ut t the designated SNMP trap agent. A syslg message is sent t the designated syslg server. An r http alert can be sent. Infrmatin is als stred in the RAM-based lg (which can be ed r http pushed).!since the cnfiguratin itself culd cntain sensitive infrmatin (e.g. even the passwrd fr the web-access itself): There is an ptin t hide all passwrds. When viewing cnfiguratin data n the ip.buffer the user will see ********. Anyne sniffing n the netwrk wuld thus nt be able t extract the passwrds. (But again, frcing https cnnects prevents all sniffing activities.) The web-pages that have sensitive cnfiguratin infrmatin are all prtected by passwrd in the web-server. There are a few pages that are available t view by anyne n the ip.buffer: The Status page. This page cntains very limited infrmatin. It prvides enugh infrmatin t tell if all cnnectins are wrking. Hwever, it will never divulge user & passwrd infrmatin, etc. When the ip.buffer s, r http pushes, the status infrmatin t a central system, that status infrmatin cntains n sensitive data (like usernames, passwrds etc). Page 5

9 Scannex ip.buffer AN009 : Security Cnsideratins UK 2008 Scannex Electrnics Ltd. All rights reserved wrldwide. 5. Prtecting pass-thrugh prts The ip.buffer prvides pass-thrugh sckets that allw bidirectinal access t the PBX when mves and changes must be dne remtely. Hwever, this feature is cmpletely prgrammable. The ip.buffer prvides the fllwing features: Yu can cmpletely disable the pass-thrugh n a channel by setting the listening prt t zer. When using the SSL/TLS firmware, the scket can be a TLS scket, i.e. encrypted. Any attempts at cnnecting nn-encrypted will be rejected. This is highly desirable when granting access t a PBX that allws mvesand-changes! The ip.buffer can be prgrammed t accept cnnectins frm nly ne IP address. All ther PCs will be rejected when they attempt t cnnect (even befre asking fr a passwrd!). The ip.buffer can authenticate back t a RADIUS server t validate the incming scket. The user will need t enter a username & passwrd. If nt using RADIUS, the pass-thrugh scket can be prtected by a simple passwrd.!if the scket cnnectin is nt encrypted SSL/TLS, then this passwrd culd be fund by sniffing the netwrk. The pass-thrugh prt has varius mdes that can be cnfigured: Stred & Nt stred - these mdes prvide bidirectinal access t the PBX (whether cnnected by serial r netwrk).!yu shuld prtect pass-thrugh sckets with at least ne f the abve methds. Mnitr - the pass-thrugh scket is read-nly. Nthing sent by the user is ever sent t the PBX. Page 6

10 Scannex ip.buffer AN009 : Security Cnsideratins UK 2008 Scannex Electrnics Ltd. All rights reserved wrldwide. 6. Prtecting delivery sckets The ip.buffer has a very flexible set f delivery methds. Sme cmments n security fr each mde are utlined here: push (SMTP client) There is n real risk t the ip.buffer. Hwever, since the ip.buffer is cnnecting t an SMTP server there shuld be adequate security in place, especially if that server prvides frwarding. The ip.buffer can authenticate t the SMTP server with a username and passwrd. When using the SSL/TLS firmware, the ip.buffer can establish either an implicit r explicit encrypted link with the SMTP server befre sending any authenticatin infrmatin 4.!If nt using an SSL/TLS link t the SMTP server, then the data can be sniffed acrss the netwrk. Scannex prvide a prprietary 40-bit encryptin fr the data that will prvide gd bfuscatin f the data. Obviusly the receiving end has t be prgrammed t decrypt the data t. Yu can chse t zlib cmpress the data. This will prvide anther layer f bfuscatin, and will prbably prevent all but the mst determined hacker frm seeing the data. Again, the receiving end must knw hw t decmpress the data HTTP pst t web server There is n real risk t the ip.buffer. Cnsideratins are similar t the push. The ip.buffer can authenticate t the web server with a username and passwrd.!the ip.buffer will nly use Basic authrizatin t the web-server, s the username and passwrd can be sniffed. Yu can put IP-based restrictins in the web-server t enhance security. The SSL/TLS firmware can https pst, using strng encryptin. Make sure the url begins with and that the SSL/TLS firmware is laded. If nt using SSL/TLS, then the same security issues fr the transferred data exist see abve FTP Server The ip.buffer is behaving as a server: 4 Obviusly, the SMTP server has t supprt encrypted cnnectins! 5!The itself des disclse that the data is zlib cmpressed, when this ptin is used. Page 7

11 Scannex ip.buffer AN009 : Security Cnsideratins UK 2008 Scannex Electrnics Ltd. All rights reserved wrldwide. The channel's data is prtected by a username and passwrd.!the FTP prtcl sends the username and passwrd acrss the netwrk in the clear. The SSL/TLS firmware allws: The client t cnnect t the standard, unencrypted, prt 21 and request an upgrade in security. The tw devices then establish a high strength encrypted channel. Then all usernames, passwrds, cmmands, and data are all prtected. The ip.buffer can set the FTP server t frce an encrypted cnnectin: Implicit encryptin the cnversatin begins encrypted. Explicit encryptin the FTP server will nt allw username, passwrd r data t be passed acrss the link until SSL/TLS encryptin has been requested by the client.!since there is a single, cmmn, FTP server, if cllecting frm a Cisc Call Manager using FTP Server cllectin, then encryptin cannt be frced (since the CCM needs t make an unencrypted FTP link). The cnnecting FTP client must be relied n t instruct the ip.buffer's FTP server t use SSL/TLS FTP Push The security cnsideratins fr FTP push are the same as fr push, in sectin 6.1. Fr the SSL/TLS firmware, the ip.buffer can make a cnnectin t an SSL/TLS-enabled FTP server. This can be either: Implicit SSL/TLS Explicit SSL/TLS When nt using SSL/TLS, the data can be prtected in the ways utline abve TCP Server (passive) The ip.buffer can be prgrammed t: The Allw field in the ip.buffer can restrict access t ne device by its IP address. The ip.buffer can restrict access t: LAN nly, Incming PPP mdem nly, r bth. The SSL/TLS firmware versin can use an encrypted TCP/IP scket. The ip.buffer can be prgrammed t authenticate back t a RADIUS server. When RADIUS is nt used, a simple passwrd can be used. Obviusly this is sent in the clear unless SSL/TLS encryptin is used. Page 8

12 Scannex ip.buffer AN009 : Security Cnsideratins UK 2008 Scannex Electrnics Ltd. All rights reserved wrldwide. The client cannt write back t the PBX TCP Push Like the ther push methds, the data can be prtected as utline abve. TCP Push als allws the ptin f using an SSL/TLS encrypted scket. The client cannt write back t the PBX Legacy Emulatin When emulating legacy devices in the ip.buffer the amunt f additinal security that can be prvided is limited (since we have t emulate an lder device that may nt be as secure). Hwever, the ip.buffer des have these facilities: The service can be restricted t ne device by its IP address (by using the Allw field in the ip.buffer) The ip.buffer can restrict access t: LAN nly, Incming PPP mdem nly, r bth. When using SSL/TLS firmware, the legacy emulatin can use an encrypted scket 6. The legacy emulatin script itself dictates what the client can d. This may allw nly reading data. Hwever, sme scripts prvide bi-directinal access back t a PBX hwever, these mdes ften nly wrk in tandem with ther explicit settings made t the ip.buffer. Scannex recmmend using the standard TCP/IP methds f cnnectin instead f Legacy Emulatin whenever pssible! It is mre secure! 6 Nte that legacy dial-in mdem access is nt pssible when using SSL/TLS encryptin. Page 9

13 Scannex ip.buffer AN009 : Security Cnsideratins UK 2008 Scannex Electrnics Ltd. All rights reserved wrldwide. 7. Netwrk Services The UDP and TCP prts f mst f the ip.buffer services can be cnfigured. All services are enabled by default. Hwever, in a secure envirnment it is preferable t disable any unused services. The ip.buffer manual dcuments hw t disable each service (usually by setting the TCP prt t zer, r by blanking ut the name/ip address field). This is the list f nn-cnfigurable prts in the ip.buffer: TCP prt 80: used fr the web-server ( http ). TCP prt 443: used fr secure web-server ( https ). UDP prt 161: SNMP agent. The SNMP agent prvides nly simple system level respnses. This is t allw autmatic asset management sftware t find the ip.buffer n the LAN. It has n SET ability, i.e. n changes can ever be made thrugh SNMP the cde just isn't there! UDP prt 56024: The Scannex SEDiscver prtcl. Packets frm the PC are bradcast t The prtcl nly wrks acrss the LAN and will nt functin acrss a ruter/firewall. It is impssible t discver ip.buffers n the ther side f a firewall r ruter. The current prtcl in the ip.buffer will send back respnse packets frm t (the same behaviur as the DHCP initialisatin prcess). Earlier versins f the ip.buffer sent back respnses direct t the PC's IP address, appearing t riginate frm the same IP address. Many mdern switches saw this as a land attack packet and dumped it (hence the change t a slightly revised prtcl). Page 10