Ken Felix Security Blog

Monday, September 29, 2014

A SIP Request Header gotchas

Debugging some sip stuff this last few weeks, I ran into something that was a little strange & that I would like to share with you.

My Wiresahrk/Tshark tool was not decoding a sip.request correctly , but it was due to the upstream SBC was sending a badly format Request & Method field in the header to begin with. So decoding SIP packets, was reporting some requests as "unknown". In this is case it was a Sip Request OPTIONS.

NOTE: E.g all "Methods" should be uppercase from what I compared to other captured Sip Request

"INVITE" vrs "invite", "BYE" vrs "bye", "CANCEL" vrs "cancel"

And the same for the Request-Line. ( Request-Line: OPTIONS )

Here's a few snapshot of the header and Methods;

( correct )

( incorrect )

The RFC3261 did not give to much details on the character set & with regards to upper & lower case, but this is a summary;

http://tools.ietf.org/html/rfc3261#section-7.1

but RFC2543

https://www.ietf.org/rfc/rfc2543.txt

note: In all internet examples, the Request are always shown in UPPERCASE ( INVITE, ACK, BYE, etc... ) In all of my previous trace and pcaps analyzed, this seemed to held true.

So keep that in mind when inspecting SIP datagrams and/or decoding sip datagrams. If wireshark flags these requests as unknown, than a deep inspection of the header should take place.

The SBC in question Sonus 5100 was still replying with a status 200 OK . So a tight inspection of the header format was not taking place or it didn't care about the case-sensitivity. The sending SBC is supposedly a Acme SBC btw.

I checked a few other SIP devices and they are seems to deploy the Requests in upper case. Even my x-lite client sends all requests in uppercase.

I hope this helps others who are scratching there heads, & wondering why the sip request are reported as unknown.

Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix --- a----t ---- socpuppets --- dot --- com

   ^      ^
=( X   X )=
     o
    / \

Sunday, September 28, 2014

Cisco DOM and transceiver matrix

Cisco DOM supported transceiver listing, the following list give great details on 1/10gig transceivers that support diagnostic optical monitoring.

http://www.cisco.com/c/en/us/td/docs/interfaces_modules/transceiver_modules/compatibility/matrix/OL_8031.html

This is a one big single reason why it's best to stick with cisco branded optical transceivers.

Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix -----a----t---- socpuppets ---dot---com
   ^      ^
=( $ $ )=
       o
    / \

Saturday, September 27, 2014

Three IOS-xr commands that could be useful

Here's 2 IOS-XR command that could come in handy.

1:

How many times have you had a card hangup in a ASR chassis? Will instead of sending somebody to pull or reset the card, just do a reload.

The hw-admin from admin mode will allow you to reload the slot that specified. On CRS you have the option to power off the slot

e.g

note: you can monitor the status using "show platform"

2:

IOS-XR let's you compute md5 hash for files. It's similar to IOS and the /verify

3:

When doing package upgrades and you want to test the outcome before activate a new build, the activate command with test option will display the outcome.

Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix -----a----t---- socpuppets ---dot---com
   ^      ^
=( * * )=
       o
    / \

Fortigate Best Comon Practices

In this post we will look at fortinet own published bcp document.

http://docs.fortinet.com/uploaded/files/1954/Best_Practices_52.pdf

At the time of this post Aug-6-2014 is the most updated. It's a very well written doc that commons normal to advance subjects from;

management
firewall policies
vdom
vpn
advance routing

One of the most common detail missed suggestions for HA & VPN that I would like to highlight;

"Use a non-NPU interface for at least one heartbeat interface to rule out potential NPU"

issues."

"Add blackhole routes for subnets reachable using VPN tunnels. This ensures that if a VPN tunnel goes down, traffic is not mistakingly routed to the Internet unencrypted"

NOTE: always try to use a lower performing port for HA operations.

Firmware updates are most, so stay up to date & so you an take advantage of new features. I always try to obtain a copy of original software that I'm running b4 any firmware updates in case I need to format the flash.

Perform routine backups b4 any major changes, updates or firewall resets.

Try to avoid "any" in firewpolicies for interfaces or services unless that what you intended.

Review the fortinet bcp document and use what's applicable in your design & operations.

Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix -----a----t---- socpuppets ---dot---com
   ^      ^
=( @ @ )=
     o
    / \

Thursday, September 18, 2014

Controlling fragments across a cisco ASA interfaces

Fragments are not good and could be downright bad if your doing packet inspection and recovery.

The reasons for the bad, there's no L4 header information in any succeeding fragments. IPS/FIREWALL and DoS detection gear can freak out and drop these. With UDP and ICMP large payload data is used in a lot for attacks.

note: Some gear will complain and drop flows upon re-assembly if the payload is just flat to big

Ping-of-Death ( aka PoD ) and Smurf took advantage of the typical os stack that allowed large packets and with PoD, windows was greatly effected and could crash.

In this post, we will look at a simple means for eliminating any fragments across interfaces.

1st let's look at the default fragments settings;

Okay the size = 200 chain = 24 and timeout = 5

Okay what this really means, 24 packets of fragment can be allow and we allow for a total of 200 packets to be buffer for reassembly. The timeout value of 5sec simpliy means we allow for 5secs for the fragments to be received, just encase some are slow getting back.

note: You might be able to use scappy to craft large packets and delay transmission for testing the delay
http://www.secdev.org/projects/scapy/

Okay let's look at how you drop all fragments across interfaces. Most will try to do something similar to the following;

But as you can see, the size can not less than the chain limit ( default = 24 )

So here's a means for dis-allowing fragments over all interfaces

config t
fragment chain 1
fragment size 1
end

Now let see a large icmp-ping and what happens when we block fragments ( 6k byte ping )

So when we dis-allow the fragments, the ASA drops these fragments. You can use the show fragment command to get an ideal of fragments statistics.

( example from a 8kbyte packet size 1 ping )

Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix -----a----t---- socpuppets ---dot---com
   ^      ^
=( $ $ )=
       o
    / \

Wednesday, September 17, 2014

Howto: quickly generate 8K bit PGP keys ( GNUgpg )

Crafting large keys on with GNUpgp could become problematic. It Definitely requires more time

Here's a few means for crafting " random bytes" to speed up your PGP key generation. Smaller PGP keys can be create in under 10-30secs on a modern PC, but larger than 4Kb bits could take a considerable amount of time. It's not abnormal to see PGP keys that needs 4-10mins just for creation.

method#1:

A shell loop;

B=0

while [ $B -lt 10 ] ; do ls -lR ; done

NOTE: run the above in a about 3 or more terminal windows on the same host

method#2:

Using unix "dd" command
;

dd if=/dev/random of=/dev/null bs=1k

method#3:

Using unix command find and find junk or random stuff.

A=0

while [ $A -lt 10 ] ; do find / -name " `echo $RANDOM`" ; done

Now sit back, and drink a cup of cafe.

A MacBook Air w/1.3 Ghz I5 took approx 10mins to create a 8192bit pgp key where as a 1024bit key took less than 10secs.

Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix -----a----t---- socpuppets ---dot---com

   ^      ^
=( @ @ )=
     o
    / \

My nextgenfw has new keys published

GNUpgp was used for publishing and creating new keys.

My access to the key-server was down due to a firewall policy

So now you can find next generation firewall public PGP keys for kfelix.

cli using gpg;

Querying a public key-server;

http://pgp.rediris.es:11371/pks/lookup?search=nextgenfw&op=index

Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix -----a----t---- socpuppets ---dot---com
   ^      ^
=( $ $ )=
       o
    / \