Find the answer to your Linux question:
Results 1 to 3 of 3
Dear Experts, I am reasonably new to the Linux networking. I am just wondering if the Linux networking stack records various attacks to the TCP/IP stack by itself. Does it ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Mar 2009
    Posts
    2

    Query: TCP/IP security logging capabilites


    Dear Experts,

    I am reasonably new to the Linux networking.

    I am just wondering if the Linux networking stack records various attacks to the TCP/IP stack by itself. Does it log errors for example corrupt TCP segments as a result of setting multilple TCP flags (the setting of both syn and rst etc). And where would such error, failed attempt log files be stored? (Ubuntu user)

    I am trying to figure out if various errors that arise within the TCP/IP stack could some how be used as guidance when designing for example firewall rules.

    Consider if an offending IP address is launching a DoS attack for example a FIN-WAIT-2 flood attack can the server have its TCP/IP stack log this?
    if this is the case then I can use various constraint reasoners and other nuts and bolts to automatically infer a set of dynamic firewall rules to mitigate/reduce attacks.

    I understand that iptables can protect the network by implementing various best practices but I am keen to know more about the logging facilities that the server TCP/IP stack can perform on its own. After all, its doing deep packet inspection (using this term loosely) as it decouples the packet, so I presume it has the mechanics to record failed attempts and so forth.

    Looking forward to your comments. I am still just getting my teeth into the issue.

    regards,
    Bill.

  2. #2
    Linux Newbie
    Join Date
    Feb 2009
    Location
    Third ring of Pergatory
    Posts
    199
    I'm not an expert but there is a tool in slackware called "ip" that gives you data from that 'deep packet inspection' and has a builtin monitor whose output can be redirected to a text file.
    From there you'd have to run a script to sift the file and implement your port states appropriately,
    Here's the output from "ip -s -s -r link show eth0" >> txt.file

    2: eth0: <BROADCAST,MULTICAST,NOTRAILERS,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether x..................x ff:ff:ff:ff:ff:ff
    RX: bytes packets errors dropped overrun mcast
    281551769 236202 0 0 0 0
    RX errors: length crc frame fifo missed
    0 0 0 0 0
    TX: bytes packets errors dropped carrier collsns
    21371053 169920 0 0 0 0
    TX errors: aborted fifo window heartbeat
    0 0 0 0

    Then there is always this can of worms.

  3. #3
    Just Joined!
    Join Date
    Mar 2009
    Posts
    2
    Yes it would appear that the Linux TCP/IP stack silently discards malformed packet headers and does not log these events (excuse my previous term of deep packet inpsection). Presumably to avoid a Log-DoS!

    I guess I was just hoping that end systems themselves could offer various network facts incurred on their own and then build protective rule sets and so forth to counter them. (A possible modification of the kernel seems to be required)

    One external solution that I already had in mind is to have the firewall or IDS up stream log packets that have non-compliant headers.

    I could then automatically reason over these logs and auto-configure a new set of firewall rules to mitigate threats to systems it protects.

    Of course if the server was running external TCP stack mechanims for example TCP-Wrapper or local iptables, snort, I could just interpret its failed log attempts and push the dropping of such bad packets up stream to the gateway firewall. Thus bringing about security-in-depth. (I am aware of snort-inline also)

    But that was not what I was thinking about as I wanted to know if *vanilla* tcp/ip stacks on servers or even end-client systems could be used in the guidance process. While they themselves would not have the semantic capability to understand the attacks, constructing a reasoner would and thus automatically configure the firewall.

    Once again, thanks for your input.
    Back the drawing board for me
    regards,
    Bill.

  4. $spacer_open
    $spacer_close

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •