Everyone,
I've actually had to lock down most ports on my server; because, I got tired of all the attempts at attacks. Everyone, please use a firewall. I've noticed many attacks to the following ports: 111 -- sunrpc ** this effects Linux machines 135 -- DCE Endpoint Resolution 137 -- netbios-ns 139 -- netbios-ssn 445 -- microsoft-ds ** these affects samba services as well. 1433 -- ms-sql-s 1434 -- ms-sql-m ** I don't know why SQL ports are being attacked.
1023 -- ??? 5554 -- ??? 9898 -- ??? ** this group may be related to PCAnywhere, or Worm, etc.
The most active: port 445 by far!
Just giving everyone a heads-up on the security issues. James Kosin
James Kosin wrote:
1433 -- ms-sql-s 1434 -- ms-sql-m ** I don't know why SQL ports are being attacked.
That's probably the Slammer worm, or someone exploiting the same vulerability. An old MSSQL risk only.
Anyway, it's always a good idea to run a firewall :)
//Andro
Everyone,
I've actually had to lock down most ports on my server; because, I got tired of all the attempts at attacks. Everyone, please use a firewall. I've noticed many attacks to the following ports: 111 -- sunrpc ** this effects Linux machines 135 -- DCE Endpoint Resolution 137 -- netbios-ns 139 -- netbios-ssn 445 -- microsoft-ds ** these affects samba services as well. 1433 -- ms-sql-s 1434 -- ms-sql-m ** I don't know why SQL ports are being attacked.
1023 -- ??? 5554 -- ??? 9898 -- ??? ** this group may be related to PCAnywhere, or Worm, etc.
The most active: port 445 by far!
Just giving everyone a heads-up on the security issues. James Kosin
Good points James...you missed one though... port 22. I see more attempts on SSH than any other port....stupid and LAME attempts but more on this than any other...
-Eucke
Eucke Warren wrote:
Everyone,
I've actually had to lock down most ports on my server; because, I got tired of all the attempts at attacks. Everyone, please use a firewall. I've noticed many attacks to the following ports: 111 -- sunrpc ** this effects Linux machines 135 -- DCE Endpoint Resolution 137 -- netbios-ns 139 -- netbios-ssn 445 -- microsoft-ds ** these affects samba services as well. 1433 -- ms-sql-s 1434 -- ms-sql-m ** I don't know why SQL ports are being attacked.
1023 -- ??? 5554 -- ??? 9898 -- ??? ** this group may be related to PCAnywhere, or Worm, etc.
The most active: port 445 by far!
Just giving everyone a heads-up on the security issues. James Kosin
Good points James...you missed one though... port 22. I see more attempts on SSH than any other port....stupid and LAME attempts but more on this than any other...
-Eucke
Yes, I missed that in the logs. They are so few attempts, I only got 2 during the one day I sampled. Of course, when they can connect, they try several names.
I also left off ports: 55838, 1026, 1027, 4899, 1334, 1025,. 6129...
If anyone is interested, I can send a copy of the report or even the log file information.
Thanks, James Kosin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Eucke Warren wrote:
| Good points James...you missed one though... port 22. I see more attempts on | SSH than any other port....stupid and LAME attempts but more on this than | any other...
Yes, they seem to be scripted; the same sequence of user names appears in every attack.
- --
- -John (john@os2.dhs.org)
On Tue, 2004-10-26 at 09:20 -0700, Eucke Warren wrote:
Good points James...you missed one though... port 22. I see more attempts on SSH than any other port....stupid and LAME attempts but more on this than any other...
Everyone will eventually "miss one", or the bad guys come up with something new. That's why demonstrated best practices are to block *everything* and only open things which you know for sure you need to open. Then make sure those open holes are not being answered by anything vulnerable... patch, update, maintain.
Not that you're wrong about SSH attacks being common, just adding to the comment.
Cheers,
Good points James...you missed one though... port 22. I see more attempts on SSH than any other port....stupid and LAME attempts but more on this than any other...
Out of curiosity, how much does it really matter so long as you have strong passwords?
If security holes are discovered in ssh, then sure, someone who knows what they're doing might be able to gain access. But then someone qualified enough to find new holes in ssh won't be targeting my desktop box, or the http server for a small buisines.
In general isn't ssh pretty secure, and aren't security fixes normally issued before the script kiddies get hold of an exploit?
-- Jim
On Wed, 27 Oct 2004 11:54:08 +0100, Jim Higson jh@333.org wrote:
Good points James...you missed one though... port 22. I see more attempts on SSH than any other port....stupid and LAME attempts but more on this than any other...
Out of curiosity, how much does it really matter so long as you have strong passwords?
If security holes are discovered in ssh, then sure, someone who knows what they're doing might be able to gain access. But then someone qualified enough to find new holes in ssh won't be targeting my desktop box, or the http server for a small buisines.
In general isn't ssh pretty secure, and aren't security fixes normally issued before the script kiddies get hold of an exploit?
-- Jim
You never know when someone will feel slighted and make any business a target "to show them."
It's best to not let root login directly and limit who can ssh in.
The old security joke:
Two men on the Serengeti Plans when they notice a lion stalking them. The first stops to put on his running shoes. The second states that you can't out run a lion even with running shoes. The first calmly states I don't have to out run the lion I have to out run you.
The moral is that you don't have to have perfect security, but you better not be the easiest target either.
Jim Higson wrote (about SSH):
Out of curiosity, how much does it really matter so long as you have strong passwords?
If security holes are discovered in ssh, then sure, someone who knows what they're doing might be able to gain access. But then someone qualified enough to find new holes in ssh won't be targeting my desktop box, or the http server for a small buisines.
In general isn't ssh pretty secure, and aren't security fixes normally issued before the script kiddies get hold of an exploit?
Yes.
But how quick are you on the patch?
If you're going to configure yum to automatically install new versions, you're *probably* OK. If you leave installing patches until you've had a chance to manually review them, and go away for a week or two, and a patch comes out the first Monday you're away...
(And it's always possible for your yum mirror to be taken off-line on the Sunday: always configure at least two mirrors if you want unattended operation. And *check your logs!*)
Security is never an absolute: what you are doing is managing risk. In this case, there is very little risk (with decent passwords), but there is some.
James.
On Wed, 2004-10-27 at 06:54, Jim Higson wrote:
Good points James...you missed one though... port 22. I see more attempts on SSH than any other port....stupid and LAME attempts but more on this than any other...
Out of curiosity, how much does it really matter so long as you have strong passwords?
If security holes are discovered in ssh, then sure, someone who knows what they're doing might be able to gain access. But then someone qualified enough to find new holes in ssh won't be targeting my desktop box, or the http server for a small buisines.
In general isn't ssh pretty secure, and aren't security fixes normally issued before the script kiddies get hold of an exploit?
Brute force login attempts against ssh can work if given enough time just like any other access that uses simple password protection. It just may take a really long time to get to the right combination of letters, numbers, and special characters (assuming you have a non-trivial password that is not dictionary based).
And it is best practice to limit ssh to only those accounts that need to use it and block direct root access. This limits the user ids that will work and makes it just a little more difficult.
Like others have said in this thread, you are managing risk, some may feel comfortable with a higher level of risk that others. But as long as you make your system just a little more difficult to access than the next one more than likely the hackers will move on to the system that is easier to hack.
Of course most security breaches in companies are from inside not external. And those that are external normally are of the social engineering type instead of some clever hack over the Internet.
Scot L. Harris wrote:
On Wed, 2004-10-27 at 06:54, Jim Higson wrote:
Good points James...you missed one though... port 22. I see more attempts
Brute force login attempts against ssh can work if given enough time
How about setting portsentry to block IPs (temporarily) after 10 or so attempts? Can it do that (I kind of think so)?
Andro
On Wed, 2004-10-27 at 11:09, Andrey Andreev wrote:
Scot L. Harris wrote:
On Wed, 2004-10-27 at 06:54, Jim Higson wrote:
Good points James...you missed one though... port 22. I see more attempts
Brute force login attempts against ssh can work if given enough time
How about setting portsentry to block IPs (temporarily) after 10 or so attempts? Can it do that (I kind of think so)?
So you slow down the brute force attack. If you block it permanently you set your self up to a DOS attack, just hit the system multiple times using spoofed addresses until you have blocked a significant range of addresses, or at least critical ones (such as DNS servers).
Given enough time brute force attempts will work. Period.
Given enough time brute force attempts will work. Period.
Technically, yes, but I'll probably be dead by the time they do!
Assume passwords are made of letters of both case and numbers, and are always 8 chars long. Of course, in reality there are more than 62 chars (IMO it's always a good idea to have puncuation in a password)
That's 62^8 possible passwords, or about 2.2*10^14
So at 1 try per second (unrealistically fast I'd say for ssh) that's 7 million years (give or take a millenia or two) to try the whole set.
Or, to put it another way, if I get one brute force crack attempt per second for a whole year there's a one in seven million chance they'd gain access.
To be honest, that's ok with me :) -- Jim
On Wed, 2004-10-27 at 12:13, Jim Higson wrote:
Given enough time brute force attempts will work. Period.
Technically, yes, but I'll probably be dead by the time they do!
Assume passwords are made of letters of both case and numbers, and are always 8 chars long. Of course, in reality there are more than 62 chars (IMO it's always a good idea to have puncuation in a password)
That's 62^8 possible passwords, or about 2.2*10^14
So at 1 try per second (unrealistically fast I'd say for ssh) that's 7 million years (give or take a millenia or two) to try the whole set.
Or, to put it another way, if I get one brute force crack attempt per second for a whole year there's a one in seven million chance they'd gain access.
To be honest, that's ok with me :)
Jim
I agree, like I said earlier it is all about managing the risk. If you take the right precautions your system will be bypassed for less secure systems.
So how many ssh attempts per second can one system sustain, assuming the attempts are from multiple systems hitting at the same time? :)
On Wed, 2004-10-27 at 14:09 -0400, Scot L. Harris wrote:
So how many ssh attempts per second can one system sustain, assuming the attempts are from multiple systems hitting at the same time? :)
Honestly, beats me. But since I limit access using AllowUsers in /etc/ssh/sshd_config and since I primarily use certificates to log in rather than passwords, they're not going to get in within my lifetime. <grin>
Even when I do use passwords (and assuming the 8-char "standard"), I always have at least one upper- and lower-case letter, one number, and one special char. So that's actually 94^8 = 6,095,689,385,410,816 or about 6.1 x 10^15.
If I did my quick figures right, they'd have to exceed 1.93 million attempts per second to be statistically likely to crack my box in less than 100 years. Not bloody likely, and still very secure. <grin>
Cheers,
On Wed, 2004-10-27 at 18:09 +0300, Andrey Andreev wrote:
How about setting portsentry to block IPs (temporarily) after 10 or so attempts? Can it do that (I kind of think so)?
No. Portsentry can only bind to ports on which there is not already another program listening, so it cannot bind to 22. What I did do with Portsentry is combine it with Shorewall to somewhat reduce hostile probes, roughly this way:
1. Create a set of "hostile" ports. These are ports which no sane and normal person would *ever* use on your box, and where you are prepared to drop someone off the face of the Earth for even looking at them. For instance, on my commercial webserver I would never expose portmap (111) to the Internet, nor should anyone ever attempt to print to that box (it being in a locked cabinet 1,500 miles away). So my list of hostile ports for that box includes 111 and 515 (and 23, 1080, 8080, 12345, mssql, etc., all ports that should never, ever, *ever* be poked).
2. Use Shorewall to firewall the box, and create REDIRECT rules in the firewall to move all such traffic to a single port (on my box, 49999). This limits exposure to potential risks, since *if* I somehow messed up and actually activated portmap it would still not get any requests from outside... all outside requests for tcp/111 would go to tcp/49999.
3. Create a script which calls Shorewall's blacklisting functionality (given an IP address) and drops this IP address into a black hole. The script also schedules an "at" job for X days (in my case, 2 days) later to remove that restriction. You don't want to keep blocking everything forever since your block list gets huge and most IP's that get blocked are going to be dial-up anyway.
4. Configure Portsentry with a hair trigger: any IP that sends even a single packet to port 49999 gets instantly black-holed with the script from Step 3.
The result is that I generally have 15-20 hosts blocked at any one time, and that most script kiddies who reach my system poke a hostile port while looking for the most common exploits. The number of attacks has gone way down, and the kiddie who sets off Shorewall/Portsentry has to wait another two days to try to test my SSH port. In reality, most simply move on.
I love it.
Rodolfo J. Paiz wrote:
<<-- snip -->>
I love it.
I took a simpler approach.
1. Setup iptables with the following iptables -A INPUT -i lo -j ACCEPT # this allows local loop interface to always work. iptables -A INPUT -d xxx.xxx.xxx.xxx -m state --state RELATED,ESTABLISHED -j ACCEPT # accept connections back to this host for connections attempted from this host iptables -A INPUT -j REJECT # this rejects everything else
2. I just add iptables -I INPUT 3 -d xxx.xxx.xxx.xxx -p tcp -m state --state NEW -m tcp --dport yyy -j ACCEPT for each port I want to open up on my server.
Note: xxx.xxx.xxx.xxx gets replaced with the local machine's IP address. yyy gets replaced with the port number
You can also restrict the source IP address for the packet by including a -s zzz.zzz.zzz.zzz to the iptables command.
Most clients, #1 above is enough to block all attacks.
James Kosin
On Wed, 2004-10-27 at 13:00 -0400, James Kosin wrote:
I took a simpler approach.
Well yes, that is *simpler* but it is in no way better. It's also very basic... in fact, that's the basic procedure for *any* firewall (close everything then open up what you need), and that's how my firewall is setup too. No news here.
The Portsentry setup is to block those people who are going to attack services I *do* run, since they will normally try to attack others as well. So the guy who is going to test SSH for exploits, and try all sorts of stuff on my Apache server, and see if he can get to Sendmail... is also likely to trigger a hostile port and get deep-sixed for 48 hours.
No iptables ruleset on Earth can protect you from attacks to an open port on which you have a service listening. That job is up to the process listening on the port. But you can attempt to find a way to block those people before or during their probes... my Portsentry mechanism is one such attempt, and has been highly successful for me as an additional layer of defense over the last two years or so.
- Setup iptables with the following iptables -A INPUT -i lo -j ACCEPT # this allows local loop
interface to always work.
Most clients, #1 above is enough to block all attacks.
No way. #1 above has nothing to do with any external attacks. And indeed closing all ports by default is just a precaution, since there should be nothing listening on those ports *anyway* and thus there should be nothing to crack except the services you do run. So in the end, your primary risk comes from the services you offer being cracked or rooted.
Again, no iptables ruleset on Earth can protect you from that.
Cheers,
Rodolfo J. Paiz wrote:
On Wed, 2004-10-27 at 13:00 -0400, James Kosin wrote:
I took a simpler approach.
Well yes, that is *simpler* but it is in no way better. It's also very basic... in fact, that's the basic procedure for *any* firewall (close everything then open up what you need), and that's how my firewall is setup too. No news here.
The Portsentry setup is to block those people who are going to attack services I *do* run, since they will normally try to attack others as well. So the guy who is going to test SSH for exploits, and try all sorts of stuff on my Apache server, and see if he can get to Sendmail... is also likely to trigger a hostile port and get deep-sixed for 48 hours.
No iptables ruleset on Earth can protect you from attacks to an open port on which you have a service listening. That job is up to the process listening on the port. But you can attempt to find a way to block those people before or during their probes... my Portsentry mechanism is one such attempt, and has been highly successful for me as an additional layer of defense over the last two years or so.
- Setup iptables with the following iptables -A INPUT -i lo -j ACCEPT # this allows local loop
interface to always work.
Most clients, #1 above is enough to block all attacks.
No way. #1 above has nothing to do with any external attacks. And indeed closing all ports by default is just a precaution, since there should be nothing listening on those ports *anyway* and thus there should be nothing to crack except the services you do run. So in the end, your primary risk comes from the services you offer being cracked or rooted.
Again, no iptables ruleset on Earth can protect you from that.
Cheers,
Sorry, maybe I didn't make myself clear. #1 included all 3 iptable entries not just the first. If you want to really cripple your machine, just do the first and third iptable entries and you will not be able to browse the web or anything. The second one opens up the return path for connections established by the client machine. You don't give iptables a chance. It is a very powerful feature. With proper setup you can allow unfeathered access to your server on your network alone and deny access (or restrict) everyone else.
James Kosin
----- Original Message ----- From: "James Kosin" jkosin@beta.intcomgrp.com To: "For users of Fedora Core releases" fedora-list@redhat.com Sent: Wednesday, October 27, 2004 10:56 AM Subject: Re: Security....
Rodolfo J. Paiz wrote:
On Wed, 2004-10-27 at 13:00 -0400, James Kosin wrote:
I took a simpler approach.
Well yes, that is *simpler* but it is in no way better. It's also very basic... in fact, that's the basic procedure for *any* firewall (close everything then open up what you need), and that's how my firewall is setup too. No news here.
The Portsentry setup is to block those people who are going to attack services I *do* run, since they will normally try to attack others as well. So the guy who is going to test SSH for exploits, and try all sorts of stuff on my Apache server, and see if he can get to Sendmail... is also likely to trigger a hostile port and get deep-sixed for 48 hours.
No iptables ruleset on Earth can protect you from attacks to an open port on which you have a service listening. That job is up to the process listening on the port. But you can attempt to find a way to block those people before or during their probes... my Portsentry mechanism is one such attempt, and has been highly successful for me as an additional layer of defense over the last two years or so.
- Setup iptables with the following iptables -A INPUT -i lo -j ACCEPT # this allows local loop
interface to always work.
Most clients, #1 above is enough to block all attacks.
No way. #1 above has nothing to do with any external attacks. And indeed closing all ports by default is just a precaution, since there should be nothing listening on those ports *anyway* and thus there should be nothing to crack except the services you do run. So in the end, your primary risk comes from the services you offer being cracked or rooted.
Again, no iptables ruleset on Earth can protect you from that.
Cheers,
Sorry, maybe I didn't make myself clear. #1 included all 3 iptable entries not just the first. If you want to really cripple your machine, just do the first and third iptable entries and you will not be able to browse the web or anything. The second one opens up the return path for connections established by the client machine. You don't give iptables a chance. It is a very powerful feature. With proper setup you can allow unfeathered access to your server on your network alone and deny access (or restrict) everyone else.
James Kosin
Great thread guys...I do have to say...once I realized what Rodolfo was describing I had to laugh. Very clever! Great mechanism! May need to look into it for my stuff...
-Eucke
----- Original Message ----- From: "Eucke Warren" euckew@sierraelectronics.com To: "For users of Fedora Core releases" fedora-list@redhat.com Sent: Wednesday, October 27, 2004 2:07 PM Subject: Re: Security....
I took a simpler approach.
<<Snip> > >
- Setup iptables with the following iptables -A INPUT -i lo -j ACCEPT # this allows local loop
interface to always work. Most clients, #1 above is enough to block all attacks.
<<snip> > >
Great thread guys...I do have to say...once I realized what Rodolfo was describing I had to laugh. Very clever! Great mechanism! May need to
look
into it for my stuff...
-Eucke
I like the idea.. I might even take it a step beyond if I ever get any spare time. Just make the router send all ports I'm not using to a honeypot! Just have to get time to put one together... Any thoughts?
Scott....
I took a simpler approach.
<<Snip> > >
- Setup iptables with the following iptables -A INPUT -i lo -j ACCEPT # this allows local loop
interface to always work. Most clients, #1 above is enough to block all attacks.
<<snip> > >
Great thread guys...I do have to say...once I realized what Rodolfo was describing I had to laugh. Very clever! Great mechanism! May need to
look
into it for my stuff...
-Eucke
I like the idea.. I might even take it a step beyond if I ever get any spare time. Just make the router send all ports I'm not using to a honeypot! Just have to get time to put one together... Any thoughts?
Scott....
I have often wished i had the time.
One thing I would like to do is set apache up to feed the attempts to get at command.com to a fake shell that disparages the guy on the other end. Another is to reflect those 32k query strings back into the error page.
And, since I'm a helpful sort of guy, it seems like it would be a worthwhile project to write an automatic script that would at least try to find the admin for 0wn3d boxes and send a warning e-mail.
If I had the time.
On Wed, 2004-10-27 at 13:56 -0400, James Kosin wrote:
You don't give iptables a chance. It is a very powerful feature. With proper setup you can allow unfeathered access to your server on your network alone and deny access (or restrict) everyone else.
My dear James, the problem is that you are misunderstanding me... or that I am not explaining myself, but if I write longer posts people bitch that I overload their quotas. <grin>
I do use iptables... see Shorewall (http://www.shorewall.net). I do take advantage of every piece of it I can, and Shorewall makes it easy for me. What I was describing is an *additional* measure of protection... since iptables cannot protect you from attacks on open ports (like 22 or 80, if you offer those services), then leave an "open" but redirected port as bait so that you can catch (and banish) anyone who touches them.
I am in no way saying that the basic iptables firewall is bad; far from it! What I am saying is that such a simple setup is good but one can do *more* to protect the system if the time, effort, and cycles are available to do some extra work.
Read over my long post again, carefully. I think you'll like the additional level of protection that this offers you: the point being that, if the guy is going to probe your 22 and 80, he's also likely to try your 1080 and 8080... so when he touches those you zap him, and hopefully make him lose interest when he has to wait two days to send *any* packets to your machine.
Cheers,
On Wed, October 27, 2004 18:54, Jim Higson said:
Good points James...you missed one though... port 22. I see more attempts on SSH than any other port....stupid and LAME attempts but more on this than any other...
Out of curiosity, how much does it really matter so long as you have strong passwords?
I do see more brute force attempts @ ssh these days and start wondering how much longer some script kiddie needs to make the algortihm a bit more clever (and eg attack user names on certain hosts which are likely to exist. This could be harvested eg from email addresses...).
I have hacked a script which tails /var/log/secure and reacts on attempts to log in as root with password. Such offending IPs are then denied port 22 access. Any comments, positive or negative, on this?
On Thursday 28 October 2004 03:37 am, HaJo Schatz wrote:
I have hacked a script which tails /var/log/secure and reacts on attempts to log in as root with password. Such offending IPs are then denied port 22 access. Any comments, positive or negative, on this?
Oooh... care to post it? I like the sounds of that. :-) Thanks
On Thursday 28 October 2004 03:37 am, HaJo Schatz wrote:
I have hacked a script which tails /var/log/secure and reacts on attempts to log in as root with password. Such offending IPs are then denied port 22 access. Any comments, positive or negative, on this?
Oooh... care to post it? I like the sounds of that. :-) Thanks
I'd also love to have a look - sounds like a good idea! Might also be nice for configurable to deny access to other services after repeated failures - eg web login forms etc
On Thu, 2004-10-28 at 18:45, John Aldrich wrote:
On Thursday 28 October 2004 03:37 am, HaJo Schatz wrote:
I have hacked a script which tails /var/log/secure and reacts on attempts to log in as root with password. Such offending IPs are then denied port 22 access. Any comments, positive or negative, on this?
Oooh... care to post it? I like the sounds of that. :-) Thanks
Sure, dead simple anyway. You can source the resulting blackist.txt e.g. in hosts.deny where you might want to block ssh access only. Alternatively, use the IPs as new rules for your firewall. Note that the blacklist.txt file has to exist for the script to run (lazy me ;)).
BTW, thanks guys for all your comments. I'm more worried about an accidential PW discovery on a user name than a DOS, so I think my chosen path should be OK. PW authentication is a must for users connecting from unknown IPs (whereas I have of course disabled root PW access). I'll have a look into snort though...
================
#!/usr/bin/perl # # Remember to restart this daemon after rotating the secure-log!!! #
use strict;
# Config my $BL = "/opt/sshBruteDetect/blacklist.txt"; my $LOG = "/var/log/secure";
my $IP; my $found;
open F, "tail -n -0 -f $LOG |" or die "Could not open log file\n ERROR: $!";
while(<F>) { if( $_ =~ /sshd.*Failed password for root from (.+) port/ ) { $IP = $1;
open B, "$BL" or die "Could not read blacklist-file!\n ERROR: $!"; $found=0; LOOP: while ( <B> ) { if( $_ =~ /$IP/ ) { $found=1; last LOOP; } } close B ; if( !$found ) { open B, ">> $BL" or die "Could not write to blacklist-file!\n ERROR: $!"; print B "$IP\n"; close B; } } }
On Thu, 2004-10-28 at 03:37, HaJo Schatz wrote:
I do see more brute force attempts @ ssh these days and start wondering how much longer some script kiddie needs to make the algortihm a bit more clever (and eg attack user names on certain hosts which are likely to exist. This could be harvested eg from email addresses...).
I have hacked a script which tails /var/log/secure and reacts on attempts to log in as root with password. Such offending IPs are then denied port 22 access. Any comments, positive or negative, on this?
Just be careful how you set this up. If the hacker figures out you are performing automatic blocks they can write a script to spoof addresses and cause your system to auto block addresses that you might want to allow.
You may want to look at snort. I believe they have various options that allow you to trigger on suspicious behavior and take similar actions if you want. Seemed like a fairly extensive scripting capability was available.
Just watch out that you don't cause your own DOS attack on your system.
On Thu, 2004-10-28 at 03:37, HaJo Schatz wrote:
I have hacked a script which tails /var/log/secure and reacts on attempts to log in as root with password. Such offending IPs are then denied port 22 access. Any comments, positive or negative, on this?
Scot L. Harris wrote:
Just be careful how you set this up. If the hacker figures out you are performing automatic blocks they can write a script to spoof addresses and cause your system to auto block addresses that you might want to allow.
Not unless they have control of the routers between the server and the (spoofed) client, in which case they can cut you off anyway.
SSH uses TCP. TCP isn't like UDP or ICMP: it's a connection-oriented protocol. That means that when client A sets up a connection to server B on port 22 (over which a SSH connection might be negotiated), A sends a packet to B, containing the IP address of A. Now this can be faked, but B will send back a packet to that IP address, containing data that A needs to know to set up the connection.
If A fakes the IP address, it will never see the reply, and can't continue with the connection.
James.
(Technically, with certain sorts of network (principally Ethernet), an attacker might be able to spoof clients or servers on the same physical network segment. But this means that the attacking machine is within physical range, and physical responses are practical).
-----Original Message----- From: fedora-list-bounces@redhat.com [mailto:fedora-list-bounces@redhat.com] On Behalf Of HaJo Schatz Sent: Thursday, 28 October 2004 17:37 To: For users of Fedora Core releases Subject: Re: OT: Security....
On Wed, October 27, 2004 18:54, Jim Higson said:
Good points James...you missed one though... port 22. I see more attempts on SSH than any other port....stupid and LAME
attempts but
more on this than any other...
Out of curiosity, how much does it really matter so long as
you have
strong passwords?
I do see more brute force attempts @ ssh these days and start wondering how much longer some script kiddie needs to make the algortihm a bit more clever (and eg attack user names on certain hosts which are likely to exist. This could be harvested eg from email addresses...).
If you do some Googling, you will no doubt find the info on this in some security forums that I found when it first started on Port 22 a few months ago. A couple of people seet up "honey pots" and waited and watched... the result was that after one of the scripted attacks detects a well known account / password combination, the attack changes fromn being scripted to manual and a "root kit" is installed. The attackers were not good at covering their tracks in terms of command history, so that is what gave it away as a manual as opposed to a scripted attack. Here's a list of hack source addresses that I've recorded over a period of two months:-
SSH Hack source addresses 147.46.60.75 220.70.167.67 141.45.183.18 150.7.57.239 155.207.19.247 219.238.179.101 220.69.12.96 211.91.23.171 67.42.142.160 210.223.178.180 216.93.183.244 61.185.226.211 222.99.91.173 218.21.129.105 66.55.167.210 219.238.239.178 193.0.122.75 210.82.97.74 211.174.185.89 218.30.21.223 200.153.74.133 211.91.135.60 212.182.102.66 216.38.218.83 163.26.22.18 202.64.28.81 203.251.202.83 194.78.243.110 220.64.160.18 66.111.192.25 200.231.30.83 67.43.3.69 147.142.232.200 211.91.98.115 61.166.6.60 203.115.96.151 211.98.106.33 130.34.218.125 210.107.239.79 219.145.217.78 130.34.218.125 207.218.206.95 165.229.192.210 218.158.126.247 211.114.239.129 66.162.179.32 163.19.1.111 203.146.102.54 61.234.47.16 82.165.240.101 210.22.128.135 203.249.35.252 210.103.69.193 61.144.253.218 211.114.246.8 213.164.155.75 218.234.208.2 61.100.180.125 212.92.88.253 219.140.29.242 202.155.108.211 211.229.177.114 144.230.99.53 222.45.45.132 218.75.54.67
I checked one the other day and the IP was owned by a Korean University.
Regards, David. ---------
I have hacked a script which tails /var/log/secure and reacts on attempts to log in as root with password. Such offending IPs are then denied port 22 access. Any comments, positive or negative, on this?
-- HaJo Schatz hajo@hajo.net http://www.HaJo.Net
PGP-Key: http://www.hajo.net/hajonet/keys/pgpkey_hajo.txt
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
On Thu, 2004-10-28 at 23:35 +1000, David wrote:
Here's a list of hack source addresses that I've recorded over a period of two months:-
[...]
I checked one the other day and the IP was owned by a Korean University.
And that's the problem. The majority of IP addresses you'll get are from dial-up pools and other common uses. Blocking it permanently does no good... the guy who attacked you is no longer there.
As an example, when I block IP addresses dynamically, I unblock them after two days. I have almost *never* seen an IP address repeat itself, and after a while I stopped even checking for repeats.
Cheers,
...
I do see more brute force attempts @ ssh these days and start wondering how much longer some script kiddie needs to make the algortihm a bit more clever (and eg attack user names on certain hosts which are likely to exist. This could be harvested eg from email addresses...).
If you do some Googling, you will no doubt find the info on this in some security forums that I found when it first started on Port 22 a few months ago. A couple of people seet up "honey pots" and waited and watched... the result was that after one of the scripted attacks detects a well known account / password combination, the attack changes fromn being scripted to manual and a "root kit" is installed. The attackers were not good at covering their tracks in terms of command history, so that is what gave it away as a manual as opposed to a scripted attack. Here's a list of hack source addresses that I've recorded over a period of two months:-
SSH Hack source addresses ...
These will change at least somewhat, of course.
I checked one the other day and the IP was owned by a Korean University.
This is part of the reason why.
The guys that are not smart enough to spoof the IP when they try to climb in are usually on DHCP, or at a netcafe, or at a school where they are more than half likely to get kicked out.
So the suggestion of a temporary blacklist is probably the best. I might even set it shorter than two days, myself.
Joel wrote (about SSH attacks):
The guys that are not smart enough to spoof the IP when they try to climb in are usually on DHCP, or at a netcafe, or at a school where they are more than half likely to get kicked out.
I refer the honourable Joel to my previous response.
In particular, you can't really spoof IP addresses on SSH sessions. The server needs to be able to get packets back to the (possibly attacking) client, which means the client's IP address must be routable.
James.
On Sun, 31 Oct 2004 23:19:39 +0000 James Wilkinson james@westexe.demon.co.uk wrote
Joel wrote (about SSH attacks):
The guys that are not smart enough to spoof the IP when they try to climb in are usually on DHCP, or at a netcafe, or at a school where they are more than half likely to get kicked out.
I refer the honourable Joel to my previous response.
In particular, you can't really spoof IP addresses on SSH sessions. The server needs to be able to get packets back to the (possibly attacking) client, which means the client's IP address must be routable.
Okay, educate me. Why is a spoofed IP address known to be not routable?
Joel said:
On Sun, 31 Oct 2004 23:19:39 +0000 James Wilkinson james@westexe.demon.co.uk wrote
In particular, you can't really spoof IP addresses on SSH sessions. The server needs to be able to get packets back to the (possibly attacking) client, which means the client's IP address must be routable.
Okay, educate me. Why is a spoofed IP address known to be not routable?
-- Joel rees@ddcom.co.jp
Because generally it isn't of value to use as a spoofed address an address on your own subnet (a trace will get back to the correct network admin anyway, who can start capturing packets and figure out the true MAC address). Consequently, most spoofing attacks will probably use: 1) An address on the victim's subnet 2) A 10./8 or 192.168./16 address 3) A broadcast or multicast address 4) A 127./8 address 5) some other victims address (for a DDoS-type attack).
If the attacker is already on the same subnet as the victim, then #3 might help, but someone could still trace the attack by MAC, so why bother.
In my experience, most ssh attacks seem to be launched from systems that are already 0wn3d (if I'm using the correct terminology), so there is no point in trying to cover up where the attack is coming from.
-se
-se
On Mon, 1 Nov 2004 02:10:36 -0800 (PST) "Steve Ellis" ellis@brouhaha.com helped out:
Joel said:
On Sun, 31 Oct 2004 23:19:39 +0000 James Wilkinson james@westexe.demon.co.uk wrote
In particular, you can't really spoof IP addresses on SSH sessions. The server needs to be able to get packets back to the (possibly attacking) client, which means the client's IP address must be routable.
Okay, educate me. Why is a spoofed IP address known to be not routable?
Because generally it isn't of value to use as a spoofed address an address on your own subnet (a trace will get back to the correct network admin anyway, who can start capturing packets and figure out the true MAC address). Consequently, most spoofing attacks will probably use: 1) An address on the victim's subnet
Okay, that would not be routable, unless, or instance, the attacker 0wns the router.
2) A 10./8 or 192.168./16 address
And that should not be routable in from outside unless our gateway to the external net is built, well, cheaply, should we say?
3) A broadcast or multicast address
Which we assume SSH will reject even if some weird router let it through?
4) A 127./8 address
Well, if he already 0wns the box, he 0wns it.
5) some other victims address (for a DDoS-type attack).
"... (for instance, for a DDoS-type attack)."
If the attacker is already on the same subnet as the victim, then #3 might help, but someone could still trace the attack by MAC, so why bother.
In my experience, most ssh attacks seem to be launched from systems that are already 0wn3d (if I'm using the correct terminology), so there is no point in trying to cover up where the attack is coming from.
Which is kind of an important point. Especially if the 0wn3d box happens to be on the local net.
What am I missing? (I'm thinking of one more, but there are probably others.)
On Mon, 1 Nov 2004 02:10:36 -0800 (PST) "Steve Ellis" ellis@brouhaha.com helped out:
Joel said:
On Sun, 31 Oct 2004 23:19:39 +0000 James Wilkinson james@westexe.demon.co.uk wrote
In particular, you can't really spoof IP addresses on
SSH sessions.
The server needs to be able to get packets back to the (possibly attacking) client, which means the client's IP address must be routable.
Okay, educate me. Why is a spoofed IP address known to be not routable?
Because generally it isn't of value to use as a spoofed address an address on your own subnet (a trace will get back to the correct network admin anyway, who can start capturing packets and
figure out
the true MAC address). Consequently, most spoofing attacks
will probably use:
1) An address on the victim's subnetOkay, that would not be routable, unless, or instance, the attacker 0wns the router.
2) A 10./8 or 192.168./16 addressAnd that should not be routable in from outside unless our gateway to the external net is built, well, cheaply, should we say?
3) A broadcast or multicast addressWhich we assume SSH will reject even if some weird router let it through?
4) A 127./8 addressWell, if he already 0wns the box, he 0wns it.
5) some other victims address (for a DDoS-type attack)."... (for instance, for a DDoS-type attack)."
If the attacker is already on the same subnet as the
victim, then #3
might help, but someone could still trace the attack by MAC, so why bother.
In my experience, most ssh attacks seem to be launched from systems that are already 0wn3d (if I'm using the correct terminology), so there is no point in trying to cover up where the attack is coming from.
Which is kind of an important point. Especially if the 0wn3d box happens to be on the local net.
What am I missing? (I'm thinking of one more, but there are probably others.)
The point is that the original discussion talked about black-holing traffic based on ssh authentication failures. You can't get to ssh authentication (successful or otherwise) unless you finish TCP connection set up--regardless of whether an address is routable or not, in order for TCP setup to complete the initiator MUST RECEIVE packets sent from the attacked system.
Auto-black-holing traffic after receiving most DoS-type attacks is unsafe (and ineffective) because often the source IP addresses are forged and do not correspond to where the attacker is really coming from the hackers could force you to dropping traffic from nearly everyone, while auto-black-holing traffic based on communication AFTER TCP connection set up only effects the hackers (and anyone whose machine has been taken over--call it collateral damage).
Re-reading the discussion, I guess that the distinction that spoofed IP addresses on SSH sessions required two-way communication wasn't clear--my apologies.
-se
On Mon, 1 Nov 2004 11:16:27 -0800 "Steve Ellis" ellis@brouhaha.com wrote
On Mon, 1 Nov 2004 02:10:36 -0800 (PST) "Steve Ellis" ellis@brouhaha.com helped out:
Joel said:
On Sun, 31 Oct 2004 23:19:39 +0000 James Wilkinson james@westexe.demon.co.uk wrote
In particular, you can't really spoof IP addresses on
SSH sessions.
The server needs to be able to get packets back to the (possibly attacking) client, which means the client's IP address must be routable.
Okay, educate me. Why is a spoofed IP address known to be not routable?
Because generally it isn't of value to use as a spoofed address an address on your own subnet (a trace will get back to the correct network admin anyway, who can start capturing packets and
figure out
the true MAC address). Consequently, most spoofing attacks
will probably use:
1) An address on the victim's subnetOkay, that would not be routable, unless, or instance, the attacker 0wns the router.
2) A 10./8 or 192.168./16 addressAnd that should not be routable in from outside unless our gateway to the external net is built, well, cheaply, should we say?
3) A broadcast or multicast addressWhich we assume SSH will reject even if some weird router let it through?
4) A 127./8 addressWell, if he already 0wns the box, he 0wns it.
5) some other victims address (for a DDoS-type attack)."... (for instance, for a DDoS-type attack)."
If the attacker is already on the same subnet as the
victim, then #3
might help, but someone could still trace the attack by MAC, so why bother.
In my experience, most ssh attacks seem to be launched from systems that are already 0wn3d (if I'm using the correct terminology), so there is no point in trying to cover up where the attack is coming from.
Which is kind of an important point. Especially if the 0wn3d box happens to be on the local net.
What am I missing? (I'm thinking of one more, but there are probably others.)
The point is that the original discussion talked about black-holing traffic based on ssh authentication failures.
Actually, the original discussion, if we go back that far, was about reactive techniques for firewalling in general.
You can't get to ssh authentication (successful or otherwise) unless you finish TCP connection set up--regardless of whether an address is routable or not, in order for TCP setup to complete the initiator MUST RECEIVE packets sent from the attacked system.
True, and it doesn't do much good for a cracker to get a buffer overflow on http if he can't get the shell prompt back to the attacking box.
Auto-black-holing traffic after receiving most DoS-type attacks is unsafe (and ineffective) because often the source IP addresses are forged and do not correspond to where the attacker is really coming from the hackers could force you to dropping traffic from nearly everyone, while auto-black-holing traffic based on communication AFTER TCP connection set up only effects the hackers (and anyone whose machine has been taken over--call it collateral damage).
That's a point. Sometimes patience is a good thing. Thus the honeypot that someone mentioned, and using the honeypot to harvest evil IPs that actually pick up a two-way conversation, as was also mentioned.
Re-reading the discussion, I guess that the distinction that spoofed IP addresses on SSH sessions required two-way communication wasn't clear--my apologies.
I think the point was made, perhaps before someone tagged the "OT" on the front of the topic. But it's a point worth making again.
Speaking in an entirely theoretical vein, if I were to consider blackholing for, say, Amazon, I would want a whole security system with several servers doing honeynet and several other servers doing nothing but tracking troublesome IP addresses, timing them out, and lengthening the time out for repeat offender IP addresses. Initial timeouts would probably start at two minutes or so. And I might do the design and decide that I couldn't guarantee it would be fast enough to protect against a DoS. Or maybe the engineer babysitting the system would push the cost beyond the benefits.
In a not-so-theoretical vein, I want to set up some reactive techniques for my personal server. Attacks outweigh real accesses by two orders of magnitude right now, and it wouldn't really hurt anything if the thing were DoSsed while I was at work.
Permanent black holes are not a good idea, of course, and that was discussed. I don't think I'd use the two day timeouts that someone mentioned for his setup, I'd think more in terms of thirty minutes. Possibly lengthen that a little if I got repeats.
But your point, that we need to be _very_ careful about reactive techniques, is well worth repeating.
On Tue, 2004-11-02 at 11:04 +0900, Joel wrote:
Permanent black holes are not a good idea, of course, and that was discussed. I don't think I'd use the two day timeouts that someone mentioned for his setup, I'd think more in terms of thirty minutes. Possibly lengthen that a little if I got repeats.
I'm the guy who started out by describing his "fly-trap" technique with Portsentry and Shorewall and the poster of the two-day timeout. The reason I chose that period, iteratively and with careful trials, is that it resulted in (a) almost zero repeat attacks from IP addresses after being unblocked, and (b) only about 20 hosts in the entire Internet being blocked at any given time.
The key in this case is careful selection of the "hostile" ports. However, any given technique you choose will have its own quirks and should be tested independently. Starting testing out at an hour and then expanding to see the results is eminently reasonable; I just thought you should know that two days works like a charm with THIS technique and on MY web server, over the last two years or so.
Your mileage may (and probably will) vary, so of course test carefully.
Cheers,
I wrote:
In particular, you can't really spoof IP addresses on SSH sessions. The server needs to be able to get packets back to the (possibly attacking) client, which means the client's IP address must be routable.
Joel wrote:
Okay, educate me. Why is a spoofed IP address known to be not routable?
Yes, I over-simplified this. I should have said routable back to the client. Imagine you're sitting in Power Cable, Nebraska, attacking a computer in Nether Wallop, UK, and spoofing a computer in Henley-on-Todd, Australia. You send a packet to the UK, which replies to it. But it sends the reply to Australia: you never see it.
But you need to see data from that packet to be able to continue the connection.
Hope this helps,
James.
James wrote
I wrote:
In particular, you can't really spoof IP addresses on SSH sessions. The server needs to be able to get packets back to the (possibly attacking) client, which means the client's IP address must be routable.
Joel wrote:
Okay, educate me. Why is a spoofed IP address known to be not routable?
Yes, I over-simplified this. I should have said routable back to the client. Imagine you're sitting in Power Cable, Nebraska, attacking a computer in Nether Wallop, UK, and spoofing a computer in Henley-on-Todd, Australia. You send a packet to the UK, which replies to it. But it sends the reply to Australia: you never see it.
But you need to see data from that packet to be able to continue the connection. ...
I think I am fairly clear on SSH, that two-way conversation is key to making the security techniques SSH uses work. The two-way-ness probably needs to be emphasised here because some members of this list have not picked up on it yet. I suppose I'm not being very clear. But what is the technical difference between spoofing IP and simply temporarily using an IP that is not assigned to you?
For instance, in the example you provide, how do we guarantee that Joe Cracker hasn't 0wn3d the DNS server(s) that the computer in Nether Wallop is referencing? Or that he hasn't simply 0wn3d the box in Henley-on-Todd and thinks he has covered his tracks, so that he doesn't care whether the box in Australia gets removed from the 'net?
Admittedly, that's not simple spoofing, but the second case is not rare and the first case might not be all that hard to someone who has a grudge. And I think these two cases (and others) do apply to SSH (and SFTP and HTTP(S), etc.).
Steve does have a point, however.
I posited:
Imagine you're sitting in Power Cable, Nebraska, attacking a computer in Nether Wallop, UK, and spoofing a computer in Henley-on-Todd, Australia. You send a packet to the UK, which replies to it. But it sends the reply to Australia: you never see it.
But you need to see data from that packet to be able to continue the connection.
Joel asked:
I think I am fairly clear on SSH, that two-way conversation is key to making the security techniques SSH uses work. The two-way-ness probably needs to be emphasised here because some members of this list have not picked up on it yet.
Yes, this is true. But before SSH can do anything, it relies on the OS setting up a TCP connection. That is inherently two-way, too.
I suppose I'm not being very clear. But what is the technical difference between spoofing IP and simply temporarily using an IP that is not assigned to you?
Terminology...
For instance, in the example you provide, how do we guarantee that Joe Cracker hasn't 0wn3d the DNS server(s) that the computer in Nether Wallop is referencing?
DNS is used less than you think. The Nether Wallop computer gets a connection from an IP address, and replies to that IP address. It may do a reverse DNS lookup, but unless that's used for hosts.allow or for logging, it doesn't actually need it for the connection. SSH certainly works where there is no DNS, no reverse DNS, and (presumably) where you have one domain name pointing at mutliple IP addresses.
Or that he hasn't simply 0wn3d the box in Henley-on-Todd and thinks he has covered his tracks, so that he doesn't care whether the box in Australia gets removed from the 'net?
If he has compromised the box, he can remove it from the net quite happily *anyway*. He could, I suppose, set up a system whereby the Power Cable computer sent a packet as if from the Australian computer. The UK server would receive it and respond to the Australian computer, which would send it on somehow to the Power Cable computer. But this doesn't buy him much: while he's using such a set-up, his inbound packets are blocked after they trip the lockout (they look as though they come from the cracked Australian computer).
He does still have his own, valid, IP address to use. So he's got himself two IP addresses to "throw away".
But he had that anyway: it would have been much simpler simply to have probed from the Australian computer in the first place.
Now if you're suggesting that Joe Cracker has a network of compromised hosts, and can try things from one after another until he finds a valid connection, then you've got a better point. And I shouldn't be surprised if determined crackers do try different probes from different machines, simply to help them cover their traces.
(In my experience, too, casual crackers will try a particular probe against a wide swathe of computers. Then if they want to try another probe, they'll look at another swathe.
It takes more than a single probe for most sysadmins to report it, and it takes reports of more than one probe for ISPs to care about it. The casual cracker will feel, accurately, that it's very unlikely that there'll be enough complaints against him for any action to be taken. Such is life on the Net in the twenty-first century...)
James.
On Sun, 2004-10-31 at 18:19, James Wilkinson wrote:
Joel wrote (about SSH attacks):
The guys that are not smart enough to spoof the IP when they try to climb in are usually on DHCP, or at a netcafe, or at a school where they are more than half likely to get kicked out.
I refer the honourable Joel to my previous response.
In particular, you can't really spoof IP addresses on SSH sessions. The server needs to be able to get packets back to the (possibly attacking) client, which means the client's IP address must be routable.
James.
At what point does the system log the ssh attempt? If it is after the initial 3 way handshake then I think an ssh attempt could be spoofed without having to receive packets back from the target system. From what I can tell it appears that when you initiate an ssh attempt the standard 3 way handshake is started. You send a SYN packet, the target sends a SYN ACK packet. Normally since you would not get the SYN ACK packet the connection would not be completed. However if you manufacture a ACK packet and send that a few seconds after you send the SYN packet I think you would have a good chance of completing the handshake. If that gets logged as an SSH attempt then the active response system in place may block the spoofed sender IP address.
True, the sender would never get any packets back but that would not matter if they are simply trying to DOS a system using its own tools.
There are two questions I don't know the answers to without doing some testing: 1. When is the SSH attempt logged, after the initial handshake or later on in the conversation. 2. what happens when the machine who's address is spoofed gets a SYN ACK that is did not send?
I does not make any sense for the spoofed machine to send any kind of response to an unsolicited SYN ACK. I guess it might send a RST but since it is not waiting for a SYN ACK I think it would just drop the packet. This would work to the spoofers benefit since the machines who's address is being spoofed would not step on the spoofed packets being sent to the target machine.
So that leaves the question of how far down the sequence do you need to spoof the traffic to get the system to log an SSH attempt?
I agree that you would not be able to establish a complete connection with the system but then the topic that was being discussed was having a malicious hacker simply cause your own system to block important addresses from your own system.
On Thu, 2004-11-04 at 23:49, Scot L. Harris wrote:
At what point does the system log the ssh attempt? If it is after the initial 3 way handshake then I think an ssh attempt could be spoofed without having to receive packets back from the target system. From what I can tell it appears that when you initiate an ssh attempt the standard 3 way handshake is started. You send a SYN packet, the target sends a SYN ACK packet. Normally since you would not get the SYN ACK packet the connection would not be completed. However if you manufacture a ACK packet and send that a few seconds after you send the SYN packet I think you would have a good chance of completing the handshake. If that gets logged as an SSH attempt then the active response system in place may block the spoofed sender IP address.
I have tried that. You have to have your login and password transmitted before the log entry appears through syslog (which makes sense, as the credentials appear in the log as well). I believe it's pretty hard to "pre-guess" (what a word) the authentication/encryption handshake to spoof an IP ;-)
On Thu, 2004-11-04 at 12:14, HaJo Schatz wrote:
On Thu, 2004-11-04 at 23:49, Scot L. Harris wrote:
At what point does the system log the ssh attempt? If it is after the initial 3 way handshake then I think an ssh attempt could be spoofed without having to receive packets back from the target system. From what I can tell it appears that when you initiate an ssh attempt the standard 3 way handshake is started. You send a SYN packet, the target sends a SYN ACK packet. Normally since you would not get the SYN ACK packet the connection would not be completed. However if you manufacture a ACK packet and send that a few seconds after you send the SYN packet I think you would have a good chance of completing the handshake. If that gets logged as an SSH attempt then the active response system in place may block the spoofed sender IP address.
I have tried that. You have to have your login and password transmitted before the log entry appears through syslog (which makes sense, as the credentials appear in the log as well). I believe it's pretty hard to "pre-guess" (what a word) the authentication/encryption handshake to spoof an IP ;-)
That makes sense. Will have to find some time to look at this a little more. :)
On Tue, 2004-10-26 at 11:03, James Kosin wrote:
Everyone,
I've actually had to lock down most ports on my server; because, I got tired of all the attempts at attacks. Everyone, please use a firewall. I've noticed many attacks to the following ports: 111 -- sunrpc ** this effects Linux machines 135 -- DCE Endpoint Resolution 137 -- netbios-ns 139 -- netbios-ssn 445 -- microsoft-ds ** these affects samba services as well. 1433 -- ms-sql-s 1434 -- ms-sql-m ** I don't know why SQL ports are being attacked.
1023 -- ??? 5554 -- ??? 9898 -- ??? ** this group may be related to PCAnywhere, or Worm, etc.
The most active: port 445 by far!
Just giving everyone a heads-up on the security issues. James Kosin
James Kosin wrote:
Everyone,
I've actually had to lock down most ports on my server; because, I got tired of all the attempts at attacks. Everyone, please use a firewall. I've noticed many attacks to the following ports: 111 -- sunrpc ** this effects Linux machines 135 -- DCE Endpoint Resolution 137 -- netbios-ns 139 -- netbios-ssn 445 -- microsoft-ds ** these affects samba services as well. 1433 -- ms-sql-s 1434 -- ms-sql-m ** I don't know why SQL ports are being attacked.
1023 -- ??? 5554 -- ??? 9898 -- ??? ** this group may be related to PCAnywhere, or Worm, etc.
The most active: port 445 by far!
Just giving everyone a heads-up on the security issues. James Kosin
James:
A visit to www.symantec.com (yes this is the web site for Norton/Symantec Antivirus) reveals that most of the attacks are directed at known vulnerabilities in Microsoft Windows and/or Internet Explorer. The 'hit' on 111 (sunrpc) usually reveals what operating system you are running. However, a good firewall will stop these probes. BTW, there is a well known and patched vulnerability in most Windows products with TCP Port 445.
James McKenzie
-
Andrey Andreev -
dave -
David -
Elvis -
Eucke -
HaJo Schatz -
James Kosin -
James McKenzie -
James Wilkinson -
Jim Higson -
Joel -
John Aldrich -
John Thompson -
Leonard Isham -
Rodolfo J. Paiz -
Scot L. Harris -
Scott -
Steve Ellis