Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
yes, I'm serious, according to me, the netfilter code in linux (2.4.18 - patched ipt_ULOG.c as well as 2.5.69 - and therefor likely 2.5.72 as well) loses packets under some circumstances. Yes, I felt the same way, ok, here it goes, I flush my tables, and set all policies to accept, and then add some logging and some denying (We're writing a portknock server and is trying to tap into the ULOG target in order to pick up the knocks).
Anyway, I feel extremely stupid. The iptables commands are fine, so is my ulogport program (although it seems weird). After using hping to perform a sequenced knock I realized that the problem was in the client code. When a socket times out, it's ripped to threads in the kernel, although not as expected. Executing a successive connect on the same sockets fails, but it doesn't fail with EBADFS, but rather with one of ETIMEOUT ECONNREFUSED or EINTR (I suspect ECONNREFUSED as it seems to be attempting to reconnect to the same ports). Anyway, I modified the client to use a clean socket for each connect system call and it now works as expected.
You can easily help, I'm publishing my code (http://www.kroon.co.za/ulogport), and yes, it is of my own design. It sucks atm, all it can do is check that the packet was a tcp packet, and if so, what the source ip was and the destination port, it prints this out. The only reason I wrote it in the first place was to work with my portknock program (http://www.kroon.co.za/portknock) which can be configured to do all kinds of really wicked stuff. I'm actually still looking for beta testers (hint hint).
And I suspect what I call portknocking is something else from what you understand? portknocking is when some packets are sent to your ip stack to test it, hack it, etc (or at least that is what I understand). We are using it as a method of passing data through a firewall, or rather, to give commands to the firewall from a remote location. So far we have managed to configure it to open ssh for us to a given ip without having access to the server.
Well, actually, for that specific tryout I merely constructed a simple syn-blocking firewall, and logged some SYN packets to ULOG which I picked up as the knocks. Then I send a specific sequence of knocks, which the server then picks up, and takes appropriate action (opening ssh in this case).