Incoming and out Going Broadcasted network traffic

linxbee · 07-29-2021, 08:47 AM

This question is with reference to Linux OS.

Does Linux maintain any data structures or internal proc file system to store the incoming and outgoing bytes that are transmitted through broadcast method only.

I looked at /sys/class/net/<if>/.., but could not find any.

Is there any way to capture this info for every second so that , I can use them to calculate used bandwidth of any given interface.

computersavvy · 07-29-2021, 05:36 PM

The command ifconfig will display received and transmitted bytes and packets on each interface. Writing a simple script to poll those values will achieve what you want. There are also some tools available but I don't use them so don't have the details.

If you did a simple search for what you want you would find a lot of resources so you could choose what would work for your needs. We are not in the business of performing web searches for you.

dugan · 07-29-2021, 05:41 PM

Use sar.

linxbee · 08-03-2021, 09:53 PM

Quote:

Originally Posted by computersavvy

The command ifconfig will display received and transmitted bytes and packets on each interface. Writing a simple script to poll those values will achieve what you want. There are also some tools available but I don't use them so don't have the details.

If you did a simple search for what you want you would find a lot of resources so you could choose what would work for your needs. We are not in the business of performing web searches for you.

ifconfig is not really much helpful here, it displays only the broadcast address not actual statistics.

But I have found a way using tool called ethtool to display statistics

linxbee · 08-03-2021, 09:55 PM

Quote:

Originally Posted by dugan

Use sar.

I cannot use it because i need to bring it up for my machine which is not recommended for my case.

linxbee · 08-03-2021, 10:01 PM

I can get the statistics using ethtool:

Code:

$ ethtool -S eth0
NIC statistics:
     rx_packets: 40171178
     tx_packets: 36111432
     rx_bytes: 38029543322
     tx_bytes: 43785062291
     rx_broadcast: 1651523
     tx_broadcast: 13
     rx_multicast: 83759
     tx_multicast: 76

For broadcast and multicast it does not say its bytes or packets.

Can anyone let me know what are those values actually, packets or bytes?

allend · 08-04-2021, 12:37 AM

According to this, multicast is packets.
Broadcast statistics are not standard, dependent on the device driver.
There is a suggestion here that will show packets.

computersavvy · 08-04-2021, 09:19 AM

Quote:

Originally Posted by linxbee

ifconfig is not really much helpful here, it displays only the broadcast address not actual statistics.

But I have found a way using tool called ethtool to display statistics

Actually ifconfig does display communications quantity. See the part in bold here

Code:

wlp4s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.2.111  netmask 255.255.255.0  broadcast 192.168.2.255
        ether 68:1c:a2:06:2d:b2  txqueuelen 1000  (Ethernet)
        RX packets 9105811  bytes 8187490903 (7.6 GiB)
        RX errors 0  dropped 1  overruns 0  frame 0
        TX packets 4831071  bytes 1748974314 (1.6 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

True, it is a single value, not defined by time other than since the interface was last activated, but with readings taken at specified intervals (maybe in a database) it is easy to calculate the rate.

OTOH ethtool has many more features so good luck with it.

computersavvy · 08-04-2021, 09:30 AM

I really do not understand why you would be concerned with broadcast and multicast bits/bytes/packets since other than transmitted the machine has no control over that. Received and transmitted OTOH actually reflect the amount of data actually going over the interface.

While I don't remember the units for sure, I think it is packets. Those are packets that are generally received or transmitted when a device on the net needs to obtain an arp packet so it can send data directly to the target. Broadcast goes to all devices on the net, multicast goes to several but limited in scope.

linxbee · 08-04-2021, 12:53 PM

Quote:

Originally Posted by computersavvy

I really do not understand why you would be concerned with broadcast and multicast bits/bytes/packets since other than transmitted the machine has no control over that. Received and transmitted OTOH actually reflect the amount of data actually going over the interface.

While I don't remember the units for sure, I think it is packets. Those are packets that are generally received or transmitted when a device on the net needs to obtain an arp packet so it can send data directly to the target. Broadcast goes to all devices on the net, multicast goes to several but limited in scope.

We are actually setting some upper limit on each interface how much it should receive, exceeding that limit has to be handled so that we can detect broadcast storm or any other activity(which can be an attack etc..)

computersavvy · 08-04-2021, 06:22 PM

I understand what you are asking for, but it seems that should be related to a rate rather than an absolute top value received/sent. If a user transfers a large file but does not exceed the capacity of the network or interface in the speed at which it transfers then that may be OK. A flood of smaller packets that may be a lot less data but received in a very short time may overwhelm the ability of the interface to respond. That is really what you appear to be concerned about and you may have to track the rate for packets as well as data in order to handle it properly.

This is similar to the many ways that have been devised of identifying and handling a DDOS attack.

linxbee · 08-05-2021, 05:08 AM

Quote:

Originally Posted by computersavvy

I understand what you are asking for, but it seems that should be related to a rate rather than an absolute top value received/sent.

This is where we can read the values in certain time period (for every 5 sec or so) take the diff of previous and current bytes, then convert them to appropriate kB's/Mb's as required then match with whatever threshold value.

Is that not enough, pls comment, am really new to this.

computersavvy · 08-05-2021, 10:47 AM

That is what I anticipated according to your posts. There are a lot of already existing methods available. I found many with a search for "how to detect ddos attack" and "tools to detect ddos attack"

I have never played with it myself, but I think you really should set the trigger on packets and not on data (bytes) since as I mentioned earlier downloading a large file could transfer a lot of data in large packets in a short time but is in no way an attack. In fact, if the attacker is transferring a lot of data then you already have a broken system.

OTOH, most ddos attacks depend on overwhelming the ability of the system to respond to everything incoming so they use a flood of much smaller packets.

business_kid · 08-05-2021, 11:15 AM

Quote:

Originally Posted by computersavvy

OTOH, most ddos attacks depend on overwhelming the ability of the system to respond to everything incoming so they use a flood of much smaller packets.

The one DDoS "method" I got anywhere close to was a dos .bat file, which everybody on some irc channel ran simultaneously. It just pinged the chosen address. I forbade my kids using it.

computersavvy · 08-05-2021, 11:29 AM

Quote:

Originally Posted by business_kid

The one DDoS "method" I got anywhere close to was a dos .bat file, which everybody on some irc channel ran simultaneously. It just pinged the chosen address. I forbade my kids using it.

I remember that, called a "ping flood". I heard about it but refused to indulge, as you did. A normal ping waits for a response, a flood does not wait but sends out as fast as possible.

That is not even close to what is used today with all the bot nets (windows machines with back doors and trojans) that do the true distributed attacks by remote control from around the world and are capable of bringing down even massive systems.