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, but first I must see how to do it (the firewall logging), I have not any ideea so far, and with Wireshark, I suppose I must let the computer working for days, until I "receive" the custom salute from the outsiders.
Ah, ok, it's the LOG target, but where it is the info logged?
I think that without being set up (iptables log in syslogd and logrotate) it is logged by dmesg but within it's limits, I think. So, I must learn how to set up loging of iptables in syslogd and then logrotate. Maybe I am wrong but this is what I think.
BRW, is it appropriate or enough to see the current connections to my computer with "netstat -aut", or I need more options here?
Last edited by unSpawn; 12-13-2012 at 11:24 AM.
Reason: //Merge, NN
Turn on kernel logging of matching packets. When this option is set for a rule, the Linux kernel
will print some information on all matching packets (like most IP header fields) via the kernel
log (where it can be read with dmesg or syslogd(8)). This is a "non-terminating target", i.e. rule
traversal continues at the next rule. So if you want to LOG the packets you refuse, use two sepa-
rate rules with the same matching criteria, first using target LOG then DROP (or REJECT).
Originally Posted by mitusf
Maybe I am wrong but this is what I think.
After thinking and before posting it would be good to consult your documentation. What you wrote about only concerns you if you don't run syslogd and don't run a logrotate cron job.
Originally Posted by mitusf
is it appropriate or enough to see the current connections to my computer with "netstat -aut", or I need more options here?
Fastest way to display nfo with (networking) tool is to avoid any resolving. Often (ls, lsof, netstat, iptables, tcpdump, etc, etc) applications have "-n" switch for that. BTW, why would we need to see 'netstat' output?
Last edited by unSpawn; 12-13-2012 at 11:31 AM.
Reason: //More *is* more
Sincerely, I hope and I don't really believe that was compromised, but I think these were only tries to break in. This is my feeling, after a behavior analyze of the "attacks" in the server log, without knowing the server's internals.
unSpawn, thank you for your answer, it was really interesting, though I need more studying about the syntax call of tcpdump. Also, what means the -nn flag, I didn't find it in the man page, maybe I should try with info?
-nn Don't convert protocol and port numbers etc. to names either.
Come to think of it just
tcpdump -s 0 -i eth[devicenumber] -w /path/to/dump.pcap 'tcp-syn != 0 and dst port 80'
should do because you're logging to file.
I'm definitely not familiar enough with Linux shellcode to say whether that is part of valid shellcode, but the above are all very common instructions. As unSpawn was saying, it's hard to say much without more context...
Thank you very much OlRoy, your response opened to me a totally new and interesting perspective. Thanks!