I resolv the problem by disabled the snort rule in the bad-traffic.rules file but it doesn't explain what is this.
Well, let's try and dissect it then.
[1:528:3] The middle number is the SID or Snort ID and that will tell you which rule it tripped. All SIDS are unique. Knowing the SID you could for instance change the function from "alert" to "log" or even "pass". This is the actual rule: "alert ip any any <> 127.0.0.0/8 any (msg:"BAD-TRAFFIC loopback traffic"; classtype:bad-unknown; reference:url,rr.sans.org/firewall/egress.php; sid:528; rev:4;)". If you translate the important bits it reads "alert for IP traffic from any address with any port to and from this box with remote address any IP address in the 127.0.0.0/8 range".
BAD TRAFFIC loopback traffic the SID's alert string. Gives you a global idea what the alert is about. Note "loopback" doesn't refer to the actual loopback device, but to the 127 class A range. This traffic is supposed to be non-routable over public networks and so it could generally be classified as a spoof. Some ISP's seem to use the 10.0.0.0/8 range within their LAN's tho. Note you should block this in and outbound traffic and any other "private LAN" ranges from passing your public interface. But even if you do so and if you activated the rule, Snort will still catch it because it sees packets before Netfilter does.
[Classification: Potentially Bad Traffic] [Priority: 2] Generic classification of this traffic. Note it sez "potentially".
10/16-08:21:31.175096 127.0.0.1:80 -> "INTERNET_IP":PORT
Something on the loopback device on TCP/80 needs outbound public network traffic.
Note TCP/80 is designated as port for service HTTP. If this was a local server you would see access
TO port TCP/80, and it's response on an unprivileged port (anything over 1024, but dependent on /proc settings for unprivileged ports). NOT traffic FROM port TCP/80. Also since this is a port below 1024 this means effectively a service run by root. If you don't know what it is, then as root running "netstat -anp", "lsof -i | grep 80" or "fuser -n tcp 80" should tell you what's running. Another way, if you don't get it logged already, would be to log that traffic and look at the packets contents with Ethereal. In you snort.conf add this log definition and rule:
ruletype catchclassa
{
type log
output log_tcpdump: catchclassa.dmp
}
catchclassa ip any any <> 127.0.0.0/8 any (msg: "Catchall for 127 class A";)
Now you'll receive all traffic tripped by that rule in your configured snort log dir in the catchclassa.dmp tcpdump file...
TCP TTL:123 TOS:0x0 ID:42230 IpLen:20 DgmLen:40
***A*R** Seq: 0x0 Ack: 0x32A60001 Win: 0x0 TcpLen: 20
Time To Live value, Type Of Service, Packet unique ID, Packet IP section length, size of the whole packet or frame, TCP flags set, number in sequence, ACK sequence number, Window and Packet TCP section length. ACK(nowledge) and RST(reset) flags means it's part of a connection thats going to be torn down. One party sends RST, then your TCP/80 acknowledges the other parties wish sending ACK/RST back.
[Xref => http://rr.sans.org/firewall/egress.php]
An URI reference to background info. Not many people consider logging outbound rules and outbound traffic logging a must. Logging, outbound traffic means it can serve as an early warning system. Large volume outbound to for instance IRC or DDoS client ports could lead to investigating users and boxen for bouncers. Often crackers will use boxen for bragging or wars that way. Setting up outbound traffic ACL's is one way to help protect other networks from spoofed or malicious traffic. Gratuituous plug: I would like to add the Grsecurity(.net) kernel patches can help you enforcing network policies. It makes it easy to deny per UID setting up inbound or listening sockets for rogue servers and you can also deny outbound network access. If you have a separate account for compiling software, running an account under strict policies would have defeated for instance the trojan horse from the OpenSSH code breach instantly...
I use a re-connect script that ping some ip adress on internet to verify if my adsl connexion is already up. Maybe snort alert me about this but i am not very sure.
No, this alert was not generated for your ping script. We've been looking at TCP traffic, not ICMP.
chkrootkit doesn't find abnormal things on my system.
Excellent you checked, but adding a filesystem integrity checker like Aide, Samhain or tripwire would be a valuable addition. As seen in the past Chkrootkit will only react to threats it knows about and can find. For instance, if you run a 2.4.x kernel, it doesn't detect anything compiled with libpcap running the interface in promiscuous mode. See
http://www.linuxquestions.org/questi...threadid=67057 for details.
Running a filesystem integrity checker will show you changes on ALL files, and even if a system has been subverted already you can still run it from a rescue cdrom to find them files (provided you saved a copy of the binary and the databases on read-only media).
Be sure to check out the
LQ FAQ: Security references for docs on hardening your system.
Snort alert / Am i attacking ?
