Showing posts with label network. Show all posts
Showing posts with label network. Show all posts

Wednesday, August 7, 2013

Researchers develop new method for understanding network connections

This is interesting: a team of researchers at MIT have designed a way to find the underlying network under an observed network.  This allows to find the direct dependencies in a network, separating in the process the indirect links, or elements that just "tag along" other elements.

The paper is here, but behind a paywall.


Friday, April 5, 2013

IT Pro confession: How I helped in the BIGGEST DDoS OF ALL TIME


Spamhaus is a Dutch company specialized in gathering lists of spam sources on the Internet and publishing them. Many mail sites - mine was as well until I moved it to Google - use their service to drop the spam before it even hits the mailbox. So, positive.

Enters another player, CuberBunker, another Dutch company, specialized in hosting pretty much anything except "terrorism and pedopornography." At least that's what it claims.

Spamhaus volunteers started detecting spam being sent from the CyberBunker servers, and they proceeded into blacklisting them. That started the beef between the two. You will find the CloudFlare blog entry here, CloudFlare being Spamhaus's hosting company.

CyberBunker clients, instead of doing something technically clever, ran a script-kiddie type DDoS: a massive attack using DNS amplification. As someone put it, that was akin to trying to take a person down by using a machine gun in a crowd.

This was made possible due to the large number of DNS accepting recursive resolutions from anywhere on the Internet.

Trevor Pott, a sysadmin, took the courage to write a short article for The Register on how he was an unwilling help for the CyberBunker side: he explains the mistake he made and how he corrected them. He also has a few cool tricks, some of them helped in limiting the damage. Even the US-CERT has a document on securing the common DNS servers. Oh, this document was published in 2006 ... the problem is nothing new. Some more information and stats can be found on OpenResolver.

Bottom line:


  • Sysadmins tend to forget about the "small" services that keep the network running: NTP, DNS, DHCP and so forth, and often, these servers are left unpatched or untested;
  • That sucks, but different version of the same software may have different default configurations! The keyword is "inventory", and knowing where each component of your infrastructure runs. And reading the release notes;
  • There is no one-magic-bullet-security-stuff that will solve all the problem: Trevor had a few layers in place that mitigated the damages caused by the misconfiguration. Namely, he limited the bandwidth available for DNS to 500Kb/s. He initially saw a 10Mb/s surge;
  • If you have people like Trevor who understand what they are doing, your network is in good hands.

Friday, March 22, 2013

Researcher ropes poorly protected devices into botnet to map the Internet

Okay, don't try this at home: the researcher(s) did this illegally, and if someone files a complaint, she, he or they can be in very serious trouble, facing fines and possible jail time.

An unnamed researcher or a group of researchers did a scan of the Internet and, when they found any, leveraged unprotected devices. The access was granted with "admin:admin", "root:root", "admin:" or "root:". It seems that, even though we are in 2013, several thousands of devices are not protected by a serious password. From the look of it, I would say these are the defaults.

During their scan and when accessing these devices, they found a number of them compromised by a really-malware botnet, Aidra.

The main finding is that out of the nearly 3.6 billion IPs scanned, only 1.3 billion (roughly 36%) are in use, the rest being reported as not used. This however raises the question on whether an non-responsive IP is due to a host with very strong filtering abilities. I suspect that the number of active IPs is higher than what they reported.

The article is to be found here.If you want, the scan dataset is available on the download page.

Monday, February 18, 2013

IPv6 anyone?

Recently, I was fiddling in a terminal and I noticed something strange: a bunch of connections going to IPv6 addresses.

A while back, I subscribed to Hurricane's TunnelBroker and I got my own networks, a /48 and a /64. However, this IPv6 was not one of them, and I was really sure that the tunnel was done. Actually, the tunnel terminated on a small cisco router that's been sitting quietly in a cupboard for a few weeks.


Here is the output of my "ifconfig":


em1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.0.6  netmask 255.255.255.0  broadcast 10.0.0.255
        inet6 2a00:1028:838a:1d8e:21d:60ff:fe04:f31c  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::21d:60ff:fe04:f31c  prefixlen 64  scopeid 0x20<link>
        ether 00:1d:60:04:f3:1c  txqueuelen 1000  (Ethernet)
        RX packets 442625  bytes 241048181 (229.8 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 482924  bytes 92626306 (88.3 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

The IPv6 2a00:1028:838a:1d8e:21d:60ff:fe04:f31c subnet belongs to my provider, O2 Czech Republic (or Telefonica). So ... My ISP supports native IPv6? Cool!

Let's go further: as there is nothing in my small router's web interface, let's have a look through the CLI. Yep,  both the inside (br0) and outside (ppp0) interfaces have IPv6. Quite expected!


br0       Link encap:Ethernet  HWaddr B0:B2:DC:16:3A:4C  
          inet addr:10.0.0.138  Bcast:10.0.0.255  Mask:255.255.255.0
          inet6 addr: 2a00:1028:838a:1d8e::1/64 Scope:Global
          inet6 addr: fe80::1/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3932310 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4920649 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:633818668 (604.4 MiB)  TX bytes:43890958 (41.8 MiB)

ppp0      Link encap:Point-Point Protocol  
          inet addr:10.226.135.99  P-t-P:88.103.200.41  Mask:255.255.255.255
          inet6 addr: 2a00:1028:838a:1d8c::1/64 Scope:Global
          inet6 addr: fe80::b2b2:dcff:fe16:3a4c/10 Scope:Link
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
          RX packets:4873418 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3806955 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3 
          RX bytes:4266450464 (3.9 GiB)  TX bytes:623147288 (594.2 MiB)

When confronted to that, my first reaction is "Gosh! Firewall!". Here, that's fine: the firewall is configured to block everything that's not originating inside. This is confirmed by an online IPv6 scanner.

But then: "what if I put a rule that allows an IP on the Inside to be pinged from the Internet?"

Let's try it. It's only a try so I put the entry directly into the IPv6 FORWARD table. I found several sites that offer the ability to run a ping test to an IPv6 host. Here is the one I used. As expected, there are replies, versus none before the line was added.

Weird part is I do remember checking a few weeks ago and I had no IPv6 connectivity. So what happened?

On New Year's eve, my previous provider's supplied router died. So after a few calls and a few days, a tech from O2 showed up with a new router. I didn't really pay attention at the time, as I was quite busy with a number of other things.

The Model Number is P-660HN-T3A_IPv6, apparently a model specific to O2. When I looked up on the Zyxel website, I couldn't find any matching firmware; the latest vendor provided firmware dates back to 2011. Searching for "O2 IPv6" returns a few hits. However and funnily enough, it states that the P-66HN-T3A doesn't support IPv6 yet ...

Now, I have to contact my server hosting company in France, so they activate IPv6 as well. 

And one more task on my to-do list: continue playing with IPv6.








Monday, December 24, 2012

Cisco Security Part II - Security at the port level

2. Security at the port level


A switch is used to interconnect different devices: desktops, laptops, servers, printers, other switches and so forth. By granting access to a network, an administrator increases the likelihood of a security breach as well as the vulnerability landscape. Here are three actions that can be performed:

  • Connection a non-approved device. Particularly nowadays with BYOD being teh buzzword, the proliferation of personal devices that can be connected to the network has exploded.
  • Abuse of the port, for example by creating a trunk that allows a device to have access to networks not supposed to be accessed directly.
  • Injection of control frames into the network, for example modification of the spanning-tree topology.
Of course, there are many, many more possible attacks. However, the purpose of this document is not to enumerate everything known to mankind, as by the time this document hits the web, there will already be things to be added.

2.1 Trunk/access

When interconnecting two switches, the need to transmit frames that belong to different virtual LAN (VLAN) may arise. In order to do so, network device vendors came up with different solutions, such as ISL from Cisco. Later, the protocol to transmit multiple VLAN over a single physical connection was standardized by the IEEE as 802.1Q.

Trunking is also used in IP Telephony: the usual setup is to have the PC piggy-back on the phone, which acts as a small switch. The “normal” data traffic is sent and received as-is and the voice traffic is encapsulated within 802.1Q. This gives the ability to separate both traffics and to use additional fields in the 802.1Q header to prioritize the voice traffic over other forms of traffic.

However, if not restricted, this ability can also be a recipe for disaster. For example, if all the ports carry all the VLANs or have the ability to create a trunk, an attacker could leverage that to gain access to other networks by sending tagged frames back to the switch.

In Cisco terminology, a trunk is called a “trunk” port (obvious, isn’t it?) and a non-trunk port is called an “access” port. An access port won’t send any 802.1Q encapsulated frame to the connected device. In the receive direction, the frame will be dropped.

In order to configure a port as an access or a trunk, the command "switchport" needs to be used within the interface:

interface GigabitEthernet 0/10
 switchport mode access

This will instruct the switch to treat the port Gi0/10 as an access port.

Once a port's mode has been set, further configuration is possible. For instance, if the port is an access port, the VLAN on which that port resides can be set with:

switchport access vlan 20

Likewise, a trunk port with native VLAN (defined later) 10 and with tagged VLAN 20 and 30 is configured with:

interface GigabitEthernet0/11
 switchport mode trunk
 switchport trunk native vlan 10
 switchport trunk allowed vlan 10,20,30

The native VLAN on a trunk is the VLAN in which all the untagged frames received will be placed, and that will be sent untagged. Numerous documents refer to the danger of native VLAN in regard to VLAN hopping or the abuse of Q-in-Q. A good practice is to make sure the native VLAN of all your inter-switch trunks are not assigned to any user VLAN.

2.2 Negotiation of a trunk (DTP)


Cisco switches allow a trunk to be dynamically formed. This means that if you don't force the mode, the connected device can announce itself as a switch and negotiate a trunk. The protocol responsible for this is Dynamic Trunking Protocol or DTP.

With the mode forced to access, the negotiation is automatically stopped. If set to a trunk and if the negotiation is left on, the switch will use DTP to inform its peer it can form a trunk.

To disable the trunk negotiation, the command is

switchport nonegotiate

2.3 Spanning-tree

Spanning Tree is the protocol responsible for negotiating a loop-free topology, even if the physical infrastructure has loops, for example for redundancy. It works by electing a root switch, which will then send specific frames called BPDU (Bridge Protocol Data Unit) that all switches in the topology have to forward following certain rules.

Based on the BPDU and the port it was received, each switch designs a port leading to the root, possibly through other switches, a set of ports that can be used for other connected switches to reach the root, and a set of blocked ports. These are ports the switch could use to reach the root, but with a higher cost.

These BPDUs have multiple roles: they can announce a better path to the root, they are used to hold the root election and they can influence the whole topology.

From what precedes, an attacker can abuse this protocol to either perform a DoS against the network, or forward all the traffic to a specific machine.

When designing a network, it is important to minimize the role of spanning-tree by using other techniques, such as bonding multiple interfaces into a single logical interface called a port-channel or an etherchannel.

When a port comes up, the default behavior is to wait for a certain amount of time, that depends on the version of spanning-tree used, to determine what the status of the port should be (root, designated, blocked). Cisco invented a mechanism to permit the port to start forwarding before that time, called "portfast".

With that came the risk of creating short network loops,until the port got the first BPDU and adopt the relevant state.

2.3.1 bpduguard

Cisco developed a security feature to force a port to go immediately down if a BPDU is received. The BPDU will be dropped as well.

If a port is connected to a phone or a computer, there is no valid reason why a BPDU should be received. On the other hand, if a BPDU is received from a port connected to a user device, this could indicate:

  • an attempt to inject BPDUs into the network, regardless of the reason;
  • an temporary loop in the network due to incorrect network settings on a computer or a connectivity issue;
  • a replay of a previous network capture;
  • and possibly other reasons.
In such an event, a reasonable thing to do is to drop the port to the down state, to prevent further incidents. This is configured on a device interface with:

interface GigabitEthernet 0/12
 spanning-tree bpduguard enable

Upon reception of a BPDU on the port, the state will be err-disable. To correct this,the port needs to be reset (shutdown/no shutdown) or the error recovery mechanism needs to be activated. This latter is not recommended as it will put the port back in service, possibly allowing the activity to resume.

It is also worth to notice that the default for this command has changed between IOS and NX-OS: a show configuration all will display these values.

2.3.2 bpdufilter

In situations where bpduguard is not welcome, for instance on uplinks to a provider, another mechanism exists: bpdufilter. Instead of shutting the port down, bpdufilter drops all bpdus, incoming and outgoing. This has the side effect of splitting the spanning-tree domain in two.

In my past, I had to help an ISP configure it: his switch connected to his clients' frequently had issues. It was found that on some occasions, the spanning-tree root role changed from his internal network to a client's.

However, it needs to be understood that, as spanning-tree is no longer working, topology loops in this situation have to be manually addresed, for instance in the form of a manual activation, or by using techniques that negate the need for spanning-tree, such as etherchannel, or unique VLANs with a L3 redundancy solution.

The configuration looks like bpduguard's:

interface GigabithEthernet0/12
 spanning-tree bpdufilter enable

2.3.3 portfast / port type edge

The spanning-tree protocol mandates that a port goes through various states before being able to forward traffic. During these state, no traffic is received or emitted besides BPDUs.

A way to speed that process is to declare the port as "portfast" or "type edge". It means that spanning-tree will take a shortcut in the states and be able to forward quickly after being turned on.

However, this has to be gauged: on the one hand, this means that a user device will have access to the network sooner, but on the other hand, it permits the creation of temporary loops - until the next BPDU is seen, the link will be up. As soon as a BPDU arrives on the port, the normal spanning-tree decision concerning the port role (root, designated etc) is taken and one end of the loop will be blocked.

An attacker could leverage this fact to create temporary, short lived loops to disrupt the switch operations. If successful, this can create either a switch or topology wide outage.

Other ways of dealing with the timers are possible: one could use rapid spanning-tree and shorten the timers from 2 seconds to 1 for the <Hello> BPDU - as more BPDUs are sent, the expected life of a loop is cut down, limiting the risk or the possibility of perpetrating such an attack. This, however, has to be evaluated as a shorter timer may also increase the risk of instabilities on the network: a transient frame drop on a link can result in flapping between that link and a backup link, possibly amplifying the problem.

2.4 Mac address learning on a port

The role of a switch is to build a table of what mac address resides on what port, and forward frames accordingly. This allows for point-to-point communications between two devices within the same VLAN, without impacting the other connected devices. A way of describing this is to state that the collision domain is limited to the port and the device connected to it.

As the switch has to consult that table binding a MAC to a port for every frame, the memory dedicated is called CAM (Content Addressable Memory), a special type of memory which is in limited quantity in any device.

An attack of the "old days" was to generate many frames with random source MAC address. This caused the switch to learn these in its CAM, filling it to the point that no new entry could be created. Any new MAC would not be learned, and the forwarding process would be for the switch to broadcast a frame to these legit but unknown addresses to all port, transforming the switch into a hub and allowing an attacker to sniff the corresponding traffic.

2.4.1 Number of permitted mac addresses


The first line of defense offered by a switch is to limit the number of MAC addresses permitted on a given port - past the number, the switch will either drop the frame or even shut the port down. MAC address counting works with the VLAN ID included in the learning: the same address seen on the same port but on two different VLANs count as two entries, one per VLAN. This is important to understand when using devices such as IP phones that may start in a VLAN and jump to a different VLAN afterwards.

The question now is: what about forgetting the known addresses? Should the switch keep them forever? Or forward these entries after a certain time?

2.4.2 Sticky Learning

In a static world, a machine is always connected to the same port, and thus the MAC address will always be seen on the same port. In that case, a sticky learning is possible, meaning that the switch will permanently - even across reboots - remember the association.

A nice - or annoying, it depends what your goals are - feature of this memorization is that if a MAC address known on a given port is seen somewhere else as source, the frame will be dropped and a security violation logged.

2.4.3 Aging considerations

However, the world is not static: laptops move from offices to meeting rooms, workstations are installed and reused and so forth. So the concept of sticky learning doesn't work well, or one needs an army of network administrator to prune the entries as machines are being moved.
Another possibility is to enforce a certain time after which the entry will be forgotten. This time is either an idle time (no frame exchanged for a certain period) or absolute (the address is removed even if traffic is seen, leading to a renewal of the learning if need be). 

2.4.4 Actions for violations

As said, the action can be the simple drop of the frame, the drop of the frame plus logging or even to shut the port completely down.

Deciding which one is a matter of policies and will of surfacing the issues - if the only thing happening is the frame being dropped, the event may go unnoticed until a user complains he has a problem. On the other hand, if the port is shut down, a visible trace exists of the event, that can be investigated and acted upon.

2.4.5 Putting it together 

Now, time to show some configurations.

2.4.5.1 Basic port security, 3 MAC addresses, no sticky learning, drop-and-log upon violation, portfast and bpduguard, mac address forgotten after 5 minutes. 

This configuration is almost a "this is your average mileage": it will work okay in many situations.

interface gigabitEthernet 0/12
 switchport port-security
 switchport port-security maximum 3
 switchport port-security violation restrict
 switchport port-security aging time 5
 spanning-tree portfast
 spanning-tree bpduguard enable
 [rest of the configuration]

2.4.5.2 Sticky learning, 2 MAC addresses, drop-and-log upon violation, portfast and bpduguard.

This could be used for a server. The first two mac addresses seen on the port are learnt.

interface gigabitEthernet 0/12
 switchport port-security
 switchport port-security maximum 2
 switchport port-security violation restrict
 switchport port-security mac-address sticky
 spanning-tree portfast
 spanning-tree bpduguard enable
 [rest of the configuration]

2.5 Recommended configurations

2.5.1 Workstation

We consider this machine to be installed at a desk and will never be moved, no phone

interface gigabitEthernet 0/12
 switchport mode access
 switchport access vlan XX
 switchport port-security
 switchport port-security maximum 1
 switchport port-security violation restrict
 switchport port-security mac-address sticky
 spanning-tree portfast
 spanning-tree bpduguard enable
 switchport nonegotiate

2.5.2 Laptop/meeting room

That machine may be moved between ports.

interface gigabitEthernet 0/12
 switchport mode access
 switchport access vlan XX
 switchport port-security
 switchport port-security maximum 1
 switchport port-security violation restrict
 switchport port-security aging time 5
 spanning-tree portfast
 spanning-tree bpduguard enable
 switchport nonegotiate

2.5.3 Phone with computer attached

The phone starts in a VLAN and moves to the new one (voice), workstation attached

Note: the phone negotiates its voice vlan using either CDP or LLDP, but this will not be discussed in this document.

interface gigabitEthernet 0/12
 switchport mode access
 switchport access vlan XX
 switchport voice vlan YY
 switchport port-security
 switchport port-security maximum 3
 switchport port-security violation restrict
 switchport port-security mac-address sticky
 spanning-tree portfast
 spanning-tree bpduguard enable
 switchport nonegotiate

2.5.4 Server / router

This considers that there is not virtual or cluster IP.

interface gigabitEthernet 0/12
 switchport mode access
 switchport access vlan XX
 switchport port-security
 switchport port-security maximum 1
 switchport port-security violation restrict
 switchport port-security mac-address sticky
 spanning-tree portfast
 spanning-tree bpduguard enable
 switchport nonegotiate

2.5.5 Network provider / external party

interface gigabitEthernet 0/12
 switchport mode access
 switchport access vlan XX
 switchport port-security
 spanning-tree portfast
 spanning-tree bpdufilter enable
 switchport nonegotiate

Wednesday, November 21, 2012

Australia's biggest Telco sold Routers with hardcoded Password

Talking of an epic fail ... this article on Slashdot:
"Hardcoded usernames and passwords have been discovered in a recent line of Telstra broadband routers that allow attackers access to customer networks. The flaws meant customer unique passwords could be bypassed to access the device administrative console and LAN."
The security researcher Roberto Paleari found that vulnerability and informed BigPond's technical support. However, due to the lack of response, he made it public on October 12, 2012. 

The sad thing is we are trying to educate the base users to security, to not open anything they get in e-mails, to choose decent passwords and to keep their systems up-to-date, to end up with a supposedly knowledgeable ISP doing that kind of major screw-up.

In this case, no matter how complex the user password is, that hardcoded one can be used to get into the customer's router, permitting an hostile party  the access to the customer's network and computers. 

My question: if someone is accused of piracy, I wonder whether BigPond may get some heat and be considered as responsible for all the damages.

Monday, November 12, 2012

Slashdot post: how to deal with a DDoS attack?

A Slashdot reader posted an article about an attack his company recently suffered. The summary is a criminal from Lebanon contacted him asking for a "fee" not to attack, the company initially said no and was taken offline by a DDoS, the company paid and the attack ceased.

A DDoS is an attacked aimed at exhausting a resource: a compute resource (CPU, Memory, HDD space) or a network resource (Router/Firewall CPU or memory, number of sessions, bandwidth). The most important is to understand what your systems are vulnerable too.

For instance, an attacker could perform a DDoS of an application by requesting abnormally long calculations in a loop, let's say computing pi to the 20 billionth decimals. If the system has at its heart only a single application server, it may be busy processing the request while delaying all the other queries. In the same way, the attacker could also request something that's abnormally large, for example generating a picture that is 10 million per 10 milllion pixels.

The most important is to know what you can act upon and what you can: there are things you can change - the architecture of the applications, the way parameters are validated, if you distribute the front-end load across multiple servers and so forth - and things you can't change: the number of sessions coming from the Internet and the rate at which they come in. For the latter, it is important to understand what your business is, who you are doing business with and what level of degradation/loss of service you accept: an american company may consider that dropping all requests from South America, Africa and Asia is acceptable if this helps maintaining its business with the USA, and thus may negotiate with their provider that upon request, an ACL allowing only the networks assigned to the ARIN and RIPE are to go through. Other companies may find this unacceptable and will have to find other solutions, such as geo-location for the access to the application.



Monday, November 5, 2012

A cool article on Oliver Heaviside

Most of us know Oliver Heaviside through the function that bears is name. There is a nice article on the man behind that function on Physics Today.



Monday, August 13, 2012

Cisco Switch Security (Introduction)

Networks are the core of all modern computer and information processing infrastructure. Regardless of the level of abstraction used - SaaS, PaaS, IaaS, cloud computing and so forth - networks and network devices still sit in the path of all data transfers.

Securing a network device means that steps will be taken to harden its configuration, ascertain no knowledge can be gained by interrogating the device, that only the authorized personnel will have access to its management interfaces and that it will contribute to the overall security scheme of the organization in a "security in depth" framework.

The result of a compromised network device can be extreme: not only the attacker has the ability to disrupt a corporation's communications, but also to modify the traffic path, sniff the transfers or even alter the data in transit. Scary? Yes and it is only a summary.

Several resources exist that describe how to secure network devices. One of them is the Security Configuration Guides as part of the NSA's Information Assurance program. Some of the steps in these articles are from that guide.

Over the next few weeks, different aspects of switch security will be examined:


  • Section 1 treats of the management console and interface
  • Section 2 addresses the security at the port level 
  • Section 3 examines security at the VLAN level
  • Section 4 deals with two additional layer 2 protocols
  • Section 5 treats of logging and logs
  • Section 6 deals with miscellaneous items








Saturday, July 7, 2012

How to protect your home internet connection

Besides protecting your computers, protecting your access is an important part of your home network security. This includes multiple parts:



  1. Protecting the management of your Internet router
  2. Creating rules to allow only what you need to go from the Internet to your network
  3. Creating rules to allow only what you need to go from your network to the Internet

1. Protecting the management of your Internet router

It may sound dull, obvious and over-repeated but this is a very important part of securing your network. For instance, I just scanned the /24 Internet network I am on: I found the router of another subscriber with remote management - usually port tcp/8080 - and it took me two attempts to find the administrative password. In this case, the username is "admin" and the password is "admin". 

From there, what can I do? A lot! I could obviously mess with the person's Internet access, but I could also get his username/password. On another side, I could also start creating PAT to access his home machines, potentially getting access to his computers. From there: game over, I'm in.

The first thing I suggest: when you get a new Internet router, change the password! There are lists of all the default combinations of username/password for the major brands.

Then, ask yourself that question: how likely is it you will be administering your router from the Internet? In most of the cases, the answer is: not likely at all. In that case, I suggest disabling the remote management facility.

2. Creating rules to allow only what you need to go from the Internet to your network

99% of the time the answer is: you don't need to allow any access from the Internet to your internal network. Do you really host a server at home? Or is it to access your home machine from work? 

In all the cases, be aware of what you do! If you expose your machine to the Internet, you may be giving access from a wider audience than you realize. And in that case, how well is your machine protected? Again, scanning the /24 Internet network I am on, I found 4 machines accessible through RDP. Chances are that I could find a combination of username/password, and again: then, I am in. Game over.

If you need to access your machine from outside your internal network, restrict the IPs from which this is possible. Are you accessing it from your workplace? Ask your network team what the corporate public IP range is, and allow only from that range. If you can't restrict to a specific set of IPs or networks, investigate other ways, such as a secured VPN, and don't be shy with the password!

3. Creating rules to allow only what your need to go from your network to the Internet

This is probably the most overlooked part: all the routers usually come with a default policy that permits anything from the inside network to the outside. While this is nice and works in all the cases, it also adds several security vulnerabilities.

  • Unwanted applications may start communicating
For instance, do you use IRC? Or peer-to-peer? Or do you often send e-mail through a chinese mail server? If the answer is "no", then blocking the corresponding hosts/ports will increase the security of your network. For instance, my own rule set allows:

  • HTTP/HTTPS/FTP/POPS/IMAPS/SSH to the whole Internet;
  • SMTP/SMTPS to my mail server
  • Google Chat to the whole Internet
  • MSN to the address defined in my IM client
  • DNS to the two Google DNS servers 8.8.8.8 and 8.8.4.4
  • A couple of ports/hosts needed for a few online games I play from time to time

And that's it. All in all, I have 29 rules, including the last one that denies everything that is not explicitly permitted. Once in a while, I look at the logs and check whether something was dropped, and if so, if it is normal - such as friends staying with me, broadcasts and all the noise that can exist on a network.

This actually helped me show to a friend that his machine was infected. He was visiting and needed access for his laptop, which I provided through my home wireless. I happened to be playing with IPv6, and I started seeing a lot of drops. Further investigation proved that these were attempts from his machine to send e-mails. I then asked if he was trying to e-mail, and he wasn't, so we started looking closer at his machine, It appeared his machine was compromised by a Trojan that was trying to send some spam. 

Another example happened when I was helping a friend secure his home network. We started seeing drops on some ports. It happens his kid had installed a peer-to-peer client on the family computer. When we looked at the peer-to-peer program, we found it was not secured at all and was sharing his whole hard drive.

  • Your machine may be used to scan the Internet to find other vulnerable machines

If your machine gets compromised, it may start scanning the Internet to find other vulnerable computers. This may result in your address appearing as an attacker in other people's logs, with the potential consequence that you may get a visit from your local authorities - in certain countries, if you fail to protect your Internet connection and your computer, you may be considered responsible for all the damages resulting from a compromise originating from IP address, regardless of whether your are the actual author.

Happy surfing!



Saturday, June 30, 2012

How to report an abuse to an ISP/SP

From time to time, you will have to report an abuse to an Internet Service Provider (ISP). Having been at both ends of this, I know it can be a frustrating task. As the person submitting the abuse report, you always end up having to feedback or a vague, generic e-mail that informs you that your report will be read and that, if needed, actions will be taken. In most of the case, this is the only response you will get. 

As the person receiving the abuse reports, you have to deal with incomplete or ambiguous information, people demanding the name of a subscriber, and from time to time, profanities and threats. Usually, that receiver gets the report from someone with no connection whatsoever to his service - understand by that "not paying anything" - on someone who gives him good money. That's a conflict of interest various laws tried to solve by imposing to the ISPs the obligation of notifying users of potential misconducts, as these may be unintentional, for instance in the case of machines infected by a virus.

In all cases, it is important to stay polite and courteous, after all, the person reporting the abuse is asking for help, but the person receiving the report may have a legal obligation in taking action.

A good report includes:

- The IP address of the machine that allegedly did the abuse;
- The IP address of the machine that was the target of the abuse;
- A description of the abuse, in factual terms - no elaboration or intents;
- The relevant entries from the logs with timestamps - the relevant entries only, no need to forward a 10MB log to show 2 lines;
- The timezone the machine is in.

In addition to these, I usually add a short note inviting the ISP to contact me should more information be needed.

Unless you are familiar with the language spoken by the ISP you are reporting the abuse to, English is a good bet to write the e-mail. If your logs are not in the same language, offer to provide a translation.

Here is an example of e-mail I would send:

Subject: potential abuse coming from x.x.x.x

Sir,
My logs indicate that x.x.x.x tried several combinations of username/password on my SMTP server, with IP y.y.y.y.

Please find the logs below. All the times are EST.
Should you need more information or log, feel free to send me an e-mail.
[Logs]

Now comes the question: how to find the e-mail address to report an abuse.

The Whois service

All IP networks have been allocated by a regional Internet Registry. These operate over a geographic area and are responsible for assigning the IP networks, maintaining the technical and administrative contacts and providing some base information regarding the IP networks.

For the North America, the registry is ARIN. On the top right corner, there is a box called "Search WHOIS". This is were you will put the offending IP. The result may, or may not include an "abuse contact".

When it doesn't include such a record, I look to see if there is a link to another delegation: some ISPs have hundreds of networks and operate their own WHOIS. In that case, the best is to follow the link and to search for the information in the next database.

In the event there is no such delegation and no abuse contact, I usually go for the parent network, until I find an abuse contact.

Going to Justice

If the abuse costed you money or caused harm or damages, you may want to go to the police. In that event, the procedure depends on where you are and what jurisdiction applies. Contact your local authorities for more information.

In that case, it is important to preserve as much information as possible: if the abused machine is your desktop, don't use it anymore, disconnect it from the network and wait for instructions.

Happy Surging!

Sunday, March 4, 2012

How to protect your home wireless

Nowadays most, if not all, of the small routers provided to connect a DSL or Cable connection includes a wireless access-point. Developed to facilitate the connection of multiple devices, it also changed the security landscape by extending the area of reception.

With a wired network, it is easy: in order to connect to a network, you need a physical access to a port on a hub, a switch or a router. This limits the possibility for someone outside a house to connect: in order to do that, that person would have to run a cable, going through walls and concrete.

However, with a wireless network, those boundaries don't exist anymore: the radio waves can get through brick, walls, glass and wood and still be demodulated by a wireless card.As a result, some layers of protection are needed to prevent any undesired presence on a home wireless network.

First, what are the risks? Well, you have the risk that someone abuses your wireless network to commit some abuse on the Internet: visits to less than reputable web sites, downloads of protected material, spam, distribution of malware. The list is almost endless. In addition to that, someone on your internal network may also abuse your local resources, and for example abuse a network printer, access your files or plant a virus on your computer.

The first protection that was devised for wireless devices is WEP (Wired Equivalent Privacy). A key is entered on both the access-point and the network clients to allow the access. Unfortunately, a flaw was present in the design and can be exploited to "crack" a network and find the key.

All recent devices offer another mode, called WPA (Wi-Fi Protected Access), followed by WPA2. It avoids WEP's flaw by using  proven encryption algorithms, such as TKIP or AES. WPA/WPA2 requires a key shared between the access-point and the networked clients. That key, of course, needs to be robust and selected as a password: although it is tempting to use something easy, this also facilitates an intruder's job by making guesses based on a list of common words.

In addition to that, almost all devices offer a way to filter what devices connect to the network, based on its MAC address. This latter is the physical identity of a network card and is unique worldwide.

To do
  • Select WPA/WPA2 instead of WEP
  • Set a strong and secure password for the pre-shared key
  • (optional) Create a MAC filter and allow only your devices



Happy Surfing!