yurisk.info

Yuri Slobodyanyuk's blog on IT Security and Networking sharing experience and expertise

Category: Cisco (page 6 of 6)

Cisco ip accounting to begin with

January 17, 2009 / / 2 Comments

First of all, Happy New year to All !
As I promised before (last year 🙂 I’ll look at ip accounting in Cisco world. I’ll say it at the start already – accounting being with us since IOS 10.0 nowadays is getting pushed aside by the powerful Netflow feature.And while it is nowhere being depreciated/end-of-lifed by Cisco , it is presented as being “not enough”for the modern enterprise. I will agree that Netflow indeed provides lots of additional statistics and info , but will remind that it demands from device and the user substantially more as well.
And therefore for many cases is just plain overkill.

So lets look at accounting closer.
When enabled on the interface it  creates database of accounting information
containing number of bytes that passed the router  between pairs of IP addresses. There are actually more types of accounting  but here I’ll talk about 2 types only: IP accounting and  IP access-list violations accounting. The first gathers statistics  for the traffic passing the router – entering and leaving it (means traffic that destined for or originating from the router itself is not accounted for). The 2nd type gathers info about traffic that is being rejected by the router according to applied ACLs. Both types can be enabled for physical/logical interfaces only (so to say VTY is not in the pack).

Both types share the same database memory space. And talking about memory –
by default router keeps 512 records, after these are exhausted no new accounting info is recorded. As usual , this is configurable (see later).

IP accounting

Here is a sneak preview of accounting at work:

Source           Destination              Packets               Bytes
122.94.42.91     62.20.179.36                       2                 223

What you see is Ip addresses spotted in the IP packet header as source/destination
, number of packets and bytes. The database is updated continuously as traffic
passes the router.

IP accounting condifuration

– enable on the interface of interest (only outbound traffic is recorded),
i.e traffic leaving interface
– if desired tune number of kept records
– see in CLI gathered info
– see info through SNMP agent (won’t cover here)
– clear active accounting database and copy snapshot to checkpoint  database
(done at once)
– see later at any time snapshot in checkpoint database or active records
in real-time

So here is our CLI:
1) Enable on interface
Router(config)#int fa0/1
Router(config-if)#ip accounting [output-packets]

2) [Optional] Tune maximum records value if desired (default 512, maximum 4294967295):
Router(config)#ip accounting-threshold 1200

3) See the active records in the database:

Router#sh ip account
Source           Destination              Packets               Bytes
68.146.13.6       162.30.79.36                       1                 129
79.82.168.224     162.30.79.36                       1                 126
142.53.125.103    162.30.79.36                    9237              423360
83.171.0.22       162.30.79.36                       1                 129
118.181.13.61     162.30.79.36                       4                 360

4) Copy active database to checkpoint database and wipe out active db records:

Router#clear ip account
Router#sh ip accounting checkpoint

Source           Destination              Packets               Bytes
68.146.13.6       162.30.79.36                       1                 129
79.82.168.224     162.30.79.36                       1                 126
142.53.125.103    162.30.79.36                    9237              423360
83.171.0.22       162.30.79.36                       1                 129
118.181.13.61     162.30.79.36                       4                 360

Usage tip: What is this good for at all? As I started in the previuos post
I use such info to provide some insight to the client of what is going on
(or rather going in/out) in his network at the given moment. So, all these
commands I do on the client’s perimeter equipment which we manage. I have
no slightest inclination to do this for client/whoever on my backbone
gear, and you would be advised not too. Just try to enable accounting on the
router passing gigabits of traffic and you’ll have some ‘splaning to do
afterwards ;).  And in general be advised that many of the posts in my blog come
from Service Provider view  and not of the end-client enterprise
(no matter how big it is) standpoint.

5.5) Some extra-bonus configs though – you may configure ACL that will filter
for what IP addresses to gather accounting info only. While trying to catch
who is loading your network would be counter-productive to use such filtering,
for monitoring long-time  it makes sense:

Router(config)#ip accounting-list 19.90.14.59 0.0.0.0

Then to  database will be written only records involving this IP(s):

Router#sh ip account
 Source           Destination              Packets               Bytes
19.90.14.59    162.30.79.37                       7                2912

IP access-list violations accounting.

This accounts for traffic blocked by ACL(s) applied to the interface(s)
– To enable :
Router(config-if)#ip accounting access-violations
Accounting will exclude mls traffic when mls is enabled.

–  To see the records:
Router#sh ip accounting access-violations
Source           Destination              Packets               Bytes   ACL

Accounting data age is 8

* Of course to see something you need to have some blocking ACL applied to the
interface(s) beforehand. As I have no ACL on any interface this db is empty.

USAGE TIP 2: If you use this feature to spot most loading flow, you’ll love this
one-liner that after  you pass to it (through std input) print out of
the show ip accounting will sort data by bytes passed in ascending order:

*Hint  Darkstar is Linux machine, not router itself .
root@DarkStar:~# sort -n -k4,4
<NOW COPY PASTE OUTPUT FROM ROUTER HERE …>
68.146.13.6       162.30.79.36                       1                 129
79.82.168.224     162.30.79.36                       1                 126
142.53.125.103    162.30.79.36                    9237              423360
83.171.0.22       162.30.79.36                       1                 129
118.181.13.61     162.30.79.36                       4                 360

79.82.168.224     162.30.79.36                       1                 126
83.171.0.22       162.30.79.36                       1                 129
68.146.13.6       162.30.79.36                       1                 129
118.181.13.61     162.30.79.36                       4                 360
142.53.125.103    162.30.79.36                    9237              423360

USAGE TIP 3:
To even further improve on the one-liner above below is again one-liner
that not only sorts accounting data by Bytes field but also sums up bytes per
Ip address (here in the 2nd field, but you can esaily modify to your needs):

root@DarkStar:~# sort -n -k4,4 | awk '{ips[$2] += $4} END { for (x in ips) print x,ips[x]}'
122.53.125.103   162.30.79.36                       3                 120
59.44.58.120     162.30.79.36                       3                 417
123.203.142.106  162.30.79.36                       1                 177
82.144.177.32    162.30.79.36                       1                 234
218.103.137.105  162.10.79.36                       1                 126
80.37.83.120     162.10.79.36                       1                 126
79.182.121.216   162.10.79.36                       9                 377
207.191.202.251  162.30.79.36                       9                 377
84.195.248.47    162.20.79.36                       7                 304
201.95.211.8     162.40.79.36                       8                 364
79.180.14.184    162.30.79.36                      24                 994
124.64.176.192   162.70.79.36                       5                 227
62.219.133.44    162.30.79.36                      72                3077
91.196.214.6     162.40.79.36                       4                 160
125.125.227.168  162.40.79.36                      15                 797

0
162.20.79.36 304
162.40.79.36 1321
162.30.79.36 5396
162.10.79.36 629
162.70.79.36 227
root@DarkStar:~#

Here I’ll wrap up my short (if you ask me) memo with few links for those interested to deep digger :

1) The whole book dedicated to knowing your network better :

Network Management: Accounting and Performance Strategies
by Benoit Claise – CCIE No. 2686; Ralf Wolter

http://www.ciscopress.com/bookstore/product.asp?isbn=1587051982

Cisco IOS command reference:

http://www.cisco.com/en/US/docs/ios/12_3/ipaddr/command/reference/ip1_i1g.html#wp1091971

PS Next post I am planning to do on Netflow , the beast of accounting to be tamed.

Finding the station/IP using/abusing most of the bandwidth – PIX/ASA

December 6, 2008 / / 2 Comments

[showmyads]Here is a short how-to I wrote some (well ,long) time ago for the newcomers  to our department. It was written for the PIX , but applies to ASA as well in most cases,see for ASA notes for differences.
Usually it starts with client complaining about slow internet, or users that already work in net are ok but new ones can’t connect, sometimes PIX crashes periodically (depends on case – every few hours), seldom but client directly asks what station in LAN is bombing the PIX with connections.
Here are the steps to try to see what is going on:
 
1) Always worth knowing the current state of the PIX, lots of connections consume lots of memory
and this  after all causes crash/slowness of processing/
 
 Mambo# show memory
Free memory:        42557840 bytes
Used memory:        24551024 bytes
————-     —————-
Total memory:       67108864 bytes
 
2) as you may know PIX is a NAT machine – every connection (outbound/inbound)
should pass NAT translation, which creates (every connection) xlate entry (in IOS it is called
NAT table) (ASA note:you may disabel NAT ,not to say it may work in Transparent mode)
 
Mambo# show xlate count
1613 in use, 5246 most used
; In abused PIX you would see dozens of thousands of xlate entries, e.g. 55550
 
; beyond xlate entry, every connection creates conn entry in PIX memory to enable stateful
;inspection, to see their count use :
 
Mambo# show conn count
5271 in use, 34824 most used
 
; next command will show on which interface there is more traffic – to know what side of the PIX is being attacked
 
Mambo# show traffic
outside:
        received (in 980818.730 secs):
                1113941822 packets      498552059 bytes
                1004 pkts/sec   0 bytes/sec
        transmitted (in 980818.730 secs):
                1170564303 packets      2054434346 bytes
                1000 pkts/sec   2002 bytes/sec
inside:
        received (in 980818.730 secs):
                0 packets       0 bytes
                0 pkts/sec      0 bytes/sec
        transmitted (in 980818.730 secs):
                76 packets      4560 bytes
                0 pkts/sec      0 bytes/sec
dmz:
        received (in 980818.730 secs):
                186616723 packets       3287127501 bytes
                1 pkts/sec      3001 bytes/sec
        transmitted (in 980818.730 secs):
                196403614 packets       1465915834 bytes
 
Now the main part – how to find out which IP is abusing the resources:
 
 
Mambo#  show local-host  |  incl host|count|embryonic
 
local host: <10.10.1.142>, conn(s)/limit = 0/0
            embryonic(s)/limit = 0/0, incomplete(s) = 0
local host: <10.10.1.53>, conn(s)/limit = 106/0
            embryonic(s)/limit = 106/0, incomplete(s) = 0
local host: <10.10.1.205>, conn(s)/limit = 14/0
            embryonic(s)/limit = 0/0, incomplete(s) = 0
local host: <10.10.1.191>, conn(s)/limit = 4/0
            embryonic(s)/limit = 0/0, incomplete(s) = 0
local host: <10.10.1.193>, conn(s)/limit = 4/0
            embryonic(s)/limit = 1/0, incomplete(s) = 0
………………………………………………………………………..
local host: <10.10.1.36>, conn(s)/limit = 22/0
            embryonic(s)/limit = 0/0, incomplete(s) = 0
local host: <10.10.1.180>, conn(s)/limit = 1/0
            embryonic(s)/limit = 0/0, incomplete(s) = 0
 
Legend:
 
local host     :  Local IP of station in LAN
conn(s)/limit  :   number of conn entries (connections) and their possible limit for this IP
embryonic(s)/limit  :  number of embryonic (half-open) connections to this IP and their limit
 
Looking at this output we could easily find station with most connections.
 
Next, to get more info (if needed)
 
 Mambo#  sh local-host 10.10.1.19
Interface Inside: 73 active, 96 maximum active, 0 denied
local host: <10.10.1.19>, conn(s)/limit = 105/0
            embryonic(s)/limit = 45/0, incomplete(s) = 0
  AAA:
  Xlate(s):
    PAT Global 216.163.137.3(40901) Local 10.10.1.19(3653)
    PAT Global 216.163.137.3(30938) Local 10.10.1.19(1439)
    PAT Global 216.163.137.3(61195) Local 10.10.1.19(3815)
    PAT Global 216.163.137.3(39325) Local 10.10.1.19(2387)
    PAT Global 216.163.137.3(12515) Local 10.10.1.19(1043)
    PAT Global 216.163.137.3(21891) Local 10.10.1.19(2368)
    ……………………………………………….
 
    PAT Global 216.163.137.3(64086) Local 10.10.1.19(4928)
;NOTE – here 216.163.137.3 is IP of outside interface of PIX
 
To temporary block some station – it will not be able to create new connections
and exsiting ones will be deleted. This block is active until next reboot.
  Mambo#  shun 10.10.1.19
To see active shuns:
  Mambo#  show shun
To disable shun
  Mambo#  no shun  10.10.1.19
Personal NOTE: Such call is a sure sign of unordered/amateurish network administration . And it always starts with the key phrase – “Your line is down, we have no Internet”. On my answer, after I look at MRTG
graphs of the client line and see 100% usage, that “Of course , you are using up  all your bandwidth” they reply “It is impossible, can you tell me who is abusing the line ?” While I may spend 10 mins
 explaing this ‘sysadmin’ that PIX/ASA/etc is not a statistics/monitoring device and other solutions exist for that and MRTG is free etc., I usually give up on them and save myself 10
 mins of my time and just give them what they want . In the next post I will write about doing the same in Cisco router.

Guarding against brute force attack on VTY in Cisco IOS

October 10, 2008 / /

Cisco starting IOS 12.3 introduced a simple but powerful feature to guard against brute force password guessing attack on remote access. The usual template followed when configuring VTY access is:
1) Configure ACL containing management IPs to be allowed to access the router through VTY
2) (Optional) Restrict VTY access protocol to ssh only (transport input ssh)
3) Apply this ACl to VTY : (config-line)# access-class <ACL>  in
4) (Optional)  SIngle out one VTY line for a special remote access IP to be used if all VTY lines
are currently in use: (config)# line vty 4
Now I enhanced this template with following features:
#Blocks login for 300 seconds after 5 failed logins within  50 seconds time interval

login block-for 300 attempts 5 within 50
#apply specified ACl to VTY line when above event occurs, it is meant to exempt
#your managemnt IP form being blocked. After timed block expires this ACL gets removed
#from VTY and previous ACL that was applied before the event is reapplied back

login quiet-mode access-class anti-DOS

#Logging rate-limitation to prevent cluttering logs with failed attempts
login on-failure log every 10

ip access-list standard anti-DOS
 permit 193.193.193.33
 remark Deny VTY access to anyone else if brute-force logins take up all VTY lines
 
Another nice feature is delay between login attempts:
Sacramento(config)#login delay 2
Delay login is in seconds

Then in logs you will see the following failed attempts:


*May 2 02:04:14.105: %SEC_LOGIN-4-LOGIN_FAILED: Login failed [user: ] [Source: 62.141.52.141] [localport: 22] [Reason: Login Authentication Failed] at 05:04:14 Sat May 2 2009
*May 2 02:04:22.112: %SEC_LOGIN-1-QUIET_MODE_ON: Still timeleft for watching failures is 22 secs, [user: ] [Source: 62.141.52.141] [localport: 22] [Reason: Login Authentication Failed] [ACL: anti-DOS] at 05:04:22 Sat May 2 2009
*May 2 02:09:22.091: %SEC_LOGIN-5-QUIET_MODE_OFF: Quiet Mode is OFF, because block period timed out at 05:09:22 Sat May 2 2009

Newer posts

© 2016 yurisk.info

Theme by Anders Noren — Up ↑