what is Botnet ?

 

A botnet is a network of compromised computers or devices, often referred to as "bots" or "zombies," that are controlled remotely by a malicious actor (known as a "botmaster"). These devices are typically infected with malware, allowing the botmaster to execute various commands on them without the device owner’s knowledge.

Here are some common uses and dangers of botnets:

1. Distributed Denial of Service (DDoS) Attacks: Botnets are often used to flood a target server or website with traffic, overwhelming it and causing it to crash or become unavailable to users.

2. Spam Distribution: They can be used to send out massive amounts of spam emails or phishing messages, which can lead to further infections or fraud.

3. Credential Stuffing: Botnets may attempt to use stolen usernames and passwords on different sites, automating the process to try many combinations quickly.

物聯網應用層通訊協定標準比較 CoAP vs MQTT

機器對機器 (Machine-to-Machine， M2M)通訊是物聯網的一個重要運作概念。隨著物聯網的應用日益興盛，M2M流量會持續增加，故針對M2M Traffic特徵及其應用，M2M通訊技術應運而生。由於物聯網架構下，感測節點本身多半採用MCU且以電池供電，故這些新的M2M協定必須考量在有限的硬體能力及功耗等條件下，使得M2M Traffic在進行網路傳輸時，有較高的Throughput、低延遲、低電力耗損，甚至提供不同的 QoS (Quality of Service)。

目前各家提供連結物聯網裝置的雲端資料服務平台，包含
AWS IoT(https://aws.amazon.com/tw/iot/)、Evrythng(https://evrythng.com/)、Xively(https://www.xively.com/)、ThingSpeak(https://thingspeak.com/)、ThingWorx(https://www.thingworx.com/)等及晶片廠提供的雲平台，如聯發科的MCS(https://mcs.mediatek.com/)、ARM mbed Device Connector(https://connector.mbed.com/)等，都廣泛支援CoAP及MQTT協定，故將選擇此兩種協定來進行說明與比較。

M2M協定介紹

CoAP

CoAP(The Constrained Application Protocol) 目前已是IETF標準(RFC 7252) ，提出一個類似HTTP/TCP設計，但是屬於輕量版的HTTP/UDP，使得其有利於感測節點進行網路傳輸。

CoAP主要特點:

1. CoAP同HTTP一樣具有REST(Representational State Transfer)設計風格，也支援GET/PUT/POST/DELETE及URIs的請求方式。
2. CoAP是主從(Client/Server)架構，感測節點多半為CoAP Client 上傳(PUT)感測資訊或節點狀態到CoAP Server。CoAP Server使用UDP (port: 5683)，對於資料是否要重傳或傳送順序(Reordering) 全交由上層應用層來決定，對於資源有限的MCU則不需要TCP協定實作。感測節點多半為CoAP Client, 因為感測節點通常是On-Off (Duty-cycled)工作模式, 只有醒來時才工作以節省能耗。若反過感測節點為CoAP Server, 則由Cloud 作為CoAP Client , 執行Get 以存取節點狀態資訊。
3. CoAP採用二進位整數格式且封包標頭4 個byte而非HTTP使用字串格式(ASCII code)，所以封包傳送時的額外負擔小且不必像HTTP一樣得進行耗時的字串解析處理。
4. CoAP QoS : CoAP訊息分為Confirmable或Non-Confirmable。Confirmable要求接收端須回送ACK，若沒有收到ACK則重送一次。若送的是Non-Confirmable訊息，則送出端不在乎接收端是否收到。
5. CoAP使用DTLS (Datagram Transport Layer Security) 進行加密
6. 通知機制: CoAP擴展了HTTP GET，加入了一個observe flag，用來主動回報所observe到的狀態，而不必像原本HTTP需要一直polling,如此可節省不必要的通訊。實作上MCU 為CoAP Client, 一旦狀態改變時主動發出CoAP GET 即可將資料丟到server
7. NAT Issue: 若感測節點在NAT後方，則必須一開始先送出請求到外部，使路由器可以接受來自外面CoAP Client的請求， 例如請求資源清單。

MQTT

MQTT（Message Queuing Telemetry Transport）是IBM開發的一個即時通訊協定，2010年IBM釋出免授權版本(v3.1)。MQTT是機器對機器（M2M）物聯網的連接協定。它被設計成一個非常輕量級的發布/訂閱消息傳輸。對於感測節點擁有很少的記憶體和或網路頻寬很小的情況下， MQTT非常適合。MQTT已經是ISO（ISO / IEC 20922：2016）和OASIS標準。另外，Facebook Messenger即是採用MQTT協定。

MQTT的主要特點:

1. 訊息傳遞為Publish/Subscribe的方式，以提供一對多的訊息分派

1. Client B及Client C先向Broker訂閱(Subscribe)一個Temperature主題, 而Client A向Broker發佈(Publish)在該主題Temperature發佈訊息(22.5)，則Client B及Client C 都會收到此訊息。 

1. 使用TCP port 1883作為通訊傳輸層 
2.  Header固定長度為2 byte，因此可以減少封包傳送時的額外負載，並減少所需的網路頻寬 
3. Publish 和Broker 中間發生異常斷線時，會使用最後遺囑(Last Will )的機制，通知所有Subscriber 
4. 3種傳送服務QoS (0,1,2)：

   Publisher <----> Broker <----> Subscriber

                  <QoS>           <QoS>

兩段所設定的QoS ，其作用的結果取兩段最小QoS值

1.)   QoS=0   "At most once": 最多送一次 ,但可能沒收到，"Fire and Forget"

•      Publisher不會Re-Publish訊息給Broker。因為使用底層是TCP, 所以Broker 一定會收到，而剩下的問題為 Broker 和Subscriber 兩者間的傳輸問題。

•      這適合應用在環境感測， Subscriber並不會在意Publisher是否會再重送，因為下一次的資料取樣很快就會再丟出來

2.)   QoS=1   "At least once": 可能收到一次以上 >=1

•      如果時間內Publisher沒收到來自Broker的PUBACK, Publisher會Re-Publish訊息。如此Broker很有能收到2次以的重覆的訊息，因此Subscriber 就可能跟著會重覆收到相同訊息。

3.)   QoS=2   "Exactly once":只會收到一次=1。

•     為避免像QoS 1,  Subscriber有可能收到重覆的訊息。因此Publisher 會有Message ID, 使得Broker 能夠判別這是Publisher 所送的重覆資料, 才不致於送給Subscriber重複的資料。

•      這適合用在計費系統，系統只要有重複收到資料、或是資料遺失狀況發生，就會造成系統錯誤。

CoAP vs MQTT 比較

1. 都是公開標準且都是基於IP層的協定 
2. 封包標頭小且採用binary格式 
3. CoAP屬於一對一通訊，MQTT則是多對多 
4. 若考慮感測節點在NAT後方的情況，由於MQTT的架構因為有中央broker的角色，MQTT Client本來就持續連接在broker，所以可以直接推播訊息，沒有NAT問題。然而CoAP Client要取得位於NAT後方的感測節點資料，則須要在路由器上設上設定virtual server或port forwarding之類才能使用，不然就必須另外有第三方伺服器存在，讓感測節點先連出才行

Raspberry Pico W 使用 MQTT publish

References:

 

Observing Resources in the Constrained Application Protocol (CoAP)


 

Socket Option : TCP_NODELAY

Linux Socket Option : TCP_NODELAY

int init_socket(mqtt_broker_handle_t* broker, const char* hostname, short port, int keepalive)
{
int flag = 1;

// Create the socket
if((socket_id = socket(PF_INET, SOCK_STREAM, 0)) < 0)
return -1;

// Disable Nagle Algorithm
if (setsockopt(socket_id, IPPROTO_TCP, TCP_NODELAY, (char*)&flag, sizeof(flag)) < 0)
return -2;

struct sockaddr_in socket_address;
// Create the stuff we need to connect
socket_address.sin_family = AF_INET;
socket_address.sin_port = htons(port);
socket_address.sin_addr.s_addr = inet_addr(hostname);

// Connect the socket
if((connect(socket_id, (struct sockaddr*)&socket_address, sizeof(socket_address))) < 0)
return -1;

// MQTT stuffs
mqtt_set_alive(broker, keepalive);
broker->socket_info = (void*)&socket_id;
broker->send = send_packet;

return 0;
}

Disable Nagle Algorithm: 　
為了提升TCP傳送效率, 不要送一點資料就送出一個TCP/IP封包, 若只送1 byte , 先不看MAC層header 光TCP+IP Header 就有40byte了, overhead 太大, 所以Nagle 這個人, 就提一個方法, 累積一定的大小才送..

if there is new data to send
  if the window size >= MSS and available data is >= MSS
    send complete MSS segment now
  else
    if there is unconfirmed data still in the pipe
      enqueue data in the buffer until an acknowledge is received
    else
      send data immediately
    end if
  end if
end if

TCP RTO計算方式

When TCP sends a segment it maintains a timer, waiting for the other end to acknowledge reception of the segment. If an acknowledgment isn't received in time, the segment is retransmitted.

這個timer 就是RTO (Retransmission TimeOut) ,它的時間並不是固定的, 而是依當下的網路擁塞程度做動態的調整。


To compute the current RTO, a TCP sender maintains two state variables, SRTT (smoothed round-trip time) and RTTVAR (round-trip time variation).

init : RTO=3 秒

1) 取得第一個RTT後, RTO 計算如下

SRTT <- R

RTTVAR <- R/2 

RTO <- SRTT + max (G, K*RTTVAR)

其中 K = 4 , clock granularity of G seconds. (G: 100ms~500ms )

2) 之後每收到一個RTT,  RTO 計算如下

RTTVAR <- (1 - beta) * RTTVAR + beta * |SRTT - R'|
SRTT <- (1 - alpha) * SRTT + alpha * R'
RTO <- SRTT + max( G, K * RTTVAR )
其中 alpha = 1/8, beta = 1/4,
若 RTO小於1s, 則進位至1秒

When segment 4 is transmitted 2.4 ms later, it cannot be timed, since the timer for this connection is already in use. 

1. 在TCP中，同一時間下只能處理一個 RTT 的量測程序。
2. Retransmission Timer只有一組
3. 有重送(retransmit)過的封包的RTT不可以拿來計算, 因為沒有辦法知道所收到的確認封包(Ack) 第一次送出的封包回覆的還是重送的封包回覆的

https://tools.ietf.org/html/rfc2988

   (5.1) Every time a packet containing data is sent (including a
         retransmission), if the timer is not running, start it running
         so that it will expire after RTO seconds (for the current value
         of RTO).

         每次送出封包,若當時timer沒啓動,則要啓動

   (5.2) When all outstanding data has been acknowledged, turn off the
         retransmission timer.

         若送出的全都封包, 已全部都有ACK回來, 關閉 timer
(5.3) When an ACK is received that acknowledges new data, restart the
         retransmission timer so that it will expire after RTO seconds
         (for the current value of RTO).

        若有ACK回來是回應新封包 (即非dup ACK), 則 timer須更新,使得再經過RTO秒後會發生timeout

   When the retransmission timer expires, do the following:

   (5.4) Retransmit the earliest segment that has not been acknowledged
         by the TCP receiver.

        timeout 發生了, 把Window還沒被ACK的(Outstanding Packet)全部重送

            

   (5.5) The host MUST set RTO <- RTO * 2 ("back off the timer").  The
         maximum value discussed in (2.5) above may be used to provide an
         upper bound to this doubling operation.

          把RTO乘以2 (RTO <- RTO * 2 )

   (5.6) Start the retransmission timer, such that it expires after RTO
         seconds (for the value of RTO after the doubling operation
         outlined in 5.5).

      timer再重新啓動,使得再經過RTO秒後會發生timeout

例子, 

當SYN區段傳送出去時，RTTM、RTTS、及 RTTD 尚未有值，而 RTO 的值被設定為 3 秒。

2.當SYN+ACK區段抵達，其 R 被量測後為 1.5 秒，其變數的值如下所示：


R = 1.5

SRTT = 1.5
RTTVAR = 1.5 / 2 = 0.75 

RTO = 1.5 + 4 . 0.75 = 4.5

3.當第一個資料區段傳送出去時，一個新的 RTT 量測程序被啟動。請注意，當傳送端傳送ACK區段時並不會啟動 RTT 量測程序，因為它不會消耗序號也不會啟動計時器。第二個資料區段也不會啟動 RTT 量測程序，因為已經有一個量測程序正在進行中。最後一個ACK區段的抵達被用來計算下一個 RTTM 的值。儘管最後一個ACK區段是用來回應兩個資料區段 ( 累計式 )，它的抵達完成了第一個區段之R的值。其變數的值如下所示：


RTT = 2.5
SRTT = 7/8 (1.5) + 1/8 (2.5) = 1.625
RTTVAR = 3/4 (0.75) + 1/4 |1.625 − 2.5| = 0.78
RTO = 1.625 + 4 (0.78) = 4.74