The Poor Man's (or Woman's) Intrusion Detection System
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

README.md 6.2 KiB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162
  1. Poor Man's IDS
  2. ==============
  3. ### (Yes Women can use it too)
  4. The goal of this project is to keep an eye on the requests going in
  5. and out of my network onto the Internet (iNet). This is made
  6. necessary for two reasons:
  7. 1. By looking for unusual activity I can get a heads up about
  8. unwanted software or even "spy hardware" on my systems, ie.
  9. "Detect Intrusions".
  10. 2. Almost all software now days, especially those created by gigabuck
  11. giants, makes requests out onto the iNet that I did not ask for
  12. and don't want happening. But even Mozilla makes network traffic I
  13. didn't ask for and don't want.
  14. So this tool is my way of "watching the watchers". This is not a
  15. plug-n-play tool that _magically_ grants the user a "suit of
  16. invulnerability". But it is a tool for those looking for more insight
  17. into their iNet traffic either due to security concerns or curiosity.
  18. This software is in the very early stages. Right now it just combines
  19. data from logs from a couple of different software packages. I've
  20. already setup many blocks for traffic I don't want happening, like
  21. g00gle Analytics, some ad servers, ...
  22. For the curious I'll post my current block lists in this repository
  23. from time to time. But be **WARNED** that its likely to break your
  24. iNet experience if you use them. I'm a cyber-rebel at heart and tend
  25. to take an "if its doing something I don't want, I have no use for
  26. it" approach. Meaning I'd rather not use a site / program if it
  27. violates my concerns, rather than just "go with the flow". And I will
  28. likely discover I'm breaking stuff I actually want, like: I realized
  29. I've broken my ability to post comments on
  30. [HaD](https://hackaday.com/), but I was curious about what "Server X"
  31. did.
  32. So! If you're not "faint of heart" come join me on my adventure in
  33. iNet security exploration.
  34. Phase 1 - General Setup & Operation
  35. -----------------------------------
  36. In general I feel its necessary to have a **real-world** idea of what
  37. you're dealing with before diving in and writing software to deal
  38. with what you _think_ your dealing with. So the basic plan is simple:
  39. 1. Setup my network routing devices, which are running Linux, to log
  40. DNS queries and network connections. Specifically, anything that is
  41. a _new_ unrelated packet gets logged.
  42. 2. Collect the logs on a machine, with backups on alternate machines.
  43. 3. Run the logs through a filter to combine the DNS query data with
  44. the packet data.
  45. 4. Analyze results to determine phase 2 needs.
  46. In this phase I'm jumping the gun a bit, but cyber-thugs are actively
  47. beating on all of our doors, even as I'm getting my stuff together
  48. and there are certain kinds of traffic I know I want to put an end
  49. to. In that light I've already spotted interesting servers I'm
  50. blocking. And I've beefed up my firewall to my mail server with more
  51. permanent blocks from obvious MTA bashers.
  52. In this phase I'm using the most excellent
  53. "[dnsmasq](https://thekelleys.org.uk/dnsmasq/doc.html)" to log the
  54. queries **and** block host names I don't want being accessed. I do
  55. this by assigning the bogus address "127.0.0.255" to the names in my
  56. server's "hosts" file, which is used by "dnsmasq" to answer DNS
  57. queries. That address is a **valid** "localhost" address, so will
  58. **immediately** fail requests unless you put a http(s) server. And
  59. I'm sure you can imagine those possibilities.
  60. The other source of information and block capabilities is "iptables"
  61. / "ip6tables". I added rules to log "new" packets. The parsing
  62. software is what this repository is about right now.
  63. Note on routers
  64. ---------------
  65. I'm using Netgear appliances for WiFi and the first tier firewall
  66. connected to my iNet connection. Since a lot of modern ISP connection
  67. devices provide their own idea of security I have to turn off their
  68. firewall stuff and configure them in a transparent bridging
  69. configuration.
  70. I use Netgear because they actively provide tool chains for select
  71. models of their equipment and encourage people to load their own
  72. software mods on them. Have a look at
  73. [My Open Router](https://www.myopenrouter.com/). On my devices I
  74. have settled on [Shibby's Tomato](https://tomato.groov.pl/). Its very
  75. compact, extremely flexible and seems to have everything I've needed
  76. when I've needed it. As an example my dnsmasq & iptables setup for my
  77. gateway router required no changes to the firmware. I just put some
  78. of the lesser used config pages to use.
  79. The future
  80. ----------
  81. The goal is an active alert system. This system should provide
  82. immediate feedback on unknown connections allowing the user to either
  83. grant or deny access and maintain the appropriate block lists.
  84. But as "reality" exposes itself things are likely to change.
  85. The CODE
  86. --------
  87. I'm using C++ to write this. I'm targeting C++98 at this time.
  88. Although I think C++11 defines the minimum viable version of C++
  89. there are places that its still not available, which is most likely
  90. to happen with oddball tool chains like those provided by Netgear.
  91. But even my RaspberryPI 2B doesn't support it. Well... maybe with an
  92. OS upgrade... I'm hoping to support a very wide Linux platform
  93. coverage.
  94. I'm doing all of my development with Linux. It may be possible to do
  95. something similar, maybe with very little modification, on BSD based
  96. platforms. I don't have them and therefor won't be personally working
  97. on it. But, unless it makes things really ugly, I'm not opposed to
  98. contributions on that front.
  99. Installation & use
  100. ------------------
  101. This is still **VERY** crude and incomplete.
  102. 1. Configure the source: the basic setup is hardcoded in the source.
  103. I'm just testing right now. ;-) There are three lines near the
  104. bottom of "iptraffic.cpp" to be concerned with:
  105. * `#define PATH "/srv/backups/iptraffic"`: this is the base path
  106. to the work directory. Its prepended to other paths, read on.
  107. * `ifstream log(PATH "/test.log");`: defines the log file to
  108. process.
  109. * `ofstream out(PATH "/processed.log");`: the file with the
  110. combined data that's written out.
  111. * `config.load(PATH "/iptraffic.conf");`: Path to a configuration
  112. file that lists networks to consider as "us" and connections to
  113. ignore, basically the set that is considered "OK".
  114. 2. Type "make" to compile. Hopefully it compiles for you.
  115. 3. Run "iptraffic".
  116. 4. Check the output.