My curiosity is getting to me.....

Ok.... Let's see if you talented guys and gals can come up with a potential reason for what I am seeing but cannot fathom the "why"......

I keep seeing blocks, not large - maybe 8-30 events in rapid succession - from private subnet addresses at my firewall. They are usually directed at the firewall though sometimes they go to my web server - they are dropped at the firewall so they aren't a cause for concern but I'm curious as to what is going on and can't grasp any reason whatsoever for these packets.

Sometimes the source IP will change slightly during the whole event so one that starts out 10.1.1.1 will flip to 10.1.1.2 for example and sometimes back again during the event - implying to me that this is randomly generated to try to avoid detection by rotating the IP address. They are usually TCP but there is a smattering of UDP, (see second example). Where the packets are SYN/ACK there are no corresponding outbound SYN's and they wouldn't go anyway, (firewall drops them - blocked site) - to me this implies the SYN/ACK is crafted as is the FIN/PSH/ACK in the third example because the session could never have been created in the first place to allow any legitimate PSH packet situation to occur. The source and destination ports are also of interest in that they usually remain exactly the same during an event even though the IP may change. They are often well known numbers for source and destination, (a little unusual), and they are almost always a well known port as the source.

11/11/02 15:29 firewalld[137]: deny in eth0 44 tcp 20 50 172.16.6.23 XXX.XX.XXX.XXX 8080 32788 syn ack (blocked site)

11/11/02 15:19 firewalld[137]: deny in eth0 78 udp 20 119 10.0.0.2 XXX.XX.XXX.X 137 137 (blocked site)

11/11/02 17:58 firewalld[137]: deny in eth0 59 tcp 20 113 10.250.14.14 XXX.XX.XXX.XXX 80 14328 fin psh ack (blocked site)

Now to why I'm having problems....... :(

1. This is not a scan that would get any information since the addresses are private and should be dropped on the return trip by routers - so.... no point in that.
2. While I get large numbers of them it is not a DOS/DDOS at me because the traffic level is very small compared to my pipe - not that.
3. It is not a reflected DDOS since the reflected packets go nowhere - like in 1.
4. It is not inappropriately set up boxes because the events can alter IP address one or more times during the event to a similar address, (same A or B class private net) but sometimes the C Class is way away from the original IP.

I am at a loss to see any point in these packets even though they appear crafted - or am I wrong in that assumption?

Have at it guys and gals - what is this traffic? :confused:

It could possibly be DRDoS.Usually,a DRDoS won't send a huge flood of packets your way,because the point of it is to flood the target with a large number of legit computers to make the attack almost totally unable to be traced.Do a whois on the IP.Then give the person a call,because if it is DRDoS,the IP most likely won't be spoofed it will lead you to a legitamate user.Ask them to check their firewall to see if they're having a similar problem.This method of attack can involve a huge amount of computers,and the only way to really trace it is for all of the victims to get together and figure out whos IP is whos and then you can find the IP of the attacker(which in all likelyhood is going to be spoofed),and you will have to figure out where the proxy server(s) are,and get the true IP.

Or it could just be noise.It happens from time to time,and there's no real way to totally get rid of it,but just to be sure I'd investigate if I were you.

gghornet: In a DRDos a SYN or similar packet is sent to the "middle man" with the address of the actual victim spoofed as the source. The ensuing reply, (SYN/ACK or whatever), is then sent to the victim's IP as delineated by the spoofed source. Thus it can't be DRDos.... The target is not legitimate - the packets are being dropped but the internet routers, (and by my firewall for that matter). The target would have to be a legitimate, routable IP address somewhere out there - these purport to come from private, non-routable address blocks. If some moron is trying to DRDos one of his internal addresses by using me et al he needs to read a good TCP/IP primer...... :D

PS: Love your tagline.......

LOL.Good point.Well,I don't have a freakin clue then.I'm not the most security saavy out of the bunch by any means.All I can do is try.

No prob.... You were bang on for the type of packet I would be seeing - just that routing issue got in the way.... :D

As an aside - I have also considered that it might be someone testing a scanner/tool they are writing for themselves and could care less which address they hit. But this has been going on way too long for someone to just be playing with the interface and bashing away at me as their "test" address. By now I would have expected them to have moved on to more sophisticated testing and would want some response from their new toy - something they won't be getting with these IP addresses.

It is possible some type of firewall test scan. Used espeically if you have your firewall set to email an account when it has to reject packets of some type. heres the idea....
your firewall emails an external account... say [email protected]... every time it has to reject packets (or you have an ids that does this behind the firewall every time it gets certain sequences).
Ok, so attacker dood gets access to the [email protected] account. Now when he sends packets to your firewall, he can see if they get rejected by checking [email protected]. If there is no message, he has found a way to bypass your firewall/ids. And the bad thing is, you never know where he came from because it was always 10. number that attacked you. And he now knows how to get into your system without triggering any alarms, so he can use a normal IP.

I'm not saying this is what is happening, but it is a possibility.

Souleman: Good thinking - I like the way your mind works..... :)

Unfortunately, my firewall emails no-one and my IDS systems email me in circumstances that do not fit this pattern.

While that was a great possibility it doesn't fit my situation - but I am about to start thinking about some other things that I might not have thought of which kinda scares me 'cos if this is genuine activity it means that this isn't a simple skiddy and that means I have the attention of someone I probably don't want the attention of..... :mad:

Its Probly Just someone nosing around.. to see what your system is all about.. problably looking for holes.. as long as your firewall is catching most of it, just keep on your toes, and as mentioned, do some backround info checking, and give the guy a call, that usually freaks them out enough to stop it....

Not meaning to be rude or sarcastic..... But I can't resist.... It's my nature.... :D

Which one of the thousands of 10.1.1.1 addresses there are in the world do you suggest I call.... Then of course there's the 192.168.X.X and the 172.X.X.X addresses too....

These events are from _private_ subnets, they point to no-one that's why I am so confused about their high incidence - I can understand a few from misconfigured machines but this activity is pretty constant - day in, day out, 24 hours a day at random times and for random durations - or at least I can't see a pattern.

I wouldn't care if it was a traceable address - there could be any number of reasons for the activity - what's peeking my curiosity is the origin of so much traffic that patently will go nowhere and do no-one any good - as far as I can see......

Sorry I guess I am not as Godly Proficient as yourself... Have Fun

Nmap and its decoy lists. This is probably the culprit. I can send a scan to a target, and set a decoy list as well. This sends my scan along with a number of spoofed IP's that show up in the firewall's or ids's log files. As an admin, looking at the logs show that 20 different IP's are doing the same scan...which one is the real attacker?
I could set a decoy list for 10.1.1.1, 10.1.1.2, etc, etc.
I'm sure this is, or something like this, is the issue.
Just my theory anyway....

do you have a proxy listening on 8080?

is this a watchguard log?

i suggest you drop incomming packets form private addresses at the router

Quote:

---

Originally posted here by Tedob1
i suggest you drop incomming packets form private addresses at the router

---

Doesn't that go without saying? :p :p

Sgt_B, Scarry enough, it doesn't. Thats why firewalking works so well. To many admins do not set up their routers properly, because they don't even think about that.

Sgt_B: Ok.... I'm with you on the principle.... I even went back and took a look at the logs. On only one occasion in the last 24 hours has there been a public address SYN or whatever in amongst the private address events. Without the public address the nmap scan event would be useless to a footprinter - but with there being only one I put it down to coincidence and that address showed up in other logs and proved to be valid activity. To further the point though why would one hide their valid scan amongst a pack of decoys that are sooooo obvious - it's like hiding a red ball in a pile of green ones - someone is going to see it really easily? I would really buy into your thoughts if the activity was coming from public addresses, in fact I would say you are absolutely correct but in this situation it's not logical - and I'm a firm believer in logic..... :)

Tedob1: Yes, Watchguard. No proxies of any kind. Dropping private subnet packets at the firewall is default on the firewall. Additionally I have very tight ingress and egress filters that allow only required services in and out sometimes limited to only specific remote addresses. Those were simply examples so the port numbers are not truly representative there tends to always be a readily recognizable port at the source or destination end of every event and they are often the same at both.

Actually I'm really rather glad that someone hasn't just popped up and said "Oh, that's so-and-so"..... I'd have felt quite the fool...... :)

Tiger: The red ball in a pile of green ones is not a correct analogy. I might not have described the feature properly. In the decoy list, you can specify publis as well as private IP addresses. So If I sent 10 scans to your machine...all with public addresses, that actually belonged to ther people.....well....find the red ball then! :D You can also specify your IP to scan at the end of the decoys. I've heard of some IDS's that will stop alerting after 5 or 6 of the same scan. This is just info I've heard, and have no resources to back it up though.
This in no way helps you, I just wanted to clarify a little...
Ok back on subject,
I agree, that my previous post is invalid since no other scans are showing up. I'm quite stumped as to who or what is doing this. The only thing that I can think of is comparing your logs from the IDS and the firewall. Are there any inconsistencies. Just switched on paranoid mode. Perhaps someone has gotten to your firewall logs and has done some tampering either removing their scans from the list, or covering their tracks by switching to a private IP address in the logs. Lame theory, but the only one I got.
Either that or a misconfigured router/computer on the internet somewhere. <--A bit more probable.

Either way, good luck, and let us know if you find the source!

that is an odd one.

i appears that all of the incoming IP addresses are reserved for private networks, so if i have this right, that network address should only be on the inside of a network and the IP coming to you should include the IP of the router or proxy that it is going through. routers dont use reserved IP addresses so they are pretty much null on the internet. the similar addresses that you are getting may be a router or proxy that these addresses are coming from. so whatever is coming to you, it may be coming from the inside of another LAN.