Tag: tw

I found different kinds of explanations about what Proxy ARP is, just few of them were understandable at first. After merging all of them this explanation came out of my networking workshop:

• Assuming that a router has an ARP entry of some IP address, if he receives an ARP request from somebody for that IP, the router will respond with its own MAC address.
• Proxy ARP is fairly simple technique for nodes to get MAC address of a destination host that is on a different subnet but on the same router. Same router different interface.

And this one to:

• If we have in the network one edge router that is our way out from the local LAN network. That router has Proxy ARP enabled by default. When it receives an ARP request on his interface for a client that is not actually from that local network it will try to be helpful and it will search his routing table if that network is locally connected on some other local interface. If he finds it, it will respond with his own MAC address to tell the source that he is the way to go towards that host.

If we look at the image below, I prepared a more detailed example for those who are still a bit confused about it.

It’s a technique that enables our R7 router on the image below to proxy ARP request from C1 computer which tries to find MAC address of computer C3.

You need to note that C1 has address from /16 range and that is why it thinks that 192.168.50.50 is on the same subnet as 192.168.1.11 . If that was not the case and C1 had the address 192.168.1.11/24, it would send the ARP asking what is MAC address of default gateway. It will go to default gateway because he will know that he is not directly connected to all of network 192.168.0.0/16. We are then talking about standard routing by getting the packets from one subnet to another using routing table examination.

This is really cool feature on Cisco router not usually mentioned until you dig a little deeper inside Cisco IOS. But first a bit of theory…

What is TCP SYN flood attack

TCP 3-way handshake

SYN flood DoS attack happens when many sources start to send a flood of TCP SYN packets usually with fake source IP.

This attack uses TCP 3-way handshake to reserve all server available resources with fake SYN requests not allowing legitimate users to establish connection to the server. SYN packet is the first step in TCP 3-way handshake. This is the step where client sends connection synchronization request to the server. Server receives TCP SYN from client, the server replies back with SYN ACK. SYN ACK acknowledges synchronization request.

In that moment server is waiting the client to complete the handshake by sending an ACK back to server to acknowledge the SYN ACK. With this third step, TCP session is successfully established and communication between server and client begins.

If the ACK is not received from the client side, server will wait for it for some time and then the session will timeout and get dropped. When the server deletes the session, his resources will be released.

TCP SYN flood attack

TCP SYN flood attack sends first packet of 3-way handshake SYN packet to server many times to cause the server to allocate resources for sessions that will never become established. It means that client who is attacking will never respond to server SYN ACK and the session will remain on the second step of 3-way.

Network Packet Generator or Network Traffic Generator is a tool every network engineer will sooner or later want to use. Here’s one I found and it’s great!

First time I saw an Ethernet frame in details on my CCNA class back in 2010 I immediately got the idea about generating some packets on my own. It was logical next step to ask myself: “Ok, so how can I make one of those and see what happens when I send it out on the network?”. I was not really sure that there is a tool that would make it possible.

Don’t get me wrong, net surfers don’t need this!

I mean, Yeah, ok, I know I am generating a lot of packets right now by not doing anything because my Mac is surely syncing who knows what across the Internet. The thing is, you are not really in control of your machine’s applications network layer which is talking across the network, so you can not really make much changes in frames header format and whats inside headers. Apps are sending out standard packets with standardised header format (flags, addresses etc.). The thing that we control is only the data that we send, the payload of those packets, headers, they do their thing to make the transfer possible.

You can control the packet source IP address of course, maybe MAC address sometimes on some Linux machines by editing your NIC configuration but I am sure you know that if you are still here 🙂

Network engineers do need this!

But I am a network engineer and I usually want:

• to test something
• make something that does not exist so far or is not standardised.
• I want to try to create a new protocol that will talk using IP.
• I want to change protocol implementation bugs from some vendor.
• I need a way to create test packets to investigate strange firewall packet drops.
• I want to see what will happen if some packets header flags are changed in strange way, how will that affect the packet forwarding.
• I want to send stuff across the network and see what happens.
• I need other stuff too.

Flowing text is a project done as a part of academic work that I am involved with for last few years at the University of Rijeka – Department of Informatics. It’s a short overview at latest achievements in the field of network automation with some lab experiments done to test different paths across the network. The work was presented at 6th International Conference on Information Technologies and Information Society (ITIS2014).

The scope of ITIS events are the applications of IT, particularly in social sciences. The conference also covers a wider range of topics related to IT and computational modeling and analysis, in the context of our Creative Core project “Simulations” and our Research Program “Complex networks”. These include cloud computing, complex systems and complex networks, bioinformatics, graph theory and optimization, statistical analysis, business and industrial processes, logistics, information systems and security.

Okaj, let’s go…

Authors

dr. sc. Božidar Kovačić & mag.edu.inf Valter Popeškić (me)
University of Rijeka – Department of Informatics

If your LAN is extending to some places where unauthorised people can just plug in and gain access to your protected network, it’s time to implement some security on your access switch. The best thing to do is to implement IEEE 802.1X port-based authentication which will enable users/machine authentication and prevent unauthorized devices from getting access switch port running when connected. IEEE 802.1X port-based authentication is mostly called simply as dot1x.

In this article I will show you how to configure some basic dot1x stuff on switch side. I will also include Windows machine side of configuration as this is something most people presume it’s working out-of-the-box but of course that’s not the case. Radius server policy is fairly simple so a screenshot of the policy will get you going. So as you see, to get dot1x running you need to configure: