693 lines
33 KiB
Plaintext
693 lines
33 KiB
Plaintext
|
||
--=] National Security Anarchists [=--
|
||
--=] Volume I, Issue II [=--
|
||
--=] Date Release: 06/23/91 [=--
|
||
|
||
|
||
== NSA Introduction ==
|
||
|
||
Welcome to the second release of NSA newsletter. We have gotten quite a
|
||
response from our first newsletter, hope you get as much as a orgasm off
|
||
this one. Now let's get serious...
|
||
|
||
-------------------------------------------------------------------------------
|
||
Table of Contents
|
||
|
||
Section Contents
|
||
--------- --------------------------------------------------
|
||
2.0 NSA Introduction
|
||
2.1 Table of Contents
|
||
2.2 5ESS Switch, Software Release Retrofit Procedures
|
||
2.3 Trunk Port Capacity Provisioning for COs
|
||
2.4 ATM Research
|
||
2.5 Teleos: New Access Server Enhancements
|
||
2.6 SunOS /bin/mail Vulnerability/Credit: Sun/Os
|
||
2.7 NSA Information
|
||
|
||
-------------------------------------------------------------------------------
|
||
|
||
--=] National Security Anarchists [=--
|
||
--=] Volume I, Issue II [=--
|
||
--=] Presents [=--
|
||
|
||
== 5ESS Switch ==
|
||
== Software Release Retrofit Procedures ==
|
||
== 5E4 to 5E5 Software Releases ==
|
||
== AT&T 235-105-244 ==
|
||
|
||
|
||
GENERAL
|
||
|
||
This addendum supplements AT&T 235-105-244, Issue 1.03. It is to be
|
||
placed at the beginning of the manual. The information included in
|
||
this addendum will be incorporated into the next regular update of the
|
||
manual.
|
||
|
||
This addendum is issued to provide changes which have become apparent
|
||
since the last issue of the manual.
|
||
|
||
CHANGES TO MANUAL
|
||
|
||
Page 5-88, Step (replace)
|
||
|
||
3. The following step may be performedin teleprocessing offices to provide
|
||
backup AMA data in the vent that data from the final teleprocessing
|
||
session is lost or mutilated at the host collector. In performing this
|
||
step, the time interval from now to the system initialization is
|
||
increased by the amount of time required to generate the AMA tape.
|
||
|
||
Caution: All AMA data recorded between the final AMA teleprocessing
|
||
session and the initialization will be lost. Although the
|
||
following step will hlpe ensure the integrity of previously
|
||
recorded AMA data, the amount of AMA data that will be lost at
|
||
initialization time may increase by the amount of AMA data
|
||
recorded during the aforementioned time interval.
|
||
|
||
a. For offices that use teleprocessing, an optional manual AMA tape
|
||
writing session to dump secondary AMA blocks can be performed at this
|
||
time (AT&T 235-105-210, Procedure 3.19). This tape should be saved
|
||
for backup purposes.
|
||
|
||
|
||
Page 5-89, Step 5a (replace)
|
||
|
||
a. Single-stream office - enter message:
|
||
|
||
MSG OP:AMA:DISK;
|
||
|
||
Response: REPT AMA DISK SUMMARY FOR STREAM STx
|
||
DISK IS CURRENTLY xx% FULL
|
||
NUMBER OF PRIMARY AMA BLOCKS IN USE
|
||
IS APPROXIMATELY: xx
|
||
|
||
Comment : Due to design constraints, there may be a small amount of
|
||
primary AMA data in use on disk at this point.
|
||
|
||
To read the remaining primary AMA records;, start another
|
||
AMA teleprocessing or tape session (repeat Step 2).
|
||
|
||
To minimize the loss of AMA records, continue to initiate
|
||
AMA sessions until the number of primary blocks in use
|
||
(given by OP:AMA:DISK) reaches an acceptable level given
|
||
call traffic.
|
||
|
||
|
||
Page 5-93, Step 4 (replace)
|
||
|
||
4. Note 1: If ONTCs are ACTIVE MAJOR/MINOR (that is, duplex) on MCC Page
|
||
1209, uses S as the application parameter (to preserve stable
|
||
calls). If ONTCs are not duplex, use R sa the application
|
||
parameter.
|
||
|
||
Note 2: At this time, CU 1 contains 3 circuit packs that are not
|
||
compatible with the 5E4 software release currently cycling in the
|
||
AM. When CU 1 is forced on-line during the following initalizing
|
||
sequence, the switch will immediately go into a DMERT Level 3
|
||
recovery. It is essential that the AM boot (42-S-54) be
|
||
performed immediately after forcing CU 1 on-line.
|
||
|
||
To perform the initialization, enter the following commands on the EAI Page:
|
||
|
||
a. To force CU 1 on-line, enter:
|
||
|
||
CMD 11 Force CU 1 on-line, switch goes into level 3
|
||
recovery
|
||
Force CU 1? (y/n) y Force CU 1 on-line after "y" is entered
|
||
|
||
b. To set the apllication parameter, enter the following commands on the EAI
|
||
Page:
|
||
|
||
CMD 42 Sets application parameter mode
|
||
PARAMETER: S or R S saves stable calls; R does not
|
||
|
||
WARNING: Verify thateither S or R apperas (and is backlighted) to the
|
||
right of the APPL PARMA field on the EAI Page before proceeding.
|
||
If the S or R is not present and backlighted, reenter the 42 and
|
||
S/R commands again before proceeding to the boot.
|
||
|
||
c. To perform the initialization, enter the following commands on the EAI
|
||
Page:
|
||
|
||
CMD 54 Full AM boot on new software release
|
||
Boot? (y/n) y Boot begins after "y" is entered
|
||
|
||
|
||
Page 5-94, Section 5.6.7.1 (add after the last sentence)
|
||
|
||
As the AM recovers, ovserve the ROP for Asserts. If any Assers are
|
||
received, analyze them using the Asserts Manual (AT&T 235-600-500).
|
||
|
||
|
||
Page 5-98, section 5.610.1 (replace)
|
||
|
||
1. To verify that AMA is recording properly, enter message:
|
||
|
||
MSG OP:AMA:STATUS;
|
||
|
||
Response: REPT AMA STATUS FOR STREAM STx
|
||
|
||
SEGMENT STATUS
|
||
----------- ----------
|
||
1 xxxxx
|
||
2 xxxxx
|
||
3 xxxxx
|
||
|
||
LAST TIME DISK WRITER WROTE TO DISK hh:mm YY/MM
|
||
|
||
Comment: Save the ROP output for use in the next step.
|
||
|
||
Note: The percent full (number records) of each of the three SEGMENTS
|
||
will demonstrate the loading of AMA records in the SDS. Each time
|
||
the SEGMENT gets full, the disk writer writes that particular
|
||
SEGMENT to disk. The value of the segment has been written to
|
||
disk after the boot.
|
||
|
||
a. Enter the following message:
|
||
|
||
MSG OP:AMA:MAPS;
|
||
|
||
Response: REPT AMA DISK MAPS FOR STREAM ST1
|
||
WRITE PARTITION x READ PARTITION x
|
||
PARTITION x DISK MAP:
|
||
FPO:xx LPO:xx FPS:xx LPS:xx
|
||
FSO:xx LSO:xx FSS:xx LSS:xx
|
||
FBO:xx LBO:xx FBS:XX LBS:XX
|
||
. . . .
|
||
. . . .
|
||
. . . .
|
||
. . . .
|
||
|
||
2. Re-enter the message:
|
||
|
||
MSG OP:AMA:STATUS;
|
||
|
||
Response: REPT AMA STATUS FOR STREAM STx
|
||
|
||
SEGMENT STATUS
|
||
----------- ----------
|
||
1 xxxxx
|
||
2 xxxxx
|
||
3 xxxxx
|
||
|
||
LAST TIME DISK WRITER WROTE TO DISK hh:mm YY/MM
|
||
|
||
|
||
a. Enter the following message:
|
||
|
||
MSG OP:AMA:MAPS;
|
||
|
||
Response: REPT AMA DISK MAPS FOR STREAM ST1
|
||
WRITE PARTITION x READ PARTITION x
|
||
PARTITION x DISK MAP:
|
||
FPO:xx LPO:xx FPS:xx LPS:xx
|
||
FSO:xx LSO:xx FSS:xx LSS:xx
|
||
FBO:xx LBO:xx FBS:XX LBS:XX
|
||
. . . .
|
||
. . . .
|
||
. . . .
|
||
. . . .
|
||
|
||
|
||
3. Note: The amount of time it will take to verify AMA recording depends on
|
||
the amount of traffic on the switch. If your office has light
|
||
traffic, you should continue with the steps in this manual and
|
||
return to Step 2 (above) 10 minutes until you are satisfied that
|
||
AMA is recording properly.
|
||
|
||
Compare the OP:AMA:STATUS output from Step 1 with the
|
||
OP:AMA:STATUS output from Step 2.
|
||
|
||
The amount of AMA recorded depends on the amount of traffic on the
|
||
switch.
|
||
|
||
To verify that AMA is writing to a segment, compare the percent
|
||
full (number records) of the segments from Steps 1 and 2. These
|
||
should increase with traffic on the switch.
|
||
|
||
When one segment fills, it should be written to disk and a new
|
||
segmentwill begin to fill. To verify that AMA has written to
|
||
disk, check the LAST TIME DISK WRITER WROTE TO DISK - this value
|
||
should not be 00:00 00/00.
|
||
|
||
You can also verify the AMA has been written to disk by comparing
|
||
the output of the OP:AMA:MAPS commands issued in Steps 1a and 2a.
|
||
The second line of the output from the OP:AMA:MAPS gives a number
|
||
after WRITE PARTITION. Below this are listed the various
|
||
partitions available. Locate that partition corresponding to the
|
||
write partition number. Within this report are values for LPO and
|
||
LPS. Thse values should increase when AMA is written to disk.
|
||
|
||
If AMA has successfully written to disk and is writing into a new
|
||
segment , AMA is recording properly. If AMA is recording
|
||
properly, proceed to the next section.
|
||
|
||
If AMA is being recorded in one SEGMENT, but has not written to
|
||
disk, proceed to the next section but continue to monitor AMA. To
|
||
continue the monitoring, reenter the OP:AMA:STATUS message evey 10
|
||
minutes until the AMA successfully writes to disk.
|
||
|
||
If all SEGMENTS still indicate EMPTY, seek techinal assistance.
|
||
|
||
Caution: If at any time you are unsure that AMA is recorind
|
||
properly, do not hesitate to seek technical assistance.
|
||
|
||
|
||
Page 5-140, Table 5-5
|
||
|
||
The first number under the PTN column should read 0 instead of 1.
|
||
|
||
|
||
Page 5-148, Table 5-12
|
||
|
||
The first number under the PTN column should read 0 instead of 1.
|
||
|
||
-------------------------------------------------------------------------------
|
||
|
||
--=] National Security Anarchists [=--
|
||
--=] Volume I, Issue II [=--
|
||
--=] Presents [=--
|
||
|
||
== Traffic Engineering Guidelines ==
|
||
== Trunk Port Capacity Provisioning for COs ==
|
||
== EG-TFE-91.010.00 ==
|
||
|
||
|
||
EXECUTIVE OVERVIEW:
|
||
|
||
This guideline provides standards for provisioning trunk capacity (analog
|
||
and digital) in the central office switch. This capacity consists of the
|
||
forecasted amounts of trunks which terminate on the swithc, sas well as
|
||
some quantity, method , to provide for unidentified, unforecasted
|
||
requirements. The intent is to ensure the trunk capacity for central
|
||
office switches is engineered to cover the core engineering time frame, in
|
||
such a manner as to meet the unexpected customer demand and/or deployment
|
||
of unforeseen pari gain devices by GTE.
|
||
|
||
The existing PCM process authorizes engineering for forecasted switch
|
||
terminations to accommodate the message trunk forecast, the special
|
||
services forecsat, and pair gain host/remote links (future). This
|
||
guideline provides instructions for the engineering of unforecasted
|
||
miscellaneous switch terminations with COE core job/projects.
|
||
|
||
|
||
GENERAL DISCUSSION:
|
||
|
||
Competition is pushing GTE to respond to the customer on a shorter time
|
||
interval. In order to accomplish this, they must position GTE to allow
|
||
for rapid Trunk service provisioning. The availability of central office
|
||
Trunk Terminations through controlled engineering for 5-10% unforeseen
|
||
demand will ensure their ability to succesfully respond to customer demands
|
||
in a timely manner. The time required from customer request to
|
||
determination of equipment required, ordering, installing, testing is not
|
||
acceptable and is a contributing factor to GTE's loss of customer base.
|
||
Proper provisioning of trunk circuits in the right exchanges is essential
|
||
to responding to customers' needs.
|
||
|
||
Agreements are imminent which will provide for planned future pair gain
|
||
devices on the PCM by Planning. Existing links for pair gain devices will
|
||
be in the POTS/TTE trunk forecast. Therefore, margin for these links are
|
||
not provided via this process guideline.
|
||
|
||
This guideline does not provide margin for the message circuit trunk
|
||
forecast trunks. The trunk forecasters will not build margin into the
|
||
groups which they manage by the TTE program. In other words, existing or
|
||
imminent processes provide for switch terminations to accommodate TTE
|
||
forecast and H/R links.
|
||
|
||
Planning has concurred with their proposal to provide 5-10% margin for
|
||
trunk terminations in electronic switches. The decision on the precise
|
||
amount of margin to be order should be made by the Traffic Engineer. This
|
||
decision will be based on familiarity with the specific wire center and
|
||
service demands which have been experienced over the past several years,
|
||
along with knowledge of the specific switch configuration. Switches in
|
||
remote, slow growth areas would obviously requirrreless margin than
|
||
switches in metropolitan, high growth areas. Tandem or class 4/5 switches
|
||
may require larger margins due to the unpredictability of IXC demand.
|
||
|
||
|
||
GUIDELINE INSTRUCTION:
|
||
|
||
The existing PCM process authorizes engineering for forecasted switch
|
||
terminations to accommodate the message trunk forecast, the special
|
||
services forecast, and pair gain host/remote links (future). This
|
||
guideline provides instructions for the engineering of unforecasted
|
||
miscellaneous switch terminations with COE core job/projects.
|
||
|
||
Every core job/project should provision to accommodate unforeseen demand
|
||
for central office trunk terminations in addition to the
|
||
forecasted/projected requirements of the engineering period. The
|
||
unforeseen demand for trunk terminations will typically be engineered at
|
||
5% margin for rural offices and 10% margin for metropolitan offices.
|
||
Traffic Engineering of more than 10% Trunk Terminations margin will
|
||
require Planning review/approval.
|
||
|
||
Services that comprise unforeseen demand are:
|
||
|
||
o DID (on COE Forecast as lump sum)
|
||
|
||
o WATS (when served on trunks)
|
||
|
||
o Switched HI CAPS/Switched Data (DTI resources) (This is to be
|
||
forecasted by Market Forecasting as part of the CAF/SAL forecast.)
|
||
|
||
o MISC. (analog and/or DTI)
|
||
|
||
The central office switch common equipment capacity must be engineered to
|
||
carry both forecasted and unforeseen demand traffic as if all trunks were
|
||
incarry both forecasted and unforeseen demand traffic as if all trunks
|
||
were in service by the end of the core period. Twenty-four CCS per trunk
|
||
should be used to properly provision the switch's capacity. Application
|
||
as two-way split fifty percent incoming and fifty percent outgoing is
|
||
recommended unless that traffic engineer knows of local considerations
|
||
which warrant a different application.
|
||
|
||
When the engineer has determined the margin for the unforeseen demand, two
|
||
important decisions need to be evaluated: A) exact trunk or T1 quantities,
|
||
and B) associated CCS loads.
|
||
|
||
A. Trunk quantities - The exact number of margin trunks to be added
|
||
should be based on the TOGEN calculation of
|
||
required trunking and associated frames. Both
|
||
analog and digital margin should be provided
|
||
(unless a digital switch as been provision with no
|
||
analog trunks for DID). Margin trunks should be
|
||
calculated to fill frames where possible, and
|
||
consideration should also be given to the TCU
|
||
layout of the office.
|
||
|
||
Note: In all cases, when digital technology is the switch type, the
|
||
analog trunk frames should be wired so card slots are available
|
||
when shortages occur. Digital trunk FIUs can hold two QSIC cards
|
||
each, which provides four T1 saaapc lines. Currently they have to
|
||
pay right-to-use fees whenever a DTFIU is installed. GTE is
|
||
working to implement TRU fees paid as QSIC cards are installed.
|
||
Once that is the case there will be value to not installing the
|
||
QSIC cards, leaving slots open until they are needed.
|
||
|
||
Example 1: Metropolitan GTD-5 office requires 200 T1 spans for
|
||
forecasted/known trunking requirements.
|
||
|
||
200 T1 = 25 DTFIU
|
||
|
||
20 T1 - Recommended margin at 10%
|
||
|
||
220 T1 = 27.5 DTFIU
|
||
|
||
Recommendation - Provide 224 T1s to completely fill 28 DTFIUs.
|
||
Analyze TCU/FIU layout to assess impact on
|
||
TCU requirements. The DTFIU may be eliminated
|
||
if it requires an additional TCU.
|
||
|
||
Note: It is understood this example is representative of a "typical"
|
||
metropoloitan office. Engineering judgement, based on specific
|
||
site characteristics, may require more than 10% to be budgeted and
|
||
installed (with proper approval by Palnning).
|
||
|
||
Example 2: Rural GTD-5 office requires 30 T1 spans for forecasted/known
|
||
trunking requirements.
|
||
|
||
30 T1 = 3.75 DTFIU
|
||
|
||
2 T1 - Recommended margin at 5%
|
||
|
||
32 T1 = 4.0 DTFIU
|
||
|
||
Recommendation - Analyze TCU/FIU layout. If the fifth DTFIU
|
||
can be built into existing TCU, then provide,
|
||
if the fifth DTFIU would require another TCU,
|
||
do not provide.
|
||
|
||
B. CCS loads - Once the trunk quantities have been determined, a margin
|
||
trunk group should be built into the trunk summary. A CCS load of 24
|
||
CCS/trunk should be associated with these margin trunks so that common
|
||
equipment wil be calculated to include these trunks (specific impact
|
||
will be on TPC processors, MF receivers, and registers in the GTD-5
|
||
technology).
|
||
|
||
If additional TCUs and/or Digital Trunk FIus are required in the GTD5, or
|
||
additional Switch Modules are requires in the 5ESS, or more than 10%
|
||
margin is required, then Planning must review and provide
|
||
authorization/funding.
|
||
|
||
-------------------------------------------------------------------------------
|
||
|
||
--=] National Security Anarchists [=--
|
||
--=] Volume I, Issue II [=--
|
||
--=] Presents [=--
|
||
|
||
== ATM Research ==
|
||
== GTE Project 552 ==
|
||
|
||
|
||
Asynchronous transfer mode (ATM) has been standardized as the target
|
||
transfer mode for B-ISDN. It is believed to be a highly flexible
|
||
switching and multiplexing technique capable of supporting a wide range
|
||
of broadband and narrowband services. Although the conceptual view of
|
||
ATM seems attractive, the feasibility of ATM in practice is uncertain for
|
||
real-time services such as full-motion video, especially under the
|
||
assumption that some degree of statistical multiplexing is desirable
|
||
within the ATM network. The objective of this project was to evaluate
|
||
the technical feasibility and complexity of ATM for the delivery of four
|
||
full-motion video services: television distribution, video-on-demand,
|
||
videoconferencing, and videotelephony. The intra-LATA transport of these
|
||
video services over and end-to-end ATM network with a standard B-ISDN/ATM
|
||
interface was investigated.
|
||
|
||
The approach was based on a top-down view of the scenario at three
|
||
levels: services, network, and switching. At the service level, the four
|
||
types of video services and their related end-toend network transport
|
||
requirements were characterized. The effects of cell losses and cell
|
||
delays on video quality were investigated. At the network level,
|
||
alternative service topologies were compared to find the preferred
|
||
topology for deployment of each service (see Figure 552-1). The network
|
||
management and control issues were examined and traffic control methods
|
||
were proposed. At the switch level, the performance and drawbacks of
|
||
proposed ATM switch architectures were evaluated for the purpose of
|
||
switching full-motion video (see Figure 552-2). Finally, the end-to-end
|
||
transport requirements were related to the curretn state of ATM
|
||
techonology to draw conclusions about the technical feasibility of each
|
||
video service.
|
||
|
||
|
||
|
||
Source
|
||
________/ \_________
|
||
/ \
|
||
/ \
|
||
/ \
|
||
/ \
|
||
End Office/Base Unit End Office/Base Unit
|
||
/ \ / \
|
||
/ . . \ / . . \
|
||
/ \ / \
|
||
/ \ / \
|
||
BERLU BERLU BERLU BERLU
|
||
/ \ / \ / \ / \
|
||
/ \ / \ / \ / \<- Individualy
|
||
/ . . \ / . . \ / . . \ / . . \ Switched
|
||
BISDN ------?- Loops
|
||
|
||
|
||
Figure 552-1: Preferred service topology for television distribution
|
||
services. This topology minimizes the use of network
|
||
resources, ensures fast response to channel switching, and
|
||
mitigates ATM transport impairments.
|
||
|
||
|
||
|
||
____ _______ _________________ _______ _________________ _______ ____
|
||
. | 8x8 | . . | 8x8 | . . | 8x8 | .
|
||
. | SRM | . . | SRM | . . | SRM | .
|
||
__._|_______|_.___ ___._|_______|_.___ ___._|_______|_.__
|
||
\ / \ /
|
||
\ / \ /
|
||
. \ / . \ / .
|
||
(8) . X (8) . X (8) .
|
||
. / \ . / \ .
|
||
/ \ / \
|
||
____ _______ _____/ \_____ _______ _____/ \_____ _______ ____
|
||
. | 8x8 | . . | 8x8 | . . | 8x8 | .
|
||
. | SRM | . . | SRM | . . | SRM | .
|
||
__._|_______|_._____________._|_______|_._____________._|_______|_.__
|
||
|
||
|
||
|
||
|
||
Figure 552-2: A multistage self-routing fabric used in the Fujitsu
|
||
FETEX-150 ATM switch. Large ATM switches will be required
|
||
in order to offer enhanced video services to a large
|
||
customer base.
|
||
|
||
|
||
|
||
Television Distribution - Among the four video services studied, TV
|
||
distribution services appear to be the most
|
||
feasible, but large-scale multicast ATM switches
|
||
will be required. A network architecture that
|
||
allows switching as close to the customer as
|
||
possible is desirable.
|
||
|
||
Videoconferencing - Network management and control issues are
|
||
complex; the design, development, and deployment
|
||
of network suitable for videoconferencing will
|
||
be a major technical challenge in order to
|
||
guarantee quality of service interms of cell
|
||
delay/jitter and loss rate.
|
||
|
||
Videotelephony - For ubiquitous service, the complexity of
|
||
network level problems (e.g., traffic control,
|
||
network management) will be significant. Large
|
||
ATM switches will be required.
|
||
|
||
Video-on-Demand - For true point-to-point VOD, a robust ATM
|
||
backbone with processing capability for
|
||
mid-calling signaling will be required. At
|
||
present, such a network is not feasible,
|
||
although B-ISDN should have this capability. An
|
||
area-wide offering is feasible using "local"
|
||
video gateways installed at either the access
|
||
nodes or in remote units.
|
||
|
||
Overall, it was concluded that ATM techonology is not yet ready for its
|
||
role as a unified means of transport for B-ISDN. Tha main obstacles lie
|
||
in the areas of network traffic control and the development of large-scale
|
||
switching systems. Without effective solutions to these problems, any
|
||
ubiquitous offernign of on-demand, full-motion video services on a public
|
||
ATM network is not feasible in the near future.
|
||
|
||
-------------------------------------------------------------------------------
|
||
|
||
--=] National Security Anarchists [=--
|
||
--=] Volume I, Issue II [=--
|
||
--=] Presents [=--
|
||
|
||
== Teleos: New Access Server Enhancements ==
|
||
|
||
|
||
Multi-Point Token Ring LAN Bridging provides a unique and cost-effective
|
||
solution for customers that need to link multiple LAN sites only on an
|
||
"as-needed" basis, with the speed (dynamic bandwidth) but without the
|
||
incovneience and expense of T1 leased lines. A Token Ring Interface United
|
||
(TRIU) provides a 4 Megabit-per-second, IBM Token Ring Network-compliant
|
||
interface which supports connections to the AS/400 and other IBM and non-IBM
|
||
hosts, front-end processors and communication controllers that support Token
|
||
Ring source routing.
|
||
|
||
The multi-point feature dynamically establishes bridged connections between
|
||
up to 32 remote locations. The bridged channel is transparent to higher
|
||
layer protocols on the private Token Ring Network. The IAP6000 Access
|
||
Server supports 56Kbps, 64 Kbps, 384 Kbps (H0) 1,472 Mbps (H10) and even n x
|
||
64 Kbps capability. For instance, a corporate user, for a given
|
||
application, can "bundle" 4 x 64 Kbps B channels yielding 256 Kbps of
|
||
bandwidth between locations. H0 channels can be concatenated in this
|
||
similar fashion. Up to 32 B cahnnel bridge connections may be established
|
||
dynamically, on a call-by-call basis, per single TRIU. A total of eight
|
||
TRIUs can be supported in a IAP6000 twenty-slot system.
|
||
|
||
Fractional T1 support using intergrated access allows the user to permanetly
|
||
assing channels in 64, 384 or 1,472 Kbps increments for heavy usage
|
||
applications. The user now has the option of defining that a certain amount
|
||
of bandwidth over a single, intergrated network connection be "fixed" (or
|
||
dedicated) for a particular application use. With private line services
|
||
over the same Primary Rate Interface access line. For instance, users can
|
||
create hybrid networks and use both switched and private line tariffs to
|
||
optimize their network costs.
|
||
|
||
Transparent autoconnect automatically sets up a switched digital call
|
||
providing, in effect, virtual dedicated badnwidth on demand for users who
|
||
cannot justify the costs of private lines. The IAP6000 Access Server can be
|
||
programmed through the system console to dial a specific remote location and
|
||
leave the connection active. In this mode, the call is monitored and if for
|
||
any reason the connection is dropped, the IAP6000 Access Server
|
||
automatically re-establishes the call.
|
||
|
||
Dynamic event steram reproting enables the IAP6000 Access Server to relay
|
||
network information it recieves from the public switched network to an
|
||
adjunct information processor (PC, mini, mainframe). The event steram link
|
||
is a 9600 Kpbs, asynchronous, RS-232 interface. Information provided over
|
||
the D channel, and reported, includes: Calling Party Number Information;
|
||
Called Party Number Infomration; Time and Date of the Call, and Call
|
||
Type (Voice,Data). Event stream reporting allows the IAP6000 Access Server
|
||
to share ISDN D-channel network intelligence with non-ISDN CPE so customized
|
||
applications such as call screening, call routing (dealer locator),
|
||
automatic call back (for abandoned or busy calls) and secure dial-back
|
||
services for comptuer access can be implemented.
|
||
|
||
-------------------------------------------------------------------------------
|
||
--=] National Security Anarchists [=--
|
||
--=] Volume I, Issue II [=--
|
||
--=] Presents [=--
|
||
|
||
== SunOS /bin/mail Vulnerability ==
|
||
== Sun/Os MicroSystem Security Bulletin =
|
||
== Re/Edited Version ==
|
||
|
||
|
||
============================================================================
|
||
System Versions : 4.03, 4.1, 4.11
|
||
Architectures : Sun3, Sun3x, Sun4, Sun4c, Sun4/490_4.1_PSR_A
|
||
Obsoleted by : System V Release 4
|
||
Synopsis : /bin/mail can be caused to invoke a root shell if given
|
||
the proper arguments.
|
||
============================================================================
|
||
|
||
|
||
Synopsis Description:
|
||
|
||
/bin/mail is the local delivery agent for sendmail. In
|
||
some particular instance, /bin/mail parse its argument incorrectly
|
||
and therefore, mail are being drop into the bit bucket.
|
||
|
||
If there are users that has "f" has the second character, you might want
|
||
to try the following: (substitute "af" with anyuser with "f" as second
|
||
character)
|
||
|
||
From any machine except mailhost:
|
||
|
||
/bin/lib/sendmail -t -v <<END
|
||
From: anyuser
|
||
to: anyuser
|
||
Subject: test
|
||
Cc: af <-- substitute any username with second character as "f"
|
||
test
|
||
|
||
END
|
||
|
||
When the mail arrived on mailhost, sendmail process will invoke
|
||
/bin/mail with the following argument "/bin/mail -r anyuser -d af
|
||
anyuser". Now you are in trouble. The following are different
|
||
scenarios for /bin/mail.
|
||
|
||
[1] /bin/mail -r anyuser -d af <mailmessages fine
|
||
[2] /bin/mail -r anyuser -d anyone af ... <mailmessages fine
|
||
[3] /bin/mail -r anyuser -d af anyone ... <mailmessages Ah a Bug
|
||
|
||
In Case 3, /bin/mail thinks that you want to read mail instead of
|
||
delivering mail. Therefore, mail messages is lost.
|
||
|
||
Now this probably won't work on most Internet Sun/Os Unix systems. But ah
|
||
this works just dandy on direct dail ups and other networks. So go out
|
||
and practice your molestations.
|
||
|
||
------------------------------------------------------------------------------
|
||
|
||
National Security Anarchists
|
||
"Plagurism is the Basis of Creativity"
|
||
|
||
## ## ###### ######
|
||
### ## ## ## ##
|
||
###### ###### ######
|
||
## ### ## ## ##
|
||
## ## ###### ## ##
|
||
|
||
-------------------------------------------------------------------------------
|
||
National Security Anarchists
|
||
"Plagurism is the Basis of Creativity"
|
||
All Rights Reserved
|
||
Any modifications to this text file is a violation of copyright
|
||
- (c) 1991 -
|
||
--------------------------------------------------------------------------------
|
||
Downloaded From P-80 Systems 304-744-2253
|
||
|
||
Downloaded From P-80 International Information Systems 304-744-2253 12yrs+
|