Ok, so i have been reading up on how ipspoofing works, and they beat the OSI model into college heads these days/. What I am wondering is there a tutorial out there showing you how to spoof ips with open source software like nemesis?
Printable View
Ok, so i have been reading up on how ipspoofing works, and they beat the OSI model into college heads these days/. What I am wondering is there a tutorial out there showing you how to spoof ips with open source software like nemesis?
Would something like this be helpful? (notice down at the bottom of the discussion).
Well I believe that helps quite well. Thank you very much. I understand the injection, but after a packet is injected, how do you make it appear to come from another ip when making an actual tcp connection or over a syn handshake. This looks like it will clear that up for me.
Thanks again!
*once you aquire a firearm, be extra careful that you don't blow away those tiny little toes your mommy loved to kiss when you were a baby*Quote:
Originally posted here by kr5kernel
Well I believe that helps quite well. Thank you very much. I understand the injection, but after a packet is injected, how do you make it appear to come from another ip when making an actual tcp connection or over a syn handshake. This looks like it will clear that up for me.
Thanks again!
Dually noted. Believe you me, there is not a dark bonein my body, we have recently been getting alot of bad traffic on our network from spoofed ips. I was curious as to how they were doing and wanted to see if I could replicate.
how do you know they are spoofed?Quote:
Originally posted here by kr5kernel
Dually noted. Believe you me, there is not a dark bonein my body, we have recently been getting alot of bad traffic on our network from spoofed ips. I was curious as to how they were doing and wanted to see if I could replicate.
They will say they are coming form a machine that is turned off. or Multiple attacks from different ips at the same time utilizing the same attacks on different servers.
is this on a wireless network?
Who is they? and what specific types of activity is happening? What kind of attacks are these? (e.g., Smurf, Arp flooding, etc.)Quote:
They will say they are coming form a machine that is turned off. or Multiple attacks from different ips at the same time utilizing the same attacks on different servers.
Its random guessing of passwords for system accounts, ie test, guest, apache. Accounts that are locked out on linux. Every morning on several of the linux servers that have external ips we are noticing about 8-50 attempts.
Hrmmm... sounds like someone thinks your servers are interesting. Why are only the Linux box causing lockouts (you have Windows boxes)?
Are the attacks coming from the same subnet (even if "spoofed")?
It sounds like a tool being used (repeated account bruteforce attempts)
all the windows boxes are nat'd and behind a firewall. I woudlnt think it was bruteforce simply because I would expect way more attempts. Considering how many attempts could be possible per second and all. When we only get 8 login attempts, it seems more like someone just hunting and pecking and trying to guess. But it definitly is feasible.
Do you have any sanitized packet captures that you can attach?
Or sanitized firewall logs?
Or both?
For some reason I remember seeing an advisory or something on full disclosure about this... but I can't remember at the moment. I have to do some searching.
Every morning.....
Oct 12 05:01:56 sanhost sshd[10535]: Failed password for illegal user john from ::ffff:200.xxx.xxx.2 port 3798 ssh2
Oct 12 05:02:00 sanhost sshd[10537]: Failed password for root from ::ffff:200.xxx.xxx.2 port 4201 ssh2
Oct 12 05:02:04 sanhost sshd[10539]: Failed password for root from ::ffff:200.xxx.xxx.2 port 4610 ssh2
Oct 12 05:02:09 sanhost sshd[10541]: Failed password for root from ::ffff:200.xxx.xxx.2 port 4976 ssh2
Oct 12 05:02:13 sanhost sshd[10543]: Failed password for root from ::ffff:200.xxx.xxx.2 port 1406 ssh2
Oct 12 05:02:18 sanhost sshd[10545]: Failed password for root from ::ffff:200.xxx.xxx.2 port 1816 ssh2
Oct 12 05:02:20 sanhost sshd[10547]: Illegal user test from ::ffff:200.xxx.xxx.2
Oct 12 05:02:22 sanhost sshd[10547]: Failed password for illegal user test from ::ffff:200.xxx.xxx.2 port 2227 ssh2
Thats what I thought... ssh.
There has been a lot of scanning against ssh the past couple of months.
I saw reports on the FD and on several other sites that match what you are seeing.
Here is some futher reading if you'd like.
http://forums.devshed.com/archive/t-169975
http://www.securityfocus.com/archive...5/2004-07-31/0
http://seclists.org/lists/incidents/2004/Jul/0067.html
http://seclists.org/lists/incidents/2004/Jul/0065.html
Most seem to be showing up from the end of July. You're just now noticing this activity?
Even more interesting threads:
http://seclists.org/lists/incidents/2004/Jul/0084.html
Well, you can pick through them if you're really that interested.
http://seclists.org/lists/incidents/...l/date.html#69
You are denying root from logging into sshd, right?
Another thing you could do, is use your firewall, or tcp wrappers and only allow traffic from subnets that are familiar? I don't know why you allow access to sshd or who uses it... so it'd probably have to be well thought out. Or you can even change the port that sshd listens on. Something that is still easy for users to use but automated tools will not look for. (except for tools like nessus... it will still identify a sshd listening on port 8022)
BTW: Check out the link below and enter ssh for your search quary.
You should see all the info you need there. :)
http://isc.sans.org//search.php
Found using the search link above.Quote:
SSH brute forcing continues
We keep getting reports of people getting hit seriously by brute force attempts to exploit ssh. It looks like this is going to stay with us for a while longer. Best to make sure:
- Weak passwords aren't used on your machines.
- sshd version is up to date.
- User root cannot login over the network.
- Typical usernames like guest and test aren't present on your system, or are disabled from logging in.
- Consider filtering where you accept connections from on TCP port 22.
- Consider moving ssh away from port 22 if you can't filter easily (the automated bots will have to look harder to find you)
- Report on failed login attempts, but make sure you don't aggravate the problem by sending an email per attempt.
- Consider migrating to public/private key-pairs instead of passwords.
- Some of our readers have had success with rate limiting incoming ssh connections.
I have been notiocing this for a while, probably since july, I have just been blockgin the individual ips, which was leading me to believe they were spoofed since it was a different ip, but the same attack every day.