Very impressive, a very good free book for Computer Networking! The MPTCP author's book, definitely worth to read!
http://cnp3bis.info.ucl.ac.be/index.html
http://cnp3bis.info.ucl.ac.be/index.html
Tuesday, December 31, 2013
Thursday, December 19, 2013
Sunday, September 22, 2013
Wednesday, April 17, 2013
what is difference between iptables and tcp wrappers
There are several ways to control access to a service on a Linux server:
1) firewall (netfilter), you use iptables command to administer the rules. firewall work at internet layer by allowing or denying access from/to a specific host which in this case using tcp/ip and tcp/udp port number e.g allowing access to port 80 on a web server. With iptables you can restrict access to any ports / protocols or service.
2) tcpwrapper is another method of allowing or denying access to a specific service which work at application layer. Futhermore, tcpwrappers is implemented in the User space of Linux and can be used only with xinetd based services and works at application layer where as IPTABLES is implemented in the Kernel space of Linux and works in internet layer which of course can be extended to other layers by using various modules.
There are two configuration files involve in this setup:
tcp wrappers is dependent on libwrap.so module
hosts.allow
hosts.deny
Not all program/service can utilize tcpwrapper, only a few.
You use this command to check whether a program/service make use of libwrap.so or not.
[root@localhost Desktop]# ldd $(which sshd) | grep libwrap
libwrap.so.0 => /lib64/libwrap.so.0 (0x00007fc19ee83000)
This just the fundamental of tcpwrapper and iptables, you need to look into their manuals for more detail.
1) firewall (netfilter), you use iptables command to administer the rules. firewall work at internet layer by allowing or denying access from/to a specific host which in this case using tcp/ip and tcp/udp port number e.g allowing access to port 80 on a web server. With iptables you can restrict access to any ports / protocols or service.
2) tcpwrapper is another method of allowing or denying access to a specific service which work at application layer. Futhermore, tcpwrappers is implemented in the User space of Linux and can be used only with xinetd based services and works at application layer where as IPTABLES is implemented in the Kernel space of Linux and works in internet layer which of course can be extended to other layers by using various modules.
There are two configuration files involve in this setup:
tcp wrappers is dependent on libwrap.so module
hosts.allow
hosts.deny
Not all program/service can utilize tcpwrapper, only a few.
You use this command to check whether a program/service make use of libwrap.so or not.
[root@localhost Desktop]# ldd $(which sshd) | grep libwrap
libwrap.so.0 => /lib64/libwrap.so.0 (0x00007fc19ee83000)
This just the fundamental of tcpwrapper and iptables, you need to look into their manuals for more detail.
Tuesday, April 16, 2013
net flow vs SNMP interface stats
I won't write a lot words to explain what is the netflow and SNMP, if you want to know what is SNMP and netflow, you could google it, normally, the first link would fit your need.
Today, I encountered a problem that my Cacti weathermap and my NFSEN netflow traffic map showed differently.
In my Cacti, the traffic was around 1.4m, but in my NFSEN, there was around 270konly!
I stuck in there for a while, then I googled with 'netflow' then I figured out what was going on there.
In fact, netflow only records traffic in single direction which goes in or not the specific interface on a netflow exporter, normally the exporter is a router. And what is so called netflow, it will record traffic based on flow, just like a TCP session, it does not read router's interface stats, rather than that it will export all the 'flow' stats to a server, then the server would process those stats then display to you. So you could find a para when you perform config a router, called 'time-out', it Cisco router it looks like:
ip flow-cache timeout active 5
This value will tell the exporter the flow traffic should always export to analyzer every 5 min, even the flow is not well closed. Because of that, the netflow flow chart from NFSEN could not be used as real time traffic analysis. Even for a short period of network analysis, it won't make sense, due to its flow nature, we could only use it analysis some historical data, which is also very useful, because netflow records packets headers, so we could know which protocol, ip, are consuming our bandwidth, and if necessary we could block/limit access for that IP or protocol. This is very useful for network or security admin. But we have to be aware that, netflow would work only with single direction, which you could either anaylsis inbound data or outbound. For a non-load balance environment, it is OK, but in a load balance or MPLS environment, it becomes a little bit complicated. In a non-load balance environment, we could just easily to enable netflow on both sides then we could get every traffic on the patch. But for a MPLS or load-balance environment, yes, you could do the same thing, but you need to aware that, the inbound and outbound traffic are not thru the same path, that's to say, you have to fully analysis all traffic on all paths that used to balance the traffic. That was what I have encountered this afternoon.
From the screenshot, you could figure out, the NFSEN is similar to Cacti output but there are still different.
Based on the lesson I learned, I figured out that, why we still need SNMP analysis engine like Cacti even we already had netflow feature, Cacti is used to show to pure traffic stats, it will help network admin to understand the bandwidth usage; and netflow will help network admin to figure who is the bad guy to poison your network.
Today, I encountered a problem that my Cacti weathermap and my NFSEN netflow traffic map showed differently.
 |
| Cacti output |
 |
| NFSEN output |
In my Cacti, the traffic was around 1.4m, but in my NFSEN, there was around 270konly!
I stuck in there for a while, then I googled with 'netflow' then I figured out what was going on there.
In fact, netflow only records traffic in single direction which goes in or not the specific interface on a netflow exporter, normally the exporter is a router. And what is so called netflow, it will record traffic based on flow, just like a TCP session, it does not read router's interface stats, rather than that it will export all the 'flow' stats to a server, then the server would process those stats then display to you. So you could find a para when you perform config a router, called 'time-out', it Cisco router it looks like:
ip flow-cache timeout active 5
This value will tell the exporter the flow traffic should always export to analyzer every 5 min, even the flow is not well closed. Because of that, the netflow flow chart from NFSEN could not be used as real time traffic analysis. Even for a short period of network analysis, it won't make sense, due to its flow nature, we could only use it analysis some historical data, which is also very useful, because netflow records packets headers, so we could know which protocol, ip, are consuming our bandwidth, and if necessary we could block/limit access for that IP or protocol. This is very useful for network or security admin. But we have to be aware that, netflow would work only with single direction, which you could either anaylsis inbound data or outbound. For a non-load balance environment, it is OK, but in a load balance or MPLS environment, it becomes a little bit complicated. In a non-load balance environment, we could just easily to enable netflow on both sides then we could get every traffic on the patch. But for a MPLS or load-balance environment, yes, you could do the same thing, but you need to aware that, the inbound and outbound traffic are not thru the same path, that's to say, you have to fully analysis all traffic on all paths that used to balance the traffic. That was what I have encountered this afternoon.
From the screenshot, you could figure out, the NFSEN is similar to Cacti output but there are still different.
Based on the lesson I learned, I figured out that, why we still need SNMP analysis engine like Cacti even we already had netflow feature, Cacti is used to show to pure traffic stats, it will help network admin to understand the bandwidth usage; and netflow will help network admin to figure who is the bad guy to poison your network.
Tuesday, March 5, 2013
Nortel VoIP's single voice issue
A very good story for learning how firewall manage
UDP rules and SIP hand-shaking!
An Avaya voice gateway with a traditional
firewall, if we only open UDP/TCP 5060 for SIP and some RTP ports range, does
it work? See the below story :-)
Last year, I encountered a problem that we always
encountered single voice problem with our checkpoint firewall, and the most
interesting part is, if we picked up the phone call within around 60 secs, the communication is OK, but if we hear waiting music more than 60 sec, our counterpart will
not hear us!
Here is the scenario:
client B --- client B's GW --- client A's GW --- client A
We mirror Avaya Voice GW traffic into our sniffer:
Firewall rules:
B --> A UDP port 5060
B <--> A UDP port [RTP port range]
So normally it should work, because for a normal
SIP connection, B will initial a 3-way hands shake with A, then the connection
setup, and both A and B will use the established channel to communicate with
each other.
But in our case, after channel established, A send
an INVITE request to B as well, which like an answer to B's request! This is how Avaya server work!? Avaya server tried to setup another tunnel to back B to transfer voice traffic, if B not answer this request the single voice happened! This is very
abnormal for a SIP voice call, from B's Voice GW, we could see RTP ports
changed, which is very weird!
In the beginning
Sent:
609087 2012-04-20 11:15:41.587380 114.66.80.253
114.66.80.181 UDP Source port: 11790 Destination port: 5442
Received:
609104 2012-04-20 11:15:41.662456 114.66.80.181
114.66.80.253 UDP Source port: 5442 Destination port: 11790
Then
Sent:
609525 2012-04-20 11:15:45.107355 114.66.80.253
114.66.80.181 UDP Source port: 11790 Destination port: 5478
Received:
609537 2012-04-20 11:15:45.224009 114.66.80.181
114.66.80.253 UDP Source port: 5478 Destination port: 11790
After weeks of checking with Avaya, I found that
Avaya implement a very complicated algorithm in its Voice GW. In Avaya GW, IVR
and normal voice traffic are transferred in different channels and more weird part is, if IVR plays, IVR will take the existed channel to transfer its recorded music and it will setup another voice channel by "INVITE" back to the caller!!! If B does not process another "INVITE" the RTP session won't start! If
you heard IVR, it means that Avaya GW already established another channel with
the counterpart. That’s why in B's RFC compliant Voice GW, it saw some
ports change, that’s why we lost connection after several secs, because our
server would like to setup a new tunnel to transfer voice traffic!!!
But why we it works fine within 60 secs!?
Because firewall treat UDP rules by a very obsolete manner.
We all
know that, for a TCP we could keep a session, because it will have a lot of
para to monitor, (syn, ack number, port number, even the flags); but for UDP,
we only have "SIP, SPORT; DIP, DPORT" so how can we keep those rules?
In checkpoint, it just maintain a timer, if no matches for a
while, it will time-out the rule. So hacker could exploit
this vulnerability to compromise the network. But in our case, it
helped Avaya within 60 sec. Within 60 sec after B called A, Avaya
could "exploit" this vulnerability to "INVITE" back to B's GW to accomplish the "INVITE" back, but
after 60 sec, the timer timeout, it won't work any more. So we have to explicitly open a "back-door" for Avaya server to help him to "INVITE"
back to the caller.
Solution: add another rule for B <-- A udp 5060, that's all!
Appendix:
SIP: http://www.ietf.org/rfc/rfc3261.txt
Stateful firewall: http://en.wikipedia.org/wiki/Stateful_firewallMonday, February 4, 2013
Using John to Crack Cisco md5
Prerequisites:
john the ripper, a cisco md5 (enable secret) password hash
Step 1:
Download/Install john
Download/Install john
Step 2:
Have yourself a good long dictionary list because brute forcing can take while so dictionary attack is best to start with.
Have yourself a good long dictionary list because brute forcing can take while so dictionary attack is best to start with.
Step 3:
The hash inside the cisco config looks similar to this:
enable secret level 2 5 $1$WhZT$YYEI3f0wwWJGAXtAayK/Q.
enable secret 5 $1$4C5N$JCdhRhHmlH4kdmLz.vsyq0
The hash inside the cisco config looks similar to this:
enable secret level 2 5 $1$WhZT$YYEI3f0wwWJGAXtAayK/Q.
enable secret 5 $1$4C5N$JCdhRhHmlH4kdmLz.vsyq0
Make it look like this in a text file:
enable_secret_level_2:$1$WhZT$YYEI3f0wwWJGAXtAayK/Q.
enable_secret:$1$4C5N$JCdhRhHmlH4kdmLz.vsyq0
enable_secret_level_2:$1$WhZT$YYEI3f0wwWJGAXtAayK/Q.
enable_secret:$1$4C5N$JCdhRhHmlH4kdmLz.vsyq0
If you need you can try this in order to get it looking like it needs to be:
sed -n 's/[ :]/_/g; s/^\(.\{1,\}\)_5_\($1$[$./0-9A-Za-z]\{27,31\}\)_*$/\1:\2/p' < cisco-device-config > passwd
sed -n 's/[ :]/_/g; s/^\(.\{1,\}\)_5_\($1$[$./0-9A-Za-z]\{27,31\}\)_*$/\1:\2/p' < cisco-device-config > passwd
Step 4:
Launch john on the text file and be sure to include your dictionary list!
Launch john on the text file and be sure to include your dictionary list!
I know this file is titled using John, but I had to add in here that there is another application which is steadily growing in popularity and is now known as the worlds fastest md5 cracker!
It's called BarsWF
You can read more about it in the tools section here http://www.soldierx.com/tools/BarsWF and I would definetly recommend using this application over any other for md5 hash cracking/bruteforcing.
It's called BarsWF
You can read more about it in the tools section here http://www.soldierx.com/tools/BarsWF and I would definetly recommend using this application over any other for md5 hash cracking/bruteforcing.
SOMETHING TO NOTE:
At this current point in time BarsWF does not have the ability to crack these type of hashes because they are salted md5. We are hoping that BarsWF includes this funtionality soon as it was posted on their website that including support for other hashes is a goal.
Therefore in order to crack cisco hashes you will still need to utilize John the Ripper.
Why did I bother to even mention BarsWF? Two reasons:
1) I was unaware of the limitations of BarsWF at the time of writing and was amazed at the cracking speed of the normal md5 hash.
2) I wanted to assist in promoting the utility given my amazement. Obviously how much popularity the application gets will impact on whether the author makes an updated version capable of cisco hashes or just other hashes in general. As fast as BarsWF is at cracking md5, we would all love to see this speed utilized for other hashes as well.
At this current point in time BarsWF does not have the ability to crack these type of hashes because they are salted md5. We are hoping that BarsWF includes this funtionality soon as it was posted on their website that including support for other hashes is a goal.
Therefore in order to crack cisco hashes you will still need to utilize John the Ripper.
Why did I bother to even mention BarsWF? Two reasons:
1) I was unaware of the limitations of BarsWF at the time of writing and was amazed at the cracking speed of the normal md5 hash.
2) I wanted to assist in promoting the utility given my amazement. Obviously how much popularity the application gets will impact on whether the author makes an updated version capable of cisco hashes or just other hashes in general. As fast as BarsWF is at cracking md5, we would all love to see this speed utilized for other hashes as well.
-cisc0ninja
Monday, January 7, 2013
Can we fully trust an IDS or IPS?
"Not everything that is
counted counts, and not everything that counts can be counted."
---
Albert Einstein
Nowadays, more and more network administrator introduce IDS or likewise system to their network to protect their network from being attacked, but the truth is, the IDS is not that reliable as we expected.
Most IDS systems are pattern based, requiring a large set (typically ~1500+) signatures to alert based on a specific combination of TCP flags in the header, or a set pattern in the payload. The accuracy of this approach depends, of course, on the skill of the administrator writing the signature, but in most cases this provides for very accurate detection of a specific attack, and will not catch new or modified attacks.
Because most NIDS systems operate in layer 2 (OSI), they simply feed raw traffic into a detection engine and rely on the pattern matching and/or statistical analysis to determine what is malicious. Packets are not processed by the host’s TCP/IP stack and upper layer applications – so the IDS analyzed traffic, the host would otherwise discard. This approach also has the disadvantage that packets can be intentionally crafted in such a way as to confuse pattern-matching IDS systems, while still being correctly assembled by the host TCP/IP stack to render the attack payload.
So IDS would possibly have a different views with the real end system which could be exploited by hack to fool the IDS system. There are two most prevalent techniques, Insertion and Evasion. Just like what those words literal meaning, the IDS could either see more words or less words than a real end system. They very well discussed, you could find more information here[1].
And we could find a real world example here[2]. You could easily figure out that, even for the most sophisticated IDS, it could do not detect all attacks. Because it could only read in a packet level, it could not replay the whole "stream", so it make any type of implementations inevitable to this flaw.
The discussions here are not aimed to shame any IDS implementations, the systems are still very good and they are also evolving too. We just want to emphasis that, IDS is not as its literally meaning, Intrusion Detection, it could do only part of it. In China, we have a saying like that, no one could do everything himself/herself, so we should think about other solutions for "stream" based and application based attack, fortunately, now, we have some solutions for that, OSSEC, a host based or a logs based analysis engine could help security admin to detect some attacks based on system or application logs. So all the application based attack could be well processed by OSSEC. But it is not the ending for our story, both OSSEC and other logs based analysis engine are pattern based too, which means that it could only reported problem which match a certain pattern, and if the pattern is not very well customized, it will generate a lot of false active reports.
So, manpower is still needed for now, we should always keep our eye on our systems, to keep the hackers away!
Friday, January 4, 2013
disadvantage of "-sI" option for nmap
Recently, I have been so obsessed by nmap, there is a very interesting option, "-sL", which will take advantage of a zombie machine to accomplish a stealth scanning. But the truth is not like what it's said.
From the official guide, we were told that it won't be problematic to find a zombie machine, but what is the truth? I am done several tests myself, but I found that, it is really hard to do that.
1. It is really hard to find a totally isolated host which there are merely IP level packets are received. Nowadays, all servers are equipped with loadbalancer, proxy, reverse-proxy, etc. Those applications will generate some TCP/ICMP/IGMP level packets to determine an host is alive. So even there is no effective requests at all from the clients, we could not grantee that there are no other IP packets bothered us.
2. The zombie host must open its 80 or 443 ports. continue with the prior problem, a lot of web applications are use some arbitrary ports instead of well known ports 80 and 443, they choose customized ports like 1443 or 8080, but nmap could not use those ports to perform ID incremental scanning.
3. No one really use or log-on to that host from SSH or made some development. As we all know, the most vulnerable hosts are dev hosts, those hosts are always welcome for everyone, in this case, they do not fit. there will be a lot of traffic for SVN, SSH and some other testing requests from developers.
Conclude with those 3 points, it's made zombie host based scanning an unpractical for a real world scanning.
I have set-up a lab myself, which should be very quite environment than a real world, but the results were always different. here is my lab environment:
zombie: 192.168.1.100, a http server
target: 192.168.1.101, ports 22, ports 80, ports 8080 are opened
I scanned for three times, but I got three different results:
First:
PORT STATE SERVICE
22/tcp closed|filtered ssh
80/tcp closed|filtered http
8080/tcp open http-proxy
Second:
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
8080/tcp open http-proxy
Third:
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
8080/tcp closed|filtered http-proxy
But do not be scared, you still be able to find a zombie host, but keep in mind, the zombie host must very do not proceed any IP or higher level request, otherwise the ID incremental will make no sense any more.
"The quieter you become, the more you are able to hear"
From the official guide, we were told that it won't be problematic to find a zombie machine, but what is the truth? I am done several tests myself, but I found that, it is really hard to do that.
1. It is really hard to find a totally isolated host which there are merely IP level packets are received. Nowadays, all servers are equipped with loadbalancer, proxy, reverse-proxy, etc. Those applications will generate some TCP/ICMP/IGMP level packets to determine an host is alive. So even there is no effective requests at all from the clients, we could not grantee that there are no other IP packets bothered us.
2. The zombie host must open its 80 or 443 ports. continue with the prior problem, a lot of web applications are use some arbitrary ports instead of well known ports 80 and 443, they choose customized ports like 1443 or 8080, but nmap could not use those ports to perform ID incremental scanning.
3. No one really use or log-on to that host from SSH or made some development. As we all know, the most vulnerable hosts are dev hosts, those hosts are always welcome for everyone, in this case, they do not fit. there will be a lot of traffic for SVN, SSH and some other testing requests from developers.
Conclude with those 3 points, it's made zombie host based scanning an unpractical for a real world scanning.
I have set-up a lab myself, which should be very quite environment than a real world, but the results were always different. here is my lab environment:
zombie: 192.168.1.100, a http server
target: 192.168.1.101, ports 22, ports 80, ports 8080 are opened
I scanned for three times, but I got three different results:
First:
PORT STATE SERVICE
22/tcp closed|filtered ssh
80/tcp closed|filtered http
8080/tcp open http-proxy
Second:
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
8080/tcp open http-proxy
Third:
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
8080/tcp closed|filtered http-proxy
But do not be scared, you still be able to find a zombie host, but keep in mind, the zombie host must very do not proceed any IP or higher level request, otherwise the ID incremental will make no sense any more.
"The quieter you become, the more you are able to hear"
Subscribe to:
Posts (Atom)