Archive for the ‘Network Security’ category

Newer Entries »

Top 5 Firewall Threats – Part 1

August 1st, 2009

I spend a bit of time in the field consulting. Over the last few years I’ve noticed a trend with new clients whereby I can usually (about 7 out of 10 times) identify “something” leaking out through the client’s perimeter that they were unaware of. I thought I would compile a list of the top 5 so folks could sanity check their own security.

Firewall Threat #5: Commercial VPN services

It amazes me how often employees will do an end run around perimeter security and setup their own VPN solution. I even see this on networks that already have an existing VPN solution in place. Could be the end user thinks the corporate solution is too restrictive. Could be they simply want to be able to extract info without going through the corporate content checking solution. Unfortunately there are a number of third party companies that are more than happy to sell VPN services that will circumvent the average firewall policy.

How does it work?

There are a number of VPN service vendors, but the most popular is GoToMyPC (now owned by Citrix), so I will talk about that service specifically. Implementation for the end user is pretty straightforward:

  • Create an account and pay the $20/month fee
  • Load agent software on their system at work
  • Go home and launch their Web browser

The user can then logon to their work system and control their desktop remotely. They can even transfer file information by dragging files in or out of the session window.

Why are third party VPN services a problem?

Third party VPN services allow your end users to create an encrypted tunnel between their work system and systems on the Internet. If you have implemented some form of Data Leak Prevention (DLP) or content checking on the perimeter to control the flow of company private information, they will be defeated by a third party VPN. This means your end users could be transferring anything out of your network. Not only do you have no control of what info passes through the VPN tunnel, these services try very hard to look like normal traffic so you may not even know this is happening on your network.

Under the hood

Figure #1 shows how a third party VPN solution can work. Note that session establishment originates from the work system, not from a system on the Internet. So as far as the firewall is concerned this is an outbound session. Further, many of these services use TCP/443 to communicate and SSL to secure the session. So from the firewall this looks like normal HTTPS traffic. Most admins do not log outbound HTTPS, so there may not be any log entries to review.

gotomypc

How to prevent it

There are a number of possible solutions to curb this activity:

1) Review outbound firewall logs

Specifically, you want to look at outbound traffic taking place after hours. Filter out patching sites (Microsoft, Adobe, etc.), A/V signature updates, or any other expected pattern. Everything else should be scrutinized. Pay close attention to repeated connection attempts to the same host or subnet at a predictable interval (say every 20-60 seconds).

2) Desktop enforcement

Leverage application control or a similar technology to control which applications your users can install on their desktop. While this option may seem to be the most cumbersome, its also the only one that will work most consistently.

3) Block the IP addresses of known VPN services

While this option will work, it requires research to find out which IPs you should ban. Also, the list is going to change as new vendors come on the scene or IPs get moved around. For these reasons its my least favorite option.

Firewall Threat #4: Secure Shell (SSH)

It pains me to put SSH on this list, as over the years I’ve found it to be one of my most useful tools. Unfortunately SSH can be your worst nightmare when its in the hands of your end users.

How does it work?

Most people know you can use SSH as a secure replacement for Telnet. What is not as well known is that SSH can be used to tunnel TCP traffic. This can be implemented as either a forward tunnel, or a reverse tunnel.

SSH forward tunnels

When a user creates an SSH forward tunnel, the SSH client will open up which ever TCP port is specified by the user. Further, the user can instruct the remote SSH server where to send any traffic sent to this local port.

An example is shown in Figure #2. Let’s say that all outbound Web traffic is sent through a content checking system. The firewall checks outbound HTTP to ensure that only appropriate sites are accessed and that certain keywords are not permitted through. Let’s further assume that we have an internal user who wishes to access inappropriate sites.

ssh-forward

Here’s what the end user would do. On their home system they would run a proxy server as well as an SSH server. From their office system they would run an SSH client in order to connect to their SSH server and request a forward tunnel. They would tell the SSH client to open a local port (say 8080) and tell the SSH server to forward all of this traffic to the local proxy server. Now all they need to do is tell their Web browser to use the proxy server located at Localhost, port 8080.

Voila! When they launch their Web browser it will connect to TCP/8080 on the local system. This traffic is then sent down the encrypted tunnel to the SSH server, and then on to the proxy. The proxy server will then connect to what ever site on the Internet the user specified. The firewall can not content check the passing data or control which sites get accessed, because the datastream is encrypted. Our perimeter security has been circumvented.

By the way, the user does not have to limit access to only their personal system. Its possible to tell the SSH client to service connections for other hosts on the wire as well. I remember an on-site I once performed where my porn signatures were triggering on the internal network but not at the perimeter. Turned out one of the engineers had done the above and opened up access to their buddies. So when another engineer connected to his system, the porn content was visible. When it left his system and went to the Internet, it was now encrypted and protected from detection.

SSH reverse tunnels

SSH reverse tunnels are similar to SSH forward tunnels, but are designed to handle data requests headed in the other direction. This is shown in Figure #3. Let’s say we have an internal server which is only accessible to internal employees. In other words, the firewall does not permit inbound connection requests from the Internet to be forwarded to the server. In fact there may not even be any one-to-one NAT or port forwarding in place for folks on the Internet to even try and access the server. Let’s further assume that we have an end user who wishes to expose this server to the Internet.

ssh-reverse

This time the user only needs the SSH server on their home system. From their office system, they launch an SSH session out to their server and request a reverse tunnel. With a reverse tunnel the user tells the SSH server to listen on some local TCP port (say TCP/80) and send any inbound connection requests to the SSH client. The user then tells the SSH client to forward these connection attempts to a specific port at a specific IP address (say TCP/80 on an internal HR Web sever).

Once this connection is complete, anyone connecting to TCP/80 on the users home system will be forwarded to TCP/80 on the internal HR Web sever. The firewall can not control the session because it looks like outbound traffic and all the data is encrypted. In fact you can’t even detect this activity on the HR Web server as all connection requests will be logged as originating from the user’s internal desktop system (the one running the SSH client).

How to prevent it

Take control of all outbound SSH activity. Block TCP/22 outbound and only permit it through when its verified the traffic meets corporate policy. SSH can be configured to listen on any TCP port, so we have to be able to spot non-standard port use as well. Leverage a NIDS or NIPS signature that checks the first three incoming TCP reply packets for an SSH server banner. This should be done on all TCP ports except 22. The banner will contain the string “SSH-1” or “SSH-2”. While its possible to hack the client and server software to change the banners, most end users do not have necessary skills to modify the software and still have it remain functional.

That’s enough for this post. In the next I’ll include the last three threats.

C

2 comments »

Posted in 2-alert, Network Security

Tags:

Why Firewall Reject Rules Are Better Than Firewall Drop Rules

July 23rd, 2009

Most firewalls come pre-configured to quietly drop traffic rather than reject it. But what’s the difference between the two and is it truly better to drop instead of reject? If you have never given this question much thought, the answer might surprise you.

Firewall traffic control options

Firewalls typically give you three options when interacting with traffic, these are:

  • Accept – Let the traffic pass through
  • Drop – Remove the packet from the wire and generate no error packet
  • Reject – Remove the packet from the wire and return an ICMP “Communication administratively prohibited” (ICMP type 3, code 13) error packet

Some firewalls are customizable when it comes to the reject packet that gets returned. For example Netfilter provides options from making the port look like its closed to tar pitting the connection. For the purpose of this post I’ll stick with just the administratively prohibited message since that’s the most widely deployed.

What happens when you port scan a system

An attacker can identify open versus closed ports on a system because each responds differently to a stimulus packet. When I send a TCP SYN packet to a system, one of the following is going to occur:

  • If the port is open a TCP SYN/ACK will be returned
  • If the port is closed a TCP RST/ACK will be returned

So if a SYN/ACK is returned, I know the port is open. If a RST (reset)/ACK is returned, I know the port is closed.

Now expand this out to the Internet level and some other possibilities come into play:

  • If the host is off-line an ICMP host unreachable will be returned by the upstream router
  • If the network the host is connected to is off-line, an ICMP network unreachable will be returned by the upstream router
  • If a router or a firewall with a reject rule is blocking the connection, an administratively prohibited error is returned
  • If the port is protected by a firewall with a drop rule, nothing is returned

Note that its the final two possibilities that involve traffic control. If we drop traffic, nothing is returned to the scanner. If we reject, then an ICMP error is returned.

The myth of stealthing the firewall

Vendors favor drop rules for two reasons, both of which are incorrect. The first is that dropping traffic helps to “stealth” the firewall. The concept is that since the firewall is returning no data, an attacker will be unable to determine you have a firewall. Look at the above response options again. The only time nothing is returned consistently is when a firewall with a drop rule is in the way. So by dropping traffic you are not stealthing the firewall, you are advertising it. This is why tools like nmap will actually report the probe as “filtered” when nothing comes back.

When I’ve confronted vendors with this fact, the response is either “Huh?” or “They still don’t know your firewall’s IP address so its still stealthed”. The second statement is only partially true in that an attacker would have to perform the additional step of running a tool such as tcptraceroute to determine the IP address of the firewall.

So the concept of being able to stealth a device that interacts with traffic flow is a complete myth. The closest match is probably Netfilter’s ability to reject via host unreachable messages. While this does not hide the IP address of the firewall, it does make the firewall look more like a router and help to mask the network segmentation behind it.

The myth of using less bandwidth

The second reason vendors favor drop rules is they think it generates less traffic on the wire. This makes sense logically unless you understand how TCP/IP communicates. In other words, on the surface this statement seems rational. Keep the ICMP errors off the wire and you are using less bandwidth. The reality however is that TCP tries very hard to be reliable. This means that when the first probe packet is quietly dropped, the source is going to send two, possibly four more packets to try again. If you add up the bits on the wire, you actually end up using more bandwidth when you force the source into retransmission mode.

What do the RFC’s say?

So which method is RFC legal, dropping or rejecting? If we reference RFC 1122 it says:

3.3.8  Error Reporting

         Wherever practical, hosts MUST return ICMP error datagrams on
         detection of an error, except in those cases where returning an
         ICMP error message is specifically prohibited.

“Specifically prohibited” refers to the fact that you should never respond to an error packet with another error packet. Its just too easy to create infinite loops. So if we are prohibiting traffic flow we are suppose to be returning an ICMP error message.

Making your IP range less attractive to spoofing

One of the biggest problems with using drop rules is that you make your IP range more attractive for spoofing. Consider the typical SYN flood attack where an attacker attempts to fill up a server’s TCP connection queue so that legitimate connection requests can not be serviced. The attacker will flood the target with TCP connection requests, typically from multiple zombie hosts. Since the attacker has no intention of completing the TCP three packet handshake, the source IP address is spoofed to help protect the true identity of the zombie.

If an attacker spoofs one of your IP addresses as part of their SYN flood, you will see the server under attack send unsolicited SYN/ACK packets to the spoofed IP address. This is not the server attacking your network, its simply the server responding to a connection request and it has no idea the source IP address was spoofed.

OK, let’s return to the above listed scanning options and combine that with your network setup to see what impact you will have on the attacker’s ability to perform a successful SYN flood attack. If your IP address they are spoofing is:

  • Exposed host = RST/ACK returned, connection queue cleared on server in approximately 50 ms.
  • Host off-line = Upstream router returns host unreachable in approximately 3 seconds
  • Network off-line = Upstream router returns network unreachable in approximately 50 ms
  • Reject rule = Firewall/router returns Administratively prohibited message in approximately 50 ms
  • Drop rule = Server under attack attempts to respond for 30 seconds or more

The anatomy of a SYN flood

There are two metrics that come into play in making a SYN flood successful. The first is how many SYN packets can the attacker spoof per second. This metric will be determined by the size of the attacker’s zombie army. The second metric however, is something you have control of. That is “How long will each spoofed connection request tie up memory in the server’s connection queue?”.

As you can see in the above responses, when an attacker spoofs an IP address protected by a firewall drop rule, the bogus connection request ties up the server’s connection queue for the greatest amount of time. So let’s say the attacker wants to tie up one connection slot worth of memory for 60 seconds. That would take two spoofed packets protected by a firewall drop rule, or 1,200 spoofed packets if each spoofed IP is protected by a firewall reject rule. So spoofing dropped source IPs means the attacker requires fewer SYN packets per second in order to perform a successful attack. By deploying a drop rule you are inadvertently helping the attacker and making your address space more attractive to IP address spoofing.

Exec Summary

Using drop rules to prevent traffic flow is widely deployed. This author feels this has more to do with “everyone following the herd” than with a drop implementation truly being a better security posture than using reject rules. Reject rules are more RFC compliant, generate less traffic on the wire, and make your address space less attractive for IP address spoofing.

Cheers!

C

3 comments »

Posted in 4-notice, Network Security

Tags:

Stateful inspection firewalls Vs. NIPS

July 20th, 2009

Yesterday I wrote about “What makes a system vulnerable?” and had someone call me on this comment here:

Both NIPS and UTM firewalls are based on the same underlying technology (stateful inspection) so the same problems arise here as well.

The individual was confused as they thought these were two distinctively different technologies.

I’m sure at some point in your life you’ve heard the phrases “Don’t judge a book by its cover” or “A rose by any other name would still be a rose”. Both are directly applicable here. Let’s look under the hood to see what we mean.

A stateful inspection firewall is a pattern matching device which has the ability to match on pre-defined patterns in both the header and payload of passing packets (sort of like what Anti-Virus does when checking files). Typically these are IP packets, although its possible to do it with IPX, NETBEUI, etc. as well.

What distinguishes stateful inspection from stateful packet filtering is the ability to analyze the payload. Stateful packet filtering can only analyze header information. You may have head the term “deep packet inspection”. This is vaporware created by one or more marketing people who have probably watched too many porn videos. ;) Once you are inspecting the payload there is nowhere deeper to go in the packet, except maybe the Ethernet CRC check which would provide zero security value from Internet based attacks.

A Network Based Intrusion Detection System (NIPS) also leverages stateful inspection to pattern match on passing packets. Typically it uses a number of signatures, or pre-defined patterns the device has been programmed to for, in order to flag and screen out known malicious patterns. Both the header and payload of IP packets can be screened for these known patterns. So NIPS pattern matches on the header and payload, just like a stateful inspection firewall.

Consider the following products:

While Check Point is considered to be the classic firewall and TippingPoint represents the cool new NIPS technology, both offer similar features for screening out known malicious patterns on the wire. In fact both offer subscription services for keeping these signatures up to date. Check Point calls it “SmartDefense” while TippingPoint calls it “Digital Vaccine”. So both product lines are levering stateful inspection to check headers and payload (although the TippingPoint product does not seem to maintain state as often as Check Point, but that’s a topic for another post ).

So if its the same underlying technology, why don’t we simply call NIPSs stateful inspection firewalls? This was one of the best marketing slicks I’ve ever seen in the security industry. Think of it this way, pretend you are the security manager for your company (or maybe you already are, in which case you don’t have to pretend that hard ;) ), I’m a sales person who walks into your office and says:

“Hi, I have this great new stateful inspection firewall I want to sell you”

What is your reply going to be? Probably something like:

“No thank you. I already have one I’m happy with”.

Now, I walk in and say:

“I have this spiffy new network based intrusion prevention system I want to sell you”

Now the response is more along the lines of:

“Wow! I don’t have that yet. Can I buy two?”

You get the idea. By changing the name we make it sound like its a new bleeding edge “must have” technology, which makes it easier for the sales people to generate a commission. When it comes to what happens on the wire however, its just a repackaged familiar tool.

Hope this clarifies the topic!

C

No comments »

Posted in 2-alert, Network Security

Tags:

Test your network security skills

July 15th, 2009

As mentioned on the About page, I spend a bit of time teaching computer security via SANS as well as directly to clients. When people ask me if they would get anything out of taking my SANS course, I point them to this quick test. If you can score 12/15, you are in good shape. Less than that, and you need to cut the knowledge curve.  I’ll put the answers in a different post so its less tempting to cheat. ;)

Note: I’ve messed with the submission dates so the answers do not appear before the questions on the main page.

1) How many different techniques are available to sniff in a switched environment:

  • A) None. Switches block unicast traffic to all ports.
  • B) 2
  • C) 4
  • D) 6

2) You receive the ICMP packet shown below from a remote host. Which of the following is the most likely source of the packet?

  • A) Ping run on a Windows system.
  • B) Ping run on a Linux system.
  • C) hping using the “-C 8” option.
  • D) nmap using the “-sP” option.

15:52:50.129178 IP (tos 0×0, ttl  47, id 51389, offset 0, flags [none], proto: ICMP (1), length: 28) 1.2.3.4 > 172.30.2.10: ICMP echo request, id 18492, seq 21446

3) Which is the best way to discourage attackers from using your address space as part of a SYN flood attack?

  • A) Quietly drop all inbound SYN/ACK packets that are unsolicited.
  • B) Return an ICMP Admin Prohibited error packet for all inbound SYN/ACK traffic that is unsolicited.
  • C) Advertise all portions (even unused) of your IP address space via BGP.
  • D) Report all suspicious inbound traffic to the listed administrative contact of the source IP.

4) Which firewall product is susceptible to loose source route attacks?

  • A) Check Point
  • B) Cisco
  • C) Netscreen
  • D) None of the above

5) Which Libpcap filter would permit you to see potentially malicious IP fragments which could not have been generated by a normal topology MTU?

  • A) ip = frag and evil bit = enable
  • B) ip[12:2] = ip[16:2]
  • C) ip[2:2]<0x1F4 and ip[6]&32!=0
  • D) ip[8]<0x2A or ip[0]&0x0F>5

6) Which of the following techniques would permit an attacker to port scan your network without giving any indication of their true source IP address?

  • A) nmap “stealth” (-sS) scan.
  • B) nmap “idle” (-sI) scan.
  • C) nmap “decoy” (-D) scan.
  • D) Port scans require responses to stimulus so the true source IP cannot be completely hidden.

7) Which of the following best describes what happens when you surf to a Web site, see “HTTPS” in the URL, and the little lock icon on your Web browser is activated?

  • A) All data to and from the Web server is at least authenticated.
  • B) All data to and from the Web server is at least encrypted.
  • C) All data to and from the Web server is encrypted and the digital certificate is fully verified.
  • D) All data to and from the Web server is authenticated and encrypted.
  • E) All data to and from the Web server is authenticated, encrypted and the digital certificate is fully verified.

8 ) You see the following packet leaving your Web server and headed to an IP address on the Internet. What is the most likely cause?

  • A) Problem with the firewall state table time-out being set too low.
  • B) Automatic update checking for new patches.
  • C) Attacker retrieving a toolkit.
  • D) A secure HTTPS session.

17:08:08.412172 IP (tos 0×0, ttl  128, id 18210, offset 0, flags [DF], proto: UDP (17), length: 33) 172.30.2.185.32851 > 1.2.3.4.69:

9) You see the following packet entering your network. Which answer gives the most accurate and likely possibility of what is going on?

  • A) TCP transmission from a Windows system.
  • B) SMTP transmission from a Windows system.
  • C) Spam or Phishing attempt from a Windows system.
  • D) SMTP transmission from a Linux or UNIX system.

19:22:17.631407 IP (tos 0×0, ttl 112, id 30435, offset 0, flags [DF], proto: TCP (6), length: 48) 1.2.3.4.4110 > 192.168.1.10.25: S, cksum 0xc25c (correct), 103504428:103504428(0) win 8192 <mss 1460,nop,nop,sackOK>

10) Given the following netstat output, which of the answers best describes the situation:

  • A) The system has potentially been compromised.
  • B) The system needs a restart to install updated software.
  • C) The system is configured as a typical Windows desktop.
  • D) The system is configured as a typical Windows server.

Proto  Local Address          Foreign Address        State           PID
TCP    0.0.0.0:80                 0.0.0.0:0              LISTENING       2648
TCP    0.0.0.0:80                 0.0.0.0:0              LISTENING       2292
TCP    0.0.0.0:135               0.0.0.0:0              LISTENING       1204
TCP    0.0.0.0:445               0.0.0.0:0              LISTENING       4

11) Which of the following systems can potentially be taken over by a remote attacker?

  • A) A Web server exposed to Internet access.
  • B) A desktop with Internet access.
  • C) A firewall or Network Based Intrusion Prevention (NIPS) system.
  • D) All of the above.
  • E) None of the above.

12) A Network Based Intrusion Prevention System (NIPS) is simply a relabeled:

  • A) Proxy based firewall.
  • B) Stateful inspection based firewall.
  • C) Neither, it is its own unique technology.
  • D) A combination of both.

13) You see the following pattern in your firewall log, which answer best describes what may be going on?

  • A) Someone is fingerprinting which firewall product we are using.
  • B) A remote site is having connectivity issues connecting to our Web server.
  • C) The state table time-out value on our firewall is set too low.
  • D) This is normal and expected traffic to our servers.

Jun  8 05:40:36 SRC= 1.2.3.4 DST=our_web_server LEN=40 TTL=2 ID=7831 PROTO=TCP SPT=2023 DPT=80 WINDOW=1400 SYN
Jun  8 05:40:38 SRC= 1.2.3.4 DST=our_web_server LEN=40 TTL=44 ID=7832 PROTO=TCP SPT=80 DPT=80 WINDOW=1400 SYN
Jun  8 05:40:40 SRC= 1.2.3.4 DST=our_web_server LEN=40 TTL=44 ID=7833 PROTO=TCP SPT=2024 DPT=80 WINDOW=1400 ACK
Jun  8 05:40:45 SRC= 1.2.3.4 DST=our_dns_server LEN=38 TTL=44 ID=7834 PROTO=ICMP TYPE=8 CODE=0 ID=47578 SEQ=5
Jun  8 05:40:50 SRC= 1.2.3.4 DST=our_dns_server LEN=58 TTL=44 ID=7835 PROTO=UDP SPT=2025 DPT=53
Jun  8 05:40:52 SRC= 1.2.3.4 DST=our_dns_server LEN=58 TTL=44 ID=7836 PROTO=UDP SPT=80 DPT=53
Jun  8 05:40:54 SRC= 1.2.3.4 DST=our_dns_server LEN=58 TTL=44 ID=7837 PROTO=TCP SPT=2026 DPT=53 WINDOW=1400 SYN
Jun  8 05:40:59 SRC= 1.2.3.4 DST=our_dns_server LEN=58 TTL=44 ID=7838 PROTO=TCP SPT=2026 DPT=53 WINDOW=1400 RST

14) You see the following traffic pattern in your proxy log. What is the most likely cause?

  • A) 192.168.1.22 is performing normal Web browsing.
  • B) 192.168.1.22 is downloading patches.
  • C) Someone on 192.168.1.22 is running an nmap version scan against 1.2.3.4.
  • D) 192.168.1.22 has been compromised and is calling home.

192.168.1.22 [ 9/Jul/2009:10:42:55 +0000] “GET http:// 1.2.3.4/ HTTP/1.1″ “-” “-”
192.168.1.22 [ 9/Jul/2009:10:42:55 +0000] “POST http:// 1.2.3.4/ HTTP/1.1″ “-” “-”
192.168.1.22 [ 9/Jul/2009:10:43:20 +0000] “GET http:// 1.2.3.4/ HTTP/1.1″ “-” “-”
192.168.1.22 [ 9/Jul/2009:10:43:20 +0000] “POST http:// 1.2.3.4/ HTTP/1.1″ “-” “-”
192.168.1.22 [ 9/Jul/2009:10:43:45 +0000] “GET http:// 1.2.3.4/ HTTP/1.1″ “-” “-”
192.168.1.22 [ 9/Jul/2009:10:43:45 +0000] “POST http:// 1.2.3.4/ HTTP/1.1″ “-” “-”

15) Analyze the following network drawing. How many potential paths does an attacker have available in order to gain access to the internal network?

  • A) 1
  • B) 2
  • C) 3
  • D) 4

network-paths

Answers will be posted tomorrow!

C

1) How many different techniques are available to sniff in a switched environment:

A) None. Switches block unicast traffic to all ports.

B) 2

C) 4

D) 6

2) You receive the ICMP packet shown below from a remote host. Which of the following is the most likely source of the packet?

15:52:50.129178 IP (tos 0×0, ttl 47, id 51389, offset 0, flags [none], proto: ICMP (1), length: 28) 1.2.3.4 > 172.30.2.10: ICMP echo request, id 18492, seq 21446

A) Ping run on a Windows system.

B) Ping run on a Linux system.

C) hping using the “-C 8” option.

D) nmap using the “-sP” option.

3) Which is the best way to discourage attackers from using your address space as part of a SYN flood attack?

A) Quietly drop all inbound SYN/ACK packets that are unsolicited.

B) Return an ICMP Admin Prohibited error packet for all inbound SYN/ACK traffic that is unsolicited.

C) Advertise all portions (even unused) of your IP address space via BGP.

D) Report all suspicious inbound traffic to the listed administrative contact of the source IP.

4) Which firewall product is susceptible to loose source route attacks?

A) Check Point

B) Cisco

C) Netscreen

D) None of the above

5) Which Libpcap filter would permit you to see potentially malicious IP fragments which could not have been generated by a normal topology MTU?

A) ip = frag and evil bit = enable

B) ip[12:2] = ip[16:2]

C) ip[2:2]<0x1F4 and ip[6]&32!=0

D) ip[8]<0x2A or ip[0]&0x0F>5

6) Which of the following techniques would permit an attacker to port scan your network without giving any indication of their true source IP address?

A) nmap “stealth” (-sS) scan.

B) nmap “idle” (-sI) scan.

C) nmap “decoy” (-D) scan.

D) Port scans require responses to stimulus so the true source IP cannot be completely hidden.

7) Which of the following best describes what happens when you surf to a Web site, see “HTTPS” in the URL, and the little lock icon on your Web browser is activated?

A) All data to and from the Web server is at least authenticated.

B) All data to and from the Web server is at least encrypted.

C) All data to and from the Web server is encrypted and the digital certificate is fully verified.

D) All data to and from the Web server is authenticated and encrypted.

8) You see the following packet leaving your Web server and headed to an IP address on the Internet. What is the most likely cause?

17:08:08.412172 IP (tos 0×0, ttl 128, id 18210, offset 0, flags [DF], proto: UDP (17), length: 33) 172.30.2.185.32851 > 1.2.3.4.69:

A) Problem with the firewall state table time-out being set too low.

B) Automatic update checking for new patches.

C) Attacker retrieving a toolkit.

D) A secure HTTPS session.

9) You see the following packet entering your network. Which answer gives the most accurate and likely possibility of what is going on?

19:22:17.631407 IP (tos 0×0, ttl 112, id 30435, offset 0, flags [DF], proto: TCP (6), length: 48) 1.2.3.4.4110 > 192.168.1.10.25: S, cksum 0xc25c (correct), 103504428:103504428(0) win 8192 <mss 1460,nop,nop,sackOK>

A) TCP transmission from a Windows system.

B) SMTP transmission from a Windows system.

C) Spam or Phishing attempt from a Windows system.

D) SMTP transmission from a Linux or UNIX system.

10) Given the following netstat output, which of the answers best describes the situation:

Proto Local Address Foreign Address State PID

TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 2648

TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 2292

TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 1204

TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4

A) The system has potentially been compromised.

B) The system needs a restart to install updated software.

C) The system is configured as a typical Windows desktop.

D) The system is configured as a typical Windows server.

11) Which of the following systems can potentially be taken over by a remote attacker?

A) A Web server exposed to Internet access.

B) A desktop with Internet access.

C) A firewall or Network Based Intrusion Prevention (NIPS) system.

D) All of the above.

E) None of the above.

12) A Network Based Intrusion Prevention System (NIPS) is simply a relabeled:

A) Proxy based firewall.

B) Stateful inspection based firewall.

C) Neither, it is its own unique technology.

D) A combination of both.

13) You see the following pattern in your firewall log, which answer best describes what may be going on?

A) Someone is fingerprinting which firewall product we are using.

B) A remote site is having connectivity issues connecting to our Web server.

C) The state table time-out value on our firewall is set too low.

D) This is normal and expected traffic to our servers.

Jun 8 05:40:36 SRC= 1.2.3.4 DST=our_web_server LEN=40 TTL=2 ID=7831 PROTO=TCP SPT=2023 DPT=80 WINDOW=1400 SYN

Jun 8 05:40:38 SRC= 1.2.3.4 DST=our_web_server LEN=40 TTL=44 ID=7832 PROTO=TCP SPT=80 DPT=80 WINDOW=1400 SYN

Jun 8 05:40:40 SRC= 1.2.3.4 DST=our_web_server LEN=40 TTL=44 ID=7833 PROTO=TCP SPT=2024 DPT=80 WINDOW=1400 ACK

Jun 8 05:40:45 SRC= 1.2.3.4 DST=our_dns_server LEN=38 TTL=44 ID=7834 PROTO=ICMP TYPE=8 CODE=0 ID=47578 SEQ=5

Jun 8 05:40:50 SRC= 1.2.3.4 DST=our_dns_server LEN=58 TTL=44 ID=7835 PROTO=UDP SPT=2025 DPT=53

Jun 8 05:40:52 SRC= 1.2.3.4 DST=our_dns_server LEN=58 TTL=44 ID=7836 PROTO=UDP SPT=80 DPT=53

Jun 8 05:40:54 SRC= 1.2.3.4 DST=our_dns_server LEN=58 TTL=44 ID=7837 PROTO=TCP SPT=2026 DPT=53 WINDOW=1400 SYN

Jun 8 05:40:59 SRC= 1.2.3.4 DST=our_dns_server LEN=58 TTL=44 ID=7838 PROTO=TCP SPT=2026 DPT=53 WINDOW=1400 RST

14) You see the following traffic pattern in your proxy log. What is the most likely cause?

A) 192.168.1.22 is performing normal Web browsing.

B) 192.168.1.22 is downloading patches.

C) Someone on 192.168.1.22 is running an nmap version scan against 1.2.3.4.

D) 192.168.1.22 has been compromised and is calling home.

192.168.1.22 [ 9/Jul/2009:10:42:55 +0000] “GET http:// 1.2.3.4/ HTTP/1.1″ “-” “-”

192.168.1.22 [ 9/Jul/2009:10:42:55 +0000] “POST http:// 1.2.3.4/ HTTP/1.1″ “-” “-”

192.168.1.22 [ 9/Jul/2009:10:43:20 +0000] “GET http:// 1.2.3.4/ HTTP/1.1″ “-” “-”

192.168.1.22 [ 9/Jul/2009:10:43:20 +0000] “POST http:// 1.2.3.4/ HTTP/1.1″ “-” “-”

192.168.1.22 [ 9/Jul/2009:10:43:45 +0000] “GET http:// 1.2.3.4/ HTTP/1.1″ “-” “-”

192.168.1.22 [ 9/Jul/2009:10:43:45 +0000] “POST http:// 1.2.3.4/ HTTP/1.1″ “-” “-”

No comments »

Posted in 2-alert, General Security, Network Security

Tags:

Test your network security skills – Answers

July 15th, 2009

In yesterday’s post I gave you a quick network security test to try. Here are the answers:

1) D

There are six different techniques that can be used to sniff in a switched environment. ARP cache poisoning, ARP cache flooding, DHCP spoofing, Port stealing, ICMP redirect attack and ICMP route discovery attack. High end vendor switches can be configured to block all of these except the ICMP redirect attack. That must be addressed on a per host level.

2) D

Ping on both Windows and Linux encapsulate data in the payload of their Echo-Request packets. The above packet has a length of 28, which is just an IP and ICMP header. When hping generates Echo-Request packets, it uses an initial sequence number of 0 and then increments by +256. The above sequence number of 21446 is not evenly divisible by 256. This makes nmap the most likely candidate as it generates empty payload Echo-Requests with random sequence numbers.

3) B

When your address space is spoofed as part of a SYN flood attack, you will see a high number of unsolicited SYN/ACK packets being sent to your network. Quietly dropping this traffic makes your address space highly attractive to attackers spoofing packets because it maximizes the amount of time their attacking SYN packets fill up the remote connection queue. By returning an ICMP error for these packets, your  IP address space becomes less desirable as you are quickly removing the attacking SYN packets from the remote connection queue.

4) C

All three products prevent source route packets (both loose and strict) from being bounced off of the firewall itself. Netscreen however will pass loose source route packets targeting a host on the other side. So to be safe from redirection attacks in a Netscreen environment, you must ensure source routing is disabled on all exposed hosts.

5) C

The first portion of the filter, “ip[2:2]<0x1F4” checks to see if the packet is less than 500 bytes in size. The second portion of the filter, “ip[6]&32!=0” checks to see if the more fragment flag is turned on. So the complete filter will catch non-last fragments smaller than 500 bytes. All non-last fragments will express the smallest topology Maximum Transmission Unit (MTU) they pass through. The smallest LAN or WAN MTU used in the Internet is 512 bytes. So fragments smaller than 500 bytes are being crafted, most likely to obfuscate an attack pattern and avoid detection.

6) B

An idle scan leverages the predictable IP ID’s being used by a secondary system in order to make it appear that all the scanning packets are originating from that host. Since all the scan packets use the spoofed IP address of this secondary host, the attacker’s true IP address is not revealed to the host being targeted. nmap’s stealth and decoy options still transmit packets using the attacker’s true source IP address.

7) A

The protocol HTTPS and the little lock icon being activated on a Web browser simply means that the SSL or TLS protocol is being used to secure the data stream. Both specifications require that every packet be authenticated. Both specifications make encryption an optional feature. So its possible to use either SSL or TLS to communicate without encrypting any of the data passing between the systems. The only way to prevent this is to disable these options in your browser. Further, digital certificates are typically checked against a locally stored public key, but the browser does not check to see if the certificate has been revoked. This can also be changed through the browser’s options.

8 ) C

The traffic in question is an outbound attempt to connect to a TFTP server. Since Web servers do not use TFTP, this is not a problem with the firewall state table. Also, vendors do not make fixes available via TFTP, so this is not a check for new patches. The most likely candidate is that an attacker has compromised the system and is attempting to move their toolkit onto the box.

9) C

The TTL value in this packet is 112. Linux and UNIX use a starting TTL of 64, so this packet most likely did not come from one of these systems. Windows uses 128 as a starting TTL so this could likely be a Windows host located 16 hops away. This is a TCP packet headed to port 25, so it is most likely the start of an SMTP session. The system is using a very small window size (8192 bytes) and does not support the TCP windowing option (this would be listed in the output as “wscale” followed by a numeric value), which indicates that it is an older Windows desktop system. Since most organizations do not rely on old Windows desktops as their SMTP servers, this is most likely a compromised host transmitting spam or phishing attacks. A firewall such as pf or Netfilter would be able to filter these packets by passively identifying the source operating system.

10) A

Within a Linux or UNIX environment, ports can only be opened exclusively. This means that only one application can hold open a TCP or UDP listening port at any given time. While most Windows applications open ports exclusively as well, Windows permits applications to listen with non-exclusive access. The result is that one application will service most inbound sessions but if that port is busied out, connections are then passed to the second application. This can permit an attacker to open a back door on a system that is undetectable during port scans of the system.

11) D

The classic view is that only systems with open listening ports exposed to Internet access are susceptible to attack. The point of risk is in fact permitting unknown entities to interact with code running on the local system. All of the indicated systems permit some level of code interaction with untrusted IPs on the Internet. With this in mind, all can potentially be remotely compromised.

12) B

Network based intrusion prevention systems leverage stateful inspection technology to analyze both header and payload information, same as a stateful inspection based firewall. Sometimes NIPS provides more signatures to look for hostile patterns, but most high-end stateful inspection firewalls provide multiple signatures as well, but typically at a lower cost.

13) A

There are many suspicious patterns in these log entries. To start, the Time To Live (TTL) in the first packet is 2. Given modern OSs use a starting TTL of 64 or higher, and most systems are about 15 hops away from each other on the Internet, we should never see a TTL this low. Most likely this is someone running a TCPTraceroute variant to map our network through the firewall.

Look at the length of the first three TCP packets; its 40 bytes. This means no TCP options have been set. All modern day operating systems support some number of TCP options, so these looks like crafted packets. Also, the TTL of 44 is indicative of a Linux or UNIX variant, but the increment of the IP identification (ID) looks like a Windows system. The Echo Request recorded in log entry four is also suspicious, as a Linux/UNIX variant would use an initial Echo-Request sequence number of 0 or 1, not 5.

So what’s going on? Look at the source port in the first two packets. Based on the response (if any) from these probes a smart attacker can tell what technology the firewall is based on (proxy, static filtering or stateful filtering). If you know which firewall products leverage each technology, its now just a matter of further reducing the possibilities.

The second packet would identify if the source port is being restricted, which is done by some firewall products but not others. The third packet would identify if an ACK can create a new state table entry, which again is done by some products but not others. The rest of the pattern is similar. Based on what replies come back from each of these probe packets a smart attacker may be able to identify what vendor firewall product we are running.

14) D

The log entries claim this is normal HTTP 1.1 traffic. The issue is that normal HTTP traffic would include additional fields of information such as the full URI visited (we just see the target IP address 1.2.3.4) and the host identification field (what OS is being used, name and version of the browser, etc.). Both of these pieces of information are missing, which makes the log entries very suspicious. The GET and POST nature of the traffic implies that an exchange of information is taking place. While we would want to confirm via additional investigation work, it is very likely our internal system (192.168.1.22) has been compromised and is calling home for instructions.

15) C

There are three potential paths into the internal network; through the firewall, through the VPN gateway and through the switch. The firewall may be attacked directly or via data replies from a malicious site. The VPN gateway has exposed ports with no trusted system to monitor them, so it is susceptible to direct attack. Finally, the switch is a potential path as it is VLANing across multiple security zones. Features like auto trunk negotiation may be leveraged to gain access to the internal network from the DMZ, thus bypassing the firewall’s filtering capability between these two security zones.

So how did you do? The benchmark is being able to answer (meaning you knew the answer, not just a lucky guess ;) ) 12/15 questions. If you scored below that point its time to hone the old skills.

No comments »

Posted in 2-alert, General Security, Network Security

Tags:

TIC article on Networkworld

July 10th, 2009

Networkworld has an article on the DDoS attacks that appears to be originating out of North Korea. Here’s a link to it. The jist of the article is that the DDoS attacks were worse than they should have been because security folks did not know what ISP they were using. The claim was that if the government would hurry up and implement the Trusted Internet Connect (TIC) program, these problems would be a thing of the past.

First a little background, TIC is an effort to reduce the number of connections to the Internet maintained by federal, state and military networks. In 2006 there was somewhere in the neighborhood of 4,500 connections (at the time I was involved no one knew for sure exactly how many connections there were). The original goal was to reduce this to 50 connections. Last I heard the goal was 113. Expect it to float around in this ballpark for a while. Currently they’ve been able to eliminate about 25% of the connections.

There are many reasons why this is a good idea. Single point of security implementation, consolidation of resources, a more uniform implementation of security policy, just to name a few. There are many reasons why this is also a bad idea, one of which is the mitigation of DDoS attacks like the one described in the article.

Look at it this way, if I take 100 Internet connections and consolidate it into 1, I’m not going to implement a single link with 100X bandwidth (30 Gb is about the max we can push today anyway and running at that level severely limits your security product options). I’m going to do the same thing ISPs do, over subscribe the link. Since it is unlikely everyone will try and access the Internet at the same time, normally this works just fine. The problem occurs when a DDoS attack takes place as now there is less bandwidth that needs to be saturated in order for the DoS to be successful. It also means that a greater number of sites will be affected. So I would argue that TIC has the potential to make this problem worse, not better.

But let’s try and look at the true root cause of all of this. They quote Alan Paller as saying they could not get the ISP to filter the traffic. The author states this is because they didn’t know which ISP to contact. Huh? How about a whois query on the address space? Traceroute? Check the monthly bill? Direct ARIN query? I find it hard to believe that a staff of security folks would sit around staring at each other with no idea how to figure out who their ISP is. More likely the ISP did not want to take responsibility for filtering the traffic. I know I’ve run into that problem dozens of times over my career.

Its also possible that this was a pretty low priority. Think about it. The attack started on July 4th. Think back to that day. Were you out enjoying sun and family or thinking “Humm, I wonder if the Federal Trade Commission posted anything today on the state of the economy. OMG I’m financially ruined, I can’t get to their Web site!”? :) My guess is the former. This is/was a relatively lame attack which was easily mitigated by Monday morning, when access to the site actually had some value. For anyone who’s taken one of my classes, you know I’m fond of saying “Its OK to accept risk provided its an informed decision”. I can see someone making a business decision that it was better to get it working by Monday morning than to spend time, resources and tax dollars on recovering the site during a time period when it would see little use.

So it remains to be seen if TIC will make the DDoS problem better or worse. What would certainly help is a good SLA written into the contract requiring the ISP to respond to these types of attacks.

May the bits be with you,

C

No comments »

Posted in 4-notice, Network Security

Tags: