Linuxでのファイアウォールの作成とテスト、パート2.2。 ファイアウォールテーブル。 TCP \ IP構造へのアクセス

最初の部分の内容：





2番目の部分の内容：



2.1-2番目のパートの紹介。 ネットワークとプロトコルを調べます。 Wireshark

2.2-ファイアウォールテーブル。 トランスポート層 構造TCP、UDP。 ファイアウォールを拡張します。

2.3-機能を拡張します。 ユーザー空間でデータを処理します。 libnetfilter_queue。

2.4-ボーナス。 実際のバッファオーバーフロー攻撃を調査し、ファイアウォールで防止します。

ファイアウォールルール。 理論

このパートでは、単純なファイアウォールを実装するのに十分な基礎の研究をほぼ終了しますが、これを行う前に（読者がネットワークの知識があるか、パート2.1を読んでいると仮定します）、ファイアウォールがどのように決定を下すかを考慮する必要があります。











このようなルールテーブルは、ユーザー（管理者）によってファイアウォールメモリに読み込まれます。 パケットを受信するとき、パケットをどう処理するかを決定するのは、受け入れ者または拒否者です。



重要！ ファイアウォールはパケットを受信すると、必ずそのフィールド（レッスン2.1で行ったこと）を見て、それらを順番にテーブルのルールと比較します（！）これらのルールが書き込まれているように（上から下に！） 言い換えると、上の表にあるルールとそれより低いルールの根本的な違いがあります。



重要！ 奇妙なパッケージは、私たちによって保護されているネットワークやデバイスに侵入してはいけません。 さらに、スキップできるかどうかわからない場合、答えはNOです。 ファイアウォールルールで許可されているパケットのみを許可します。



したがって、ファイアウォールの構築と運用の原則：許可されたパケットのみが内部ネットワークに到達できます（また、そうする必要があります）（host1があります）。



今、例えば。 上記の表は、5つのルールを定義しています。 各パッケージを受け取ったら、適切なルールが見つかり、 Actionが記述されている場合にのみ-acceptを確認してから、スキップします。 それぞれをチェックした後に適切なルールが見つからなかった場合、そのコンテンツに関係なくパッケージを破棄します。 これを行うには、定義する最後のデフォルトルールがあります-ルールのいずれにも該当しないパッケージはすべて捨てます。 最後になければなりません（実際、登録されていなくても、すべてのファイアウォールが自動的に追加します）。



次に、 方向とackフィールドについて詳しく説明します。



方向 -パケットがネットワークに入るか出るかを決定します。 たとえば、電子メールによる情報漏えいを避けるために、すべてのsmtp（メール）プロトコルパケットをブロックすることができます。 またはその逆-telnetプロトコルを使用して着信パケットを禁止し、ネットワークへの接続を禁止します。 実際の部分では、この場合、コード内のパケットの方向を決定する方法を検討します。



最初の2つのルールはspoofと呼ばれ、ささいな攻撃の試みに対してささいな保護を提供します。 したがって、 spoof1は「ポート番号、プロトコルなどのネットワークのアドレス（10.0.1.1 = host1）を持つすべての着信パケット（ direction = in ）」を意味します。 -捨ててください。」 このルールのロジックは、パケットがファイアウォール上のネットワークに到達できないことであり、ネットワークから送信されたことを示します（ src ip = 10.0.1.1 ）。 言い換えれば、これは誰かがそれを偽造し、ユーザー（この場合はhost1）の1人として自分自身を偽装しようとしていることを意味します。このようなパッケージをスキップしたくないのです。



対称ルールとspoof2-元々内部アドレスとは異なるIP（つまり10.0.1.1ではない ）であると言われている場合、内部ネットワークからパケットをリリースしたくない。 ほとんどの場合、これも何らかのウイルスです。



ACKは、TCPプロトコルの使用時に接続を確立し、その「信頼性」をさらに維持するために使用されるフラグ（1ビット）です。 各TCP接続はトリプルハンドシェイクで始まります（3ウェイハンドシェイク、ロシア語の記事はありませんが、英語のアニメーションはここにあります： https : //en.wikipedia.org/wiki/Handshaking#TCP_three-way_handshake



TCPセッションを開くたびに、最初のパケットACK = 0でのみ、作成されたセッションACK> 0（ https://ru.wikipedia.org/wiki/TCP ）の他のすべてのパケットでのみ理解することが重要です。



このため、既存の接続を開こうとする試みと区別できます。 ACK = 0の場合、これはTCP接続（トリプルハンドシェイクの最初のパケット）を作成しようとする試みであり、ACK = 1の場合、接続は以前に作成されている必要があります（そうでない場合、そのようなパケットがネットワークに到達しないようにするのは論理的です）。



次に、 http_in 、 http_outルールを見てください：







http_inは次を意味します：パケットが着信する場合（ 方向 = in ）、任意のIPから（ Src IP = any 、この段階で、上記のスプーフィングルールは、これが内部ネットワークのIPではないことを保証することに注意してください） Dest IP == host1 == 10.0.1.1 ）、TCP経由でポート80（つまり、誰もが知っているhttpサーバー）に任意のポートから送信（> 1023は、接続の作成時にオペレーティングシステムから受信する予約されていないポートを示します）将来、パート2.1）で説明されているように、この特定の化合物を識別するために使用されます。Ack= Any。 外部からコンピューターに接続を開くように要求することにします（最初のパケットack = 0、次のack> 0）。 そして、このようなパケットを受け入れて、さらにネットワークに渡します（ action = accept ）。



http_outは対称的です。ただし、ack = 0、ack> 0のみのパケットを見逃すことはありません。つまり、コンピューターからインターネットへのhttp接続を作成することはできませんが、既に作成されたhttp接続には応答できます。



つまり、httpルールは、外部からhttpを介したネットワークへのアクセスを許可しますが、ネットワークのユーザーがhttpを使用すること（つまり、インターネットサイトへのアクセス）を禁止します。

ファイアウォールルール。 練習。

モジュールに戻ると、インターセプト関数は次のようになります。

unsigned int hook_func_forward(unsigned int hooknum, struct sk_buff *skb, const struct net_device *in, const struct net_device *out, int (*okfn)(struct sk_buff *));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

オプションを見てみましょう：



hooknum-傍受の数、すでに渡しました

const struct net_device * in、out-ネットワークインターフェイス構造へのポインター

struct sk_buff * skb-私たちにとって最も興味深いのは、必要なデータを含むポインターです

SKB-ソケットバッファ 。これはLinuxネットワークの基本構造です。 これには多くのフィールドがあり、記事を書くための別の主題になります。 もっと深くしたい人のためにいくつかの良いリンクを見つけました。



http://vger.kernel.org/~davem/skb.html

https://people.cs.clemson.edu/~westall/853/notes/skbuff.pdf



興味があるのは：

 union { struct tcphdr *th; struct udphdr *uh; struct icmphdr *icmph; struct igmphdr *igmph; struct iphdr *ipiph; struct ipv6hdr *ipv6h; unsigned char *raw; } h; // Transport header union { struct iphdr *iph; struct ipv6hdr *ipv6h; struct arphdr *arph; unsigned char *raw; } nh; // Network header
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次のように

 struct iphdr *ip_header = (struct iphdr *)skb_network_header(skb);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

IPヘッダーへのポインターを取得します（パート2.1では、このレベルでの主な情報はIPソース 、 IP宛先であると述べました）。



inclue / linux / skbuff.hからのSkb_network_header定義







http://lxr.free-electrons.com/source/include/linux/skbuff.h?v=3.0#L1282



つまり、関数がskbuff構造体の 「正しい」場所から目的のポインターを返すことがわかります。



IPヘッダーにアクセスできるようになったので、IPアドレスを取得できます。

 unsigned int src_ip = (unsigned int)ip_header->saddr; unsigned int dest_ip = (unsigned int)ip_header->daddr;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、プロトコル番号：



ip_header->プロトコル

トランスポート層へのアクセス（TCP / UDP ..）

 struct udphdr *udp_header = (struct udphdr *)(skb_transport_header(skb)+20); struct tcphdr *tcp_header = (struct tcphdr *)(skb_transport_header(skb)+20);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

TCP（および同様にUDP）ポート番号の場合：

 unsigned int src_port = (unsigned int)ntohs(tcp_header->source); unsigned int dest_port = (unsigned int)ntohs(tcp_header->dest);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

以下に、完全な機能コードを示します。 興味深い点は、 ntohs関数を使用することです。 ntohsは、ビット（数値を表す）の順序を変更する関数です。 使用されるメモリ内の数値の表現には、 リトルエンディアンとビッグエンディアンの 2種類があります。 ネットワークはビッグエンディアンシステムを使用して数値を表し、Intel リトルエンディアンアーキテクチャ（バイト順）

したがって、正しい数値を取得するには、これらの変換関数を使用する必要があります。

以下は機能全体のテキストです。パケットを受信すると、ファイアウォールルールに従って決定を下すために必要なすべてのデータを印刷します。

 unsigned int hook_func_forward(unsigned int hooknum, struct sk_buff *skb, const struct net_device *in, const struct net_device *out, int (*okfn)(struct sk_buff *)) { struct iphdr *ip_header = (struct iphdr *)skb_network_header(skb); struct udphdr *udp_header = NULL; struct tcphdr *tcp_header = NULL; unsigned int src_ip = (unsigned int)ip_header->saddr; unsigned int dest_ip = (unsigned int)ip_header->daddr; unsigned int src_port = 0; unsigned int dest_port = 0; char src_ip_str[16], dest_ip_str[16]; if(ip_header->protocol == PROT_UDP) { udp_header = (struct udphdr *)(skb_transport_header(skb)+20); src_port = (unsigned int)ntohs(udp_header->source); dest_port = (unsigned int)ntohs(udp_header->dest); } else if(ip_header->protocol == PROT_TCP) { tcp_header = (struct tcphdr *)(skb_transport_header(skb)+20); src_port = (unsigned int)ntohs(tcp_header->source); dest_port = (unsigned int)ntohs(tcp_header->dest); // XMAS packet // FIN, URG, PSH set // if(ip_header->protocol == PROT_TCP){ // printk("TCP ack = %s\n", tcp_header->ack == 1 ? "yes" : "no"); // if (tcp_header->fin > 0 && tcp_header->urg > 0 && tcp_header->psh > 0 ){ // info("XMAS packet detected, drop"); // } } ip_hl_to_str(ntohl(src_ip), src_ip_str); ip_hl_to_str(ntohl(dest_ip), dest_ip_str); printk("---------------------------\n"); printk("in device = [%s], out_device = [%s]\n", in->name, out->name); printk("ip_src = [%s], ip_dest = [%s]\n", src_ip_str, dest_ip_str); printk("src port: [%u], dest port: %u, \n", src_port, dest_port); printk("protocol = %d\n", ip_header->protocol); if(dest_port == HTTP_PORT || src_port == HTTP_PORT){ printk("HTTP packet\n"); } return NF_ACCEPT; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コンパイル中

モジュールの作成またはnetfilterの使用のほとんど（すべてではないにしても）の例は、1つのソースファイルと数十行のコードに制限されています。 ただし、大規模なプロジェクトは、単一のソースファイルに収めることができません（また、誤って）。 説明している例は1つのファイルに詰め込むことができますが、それをmodule_fw.c-charデバイス、sysfs、カーネルモジュール、およびhook_functions.cに関するすべて-インターセプト機能に分割することにしました。 複数のファイルで構成されるカーネルモジュールをコンパイルする場合、知っておく必要がある小さなトリックがあります。以下に例を示します。







ここでは、行に注意を払う価値があります。



obj-m：= fw.o

そのようなfw.cファイルはないため、これは作成されるモジュールの名前です。 また、これは、モジュールに関連するすべてのファイルを説明する次の行のプレフィックスです

fw-objs + =

もちろん、モジュールの名前とソースコードが一致してはならないことを知っておく必要があります。 それ以外の場合、すべてが同じままです。

確認する

検証のために、 dhcpインターフェイスをすばやく構成し（パート1を参照）、host1にapache2をインストールし、host2のtext2にlynxをインストールしました（ただし、telnetは不要です）。 打ち上げ



リンクス10.0.1.1







ファイアウォールが生成するものを確認します。







まあ、それだけです。

おわりに

このパートでは、ネットワーク上のトラフィックを保護および渡すためのポリシーを決定する、ファイアウォールのルールテーブルがどのように機能するかを調べました。 その後、Linuxでskbufの基本的なネットワーク構造の1つを分解し、このおかげで、プログラムを補完して、モジュールのテーブルサポートを補完することができました。 あとは、パート1で行ったように、sysfsを介してこのテーブルのダウンロードを記述し、 if {} else if {} else {} ... hook_func_forward関数に追加します。 ここには根本的に新しいものはないので、皆さんにお任せします... klistでのみ作業するかもしれませんが、これは完全に異なるトピックであり、インターネットでも十分に取り上げられています。



関数自体で、XMASパケットとして指定されたボーナスを見つけ、それが何であり、なぜインターネット上で読めるか、次のパートでは2つを開始します（「ここ」ですか？）-

 if(dest_port == HTTP_PORT || src_port == HTTP_PORT){ printk("HTTP packet\n"); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

参照：

wikipedia.org/wiki/Handshaking#TCP_three-way_handshake

en.wikipedia.org/wiki/TCP

vger.kernel.org/~davem/skb.html

people.cs.clemson.edu/~westall/853/notes/skbuff.pdf

lxr.free-electrons.com/source/include/linux/skbuff.h?v=3.0#L1282

バイトオーダー