On the Definition of a Hostile Network Connection? 266
"I have since changed the default configuration to NOT use my own FTP site. However, I still receive around one email every day that my machine has been hacked and has been 'probing' or 'attacking' their machine. Often times, these emails are CC'd to my ISP (or sometimes only sent to my ISP).
Since when did identd lookups become 'attacks'? Most email servers use identd regularly ... how come there are so many firewalls out there that log this as suspicious activity?
Additionally, are there really that many ignorant network administrators who look at a log of one refused identd lookup and one refused active-mode FTP connection every night at 2 a.m. and not realize that something on their end is trying to connect to an FTP site every night?"
Shitty ISPs (Score:2)
Incidentally, is the term "DHCP leases" anywhere to be found in those nice pieces of paper you send new clients? No? And yet you blither this nonsense to them on the phone?
I'm sure glad you're not *my* ISP.
this is widespread - and usually fueled by idiocy (Score:2)
The source? ftp, by default (ie when not passive), connects back to the source of the first connection. Yes, this is to send the actual files back that the user asked for. That's right, users were complaining about connections that they themselves had initiated.
Someone must have written a windoze-based "hax0r detected" or something like that - the equivalent of script-kiddie-admin'ing.
Peer to Peers (Score:2)
They run a peer to peer and don't realize that, oh maybe the computers might have to CONNECT?!
We even had a script kiddie flood us for a connection, even though the punk had been on gnutella that same day!
I mostly put the blame on the companies that sell the firewall software for windows. The make this huge hype about those "evil hackers" and even bother explaining WHY machines might get REAL connections.
A better educated user base would be ideal, but I think I'm dreaming.
Re:Blame the Users (Score:2)
All that you accomplish by requiring an identd daemon, is that every user have another potentially vulnerable network port open. It gives every single sysadmin one more thing to take care of. A quick bugtraq vulnerability search shows that there have been five identd-related security issues since 1999, with the consequences ranging from DoS to execution of arbitrary code with group 0.
Why on earth would you want your users using a completely useless form of authentication, that exposes them to potential risks?
--
Misinformed.. (Score:3)
I've seen a fair number of articles describing how to set up a host-based firewall on Linux. Unfortunately, I haven't seen them address the problem of how to properly filter out uninteresting data like this.
--
Re:identd needs to die anyway. (Score:4)
And that would be bad because? Help me out here, I must be missing something...
not uncommon (Score:2)
certianly gotten several compliaints from users that ftp.debian.org is port
scanning them, or similar stupid misinterpretatons of a active mode ftp
connection. I forget if ftp.debian.org uses identd. We don't appear to get
quite the same magnitude of complaints that the author of autorpm does,
possibly because most apt users download via http, for ftp.
There is also another set of idiots who install debian and apache, and then
flame us for cracking their system and defacing their website. The debian
apache package comes with a default web page that prominently mentions
Debian, you see..
--
identd needs to die anyway. (Score:3)
If you ask me, identd is nothing more than a waste of bandwidth. Someone, please prove me wrong.
--
Re:identd needs to die anyway. (Score:4)
Yes, and watch the average Windows user's head explode while you explain to him that he can't get onto IRC or Yahoo Chat because his digital X.509 certificate isn't valid or is missing.
- A.P.
--
Re:identd needs to die anyway. (Score:4)
The pidentd ident daemon can do something quite similar if run with the -C flag. From the manpage:
So, when an ident request is made, the daemon returns an encrypted token that is useless to the other end without the key. If someone has a problem, s/h/it sends back the encrypted token, and the admin decrypts it and takes apropriate action.
This method has an advantage over the method you described if multiple users make connections to the same foreign box within the same time period. If one system is not using NTP (or other time synchronization), the time period could be as long as ten minutes.
Why is this a problem? (Score:3)
Not everyone wants to, needs to or has the time to know everything about network security. Don't jump down their throats just because they happen to care about the traffic traversing their networks.
but still (Score:2)
:)
hawk
Re:And the vendors, too (Score:2)
Over the years at companies I've been at we've tried to implement some of these desktop and server management tools.
They usually work, but not always and are sometimes more frustrating to try to setup than actually use.
Re:Blame the Users (Score:5)
Thanks. I really, really needed that image.
Re:And the vendors, too (Score:2)
It sounds like this really means roaming profiles under NT. These are stored centrally and copied to and from other machines in the domain as necessary when a user logs on and off. They are not deleted when a user logs off - instead they are cached. So this may just be an option to clean up the cache, which NT doesn't do and which is a useful feature.
Re:Yup, there really are that many bad admins... (Score:2)
The funniest part about the Solaris 8 install media (at least on SPARC; haven't messed with x86) is how you can completely skip the "installation" CD entirely, booting off Software 1 of 2 to fire off a more decent (but still irritating) GUI installer, or if you just run it over a serial console, you can burn through the text-only installer.
I still amuse myself being able to install a Solaris 8 system from scratch with that trick faster than my coworkers who use the "pretty" installer.
You think this is stupid? (Score:2)
Hack attacks on port 25... (Score:4)
Things to look for, (Score:2)
What should administrators really be watching for if they are concerned with potential hostile activity over the net?
Administrators should take whatever log their IDS machines produce and periodicly run some statistics on it (every day/week/month). List remote machines in decreasing order of the number of different alerts they produce.
Example:
remote.hacker.org 4 types
  smurf 127
 http-activeweb 54
 Napster_Command_Long 8
 Napster_Create_Account 1
But this is just one of the things to do, though I have found it to be one of the most useful tricks to definately mail down the ones that are scanning/attacking. And off cource you will have to go to your logfiles to find the corresponding entries to eliminate false positives.2 C3AF4F2snlbxq'|dc
--
echo '[q]sa[ln0=aln80~Psnlbx]16isb15CB32EF3AF9C0E5D727
Blame the Users (Score:5)
Nothing beats the one time I tried to telnet into an old shell, attempted to logon, and after login failed I realized it was a different machine. The admin somehow or another ran a finger query on the shell machine I was logged onto and sent me email demanding to know who I was and why I was connected to his machine. There are some psychos out there
Then again, you never can be too paranoid.
Me = clueless admin apparently (Score:3)
I'd semi automated this and at one stage was one of those that emailed Kirk without even realising that I had autorpm running on all my Linux boxen and that was what was triggering it.
I'd prefer to think of myself as over zealous rather then clueless.
I've since given up on the whole idea. Yes I managed to alert some people to the fact their machines had been hacked and they were very thankful for it. However that was not the norm and the time spent sending the emails (even once semi-automated) could not be justified by the results.
The norm was no response at all and often the worst offenders are the BIG ISPs in that department.
Eg. Telstra have a customer that regularly hits my network with broadcasts to a certain port which is presumably a misconfigured Innoculan (anti-virus) client. Do you think Telstra would bother to reply to me or pass on my message to their customer... Not likely!
Anyway in answer to Kirks question yes this is probably going overboard and admins should probably look at a combination of firewall logging and an IDS like snort to spot the true hostile activity.
I recently began running snort here and whilst I still don't bother reporting things at least I now have a better idea of what is thrown at my network each day and a MUCH better chance of picking up an attempted hack.
So far the most common malicious thing I see is an attempted exploit of LPRng for RedHat 7.0
I'll stop babbling now and Kirk you have my apologies for ever bothering you and my thanks for a great program.
ibiblio/metalab/sunsite experience (Score:2)
We developed a longish form letter that allows us to keep our cool and to try to inform the complainer that we are not, in fact, scanning his or her machine, but responding to their ftp requests (often requests that they didn't realize that they had made) or actually are the home of one of several vhost or vIP sites they barely recall visiting.
This works pretty well, but in one case (I can't resist) a self-styled "security expert for a major corporation" accused us of violating his/her privacy then enclosed a log that listed visits to sites that revealed too much about his/her medical concerns, bingo habits, and purchasing proclivities.
If
Re:Infallible (Score:2)
Wow, that's an awfully tall order... sort of liking asking people to come up with a car that can't be used to run into things. I might be wrong, but I think it would be impossible to have an Internet that is both "safe" and at all useful.
It just always seemed to me that, barring the script kiddies, the majority of people who use these tools seem to be hackers with malicious intent. Was the internet built with malcious intent as part of the protocol?
Not really... it's just that you always hear about the hackers and script kiddies. The fact that people are using these tools to conduct their day to day business just isn't very interesting news.
As for the Internet's design, the Internet was designed to allows computers to send and receive data, nothing more or less than that. The fact that the ability to send and receive data can be used to malicious ends is just an unfortunate fact of life.
Re:And the vendors, too (Score:2)
LOL, I remember working for a place that was trying to use InsightManager. They were trying to run the management station on someone's workstation (Win98). This person had to make sure to keep Insight Manager running throughout the day while they worked, and since MAPI is a big steaming pile of non-standard crap they also had to keep Netscape open so the darn thing could send mail. This has to be the stupidest system I have ever seen a network admin try to implement. Foul and unreliable.
Re:Blame the Users (Score:2)
Grr. Nobody used finger anymore, except in the rare case to run a .plan or pgp-key server. Unless you specifically know that a host is running finger is should not be assumed. Running the safe_finger rules from the tcpwrappers man page is, like, soooo 1992 8^).
Re:identd needs to die anyway. (Score:2)
Sure, from your network to your network. There should be no presumption that I am running ident on my internet-accessable hosts, and I don't presume that you are running ident on your hosts. I would imagine that only the very old-school and clueless would attempt, or pay any attention to, ident over the Internet.
Re:ibiblio/metalab/sunsite experience (Score:2)
That's cool. I read firewall logs for a living and I like it when I get the "form letter" when I make a mistake as opposed to the "flame letter". It always hurts when some uptight admin reams me for accidently reporting some bogus traffic. I think that my incident form letter is pretty mild "This may be a probe or just a misconfigured client, etc." but I still sometimes get unfriendly critiques of my admin ability, my family's genealogy, etc.
I'm just trying to make the Internet a more friendly place, and it's always better to deal with others who are sympathetic to the cause.
Re:What to look for. (Score:2)
Not everybody has the same attitude or security policy as you. However anyone who gets rude over portscans or portscan reports needs to get a life in my book.
Re:Zork and telnet as 'attempted unauthorized entr (Score:2)
I don't know what the UWEC admin said to you, but unless he was quite rude the response you describe was completely uncalled for. I manage many firewalls and if I see a connection attempt on port 23 to some random host I most certainly would question it and bring it up with the owner of the IP block that it came from. If it turns out to be nothing, then fine, but I should at least spend the effort to find out.
9/10 of the time, when I get a human response (mostly I get autoresponders from various ISP's ticketing systems), it is to report that the source machine was cracked and scanning and that they are very sorry, etc. Sometimes I get a generic, "It's fixed" message and rarely I get an abusive message from a person like you. I hate that.
Re:Blame the scare-mongers and vendor competition (Score:2)
May I suggest to the newbies that the best practice when you see anything you don't recognize is to first do the research (Google, SANS, etc.) to find out what it probably is. Only if you can't figure it out through a moderate amount of searching should you contact the source and ask. May I also suggest that if you are running a commercial IDS that you may wish to double check your findings with Snort (or at least be familiar with the Snort ruleset). Snort is merely programmed to work well for the people who use it and there is little pressure to "bulk up" the ruleset with a lot of spurrious signatures.
Re:Doh ! security is a process, not a product ! (Score:2)
Yes! And I say this not just because I work for small managed security firm [securepipe.com] (Please ignore the fact that the website is ugly, I know). If you don't understand how to build a firewall or IDS then you should hire someone else to do it as it is very easy to get wrong (the concept of least privilege is lost on 99% of all network admins who just want things to work). Security takes time to do right and requires constant maintenance (logreading, etc.), if you don't have the time or knowledge to do it right you are going to get burned.
Re:Scanlogd Logs SuSE's Yast as an "attack", too (Score:2)
That's me, the packet facist. While I do work from the assumption that any traffic that I haven't allowed is bad, I don't necessisarily believe that the traffic is evil. Every packet came from somewhere, unless you have really broken network equipment. In any case I believe that any traffic that you can't explain as good should be followed up with the source IP owner. But that's just me, the facist
Re:Why is this a problem? (Score:2)
Too true. Many people thought it would be the greatest if everybody used Linux, then balked at the flood of clueless newbie users. The same people balk when users try to inexpertly secure their systems.
Damned if you do, damned if you don't
Re:Firewalls for Flamers (Score:2)
I know that on all the firewalls that I build ICMP Echo requests/replies are blocked through the firewall as well as UDP. All of our protected networks are RFC1918 addressed, both ICMP and UDP are stateless protocols making NAT error prone or excessively difficult. It is impossible to prevent random packets from being injected into a UDP stream, for example, exposing their client machines to more risk. If the client has a legit request they can change their security policy (at their own risk), but I wouldn't allow anything by default that wasn't requested.
Re:Me = clueless admin apparently (Score:2)
Ich Auch! And that isn't such a bad thing.
Boringly normal. Even with a database of known good email addresses to override the crappy whois database I still only manage to get a 25-30% response rate (including autoresponders). I still file several hundred incidents a day (well, it is my job 8^). My experience: If you expect someone to jump every time you send an abuse mail you are expecting way too much. I believe that it is your responsibility as a good netizen to report unusual activity (probably from a rooted box). As long as the mail doesn't bounce, what they do with the information is up to them, it is not your problem (unless you are being DoS'd).
Caveat: You will run into the problem that you will never see the payload of any TCP connection that has been denied, making your IDS useful only for single packet UDP and ICMP attacks as well as TCP traffic that you allow (web, smtp, etc.).
Re:You think this is stupid? (Score:2)
That's not entirely true. daytime would be quite helpful in identifying ancient Unix boxes that actually run the service by default as well as defeating time-based protocols (like some bad auth systems). In any case I think that is suspicious but definately not panic-worthy. In fact, if you are denying the traffic very little is panic-worthy.
Re:Yup, there really are that many bad admins... (Score:2)
That's easy. You don't. 8^).
There are only a few ways to do this. You can:
- Configure the service to use a fixed port
- Use firewall with stateful inspection of the higher layer protocol stream
- Allow any high port to any other high port (ick, improper trust relationship)
- Or just don't and use something else that you can firewall properly
Many firewall products try to inspect the traffic as it is whizzing by but this is almost impossible to get right and very, very easy to get wrong. Most of the time you can inject crafted traffic into a stream and cause the firewall to 1) Crash, 2) Give up root, 3) Open arbitrary hole. This kind of attack can effect IDS systems as well, as they are grabbing an analyzing hostile traffic. I believe that PIX, FW1, Snort, and ISS have all had these kind of problems in the past. Given enough time and effort I'm sure more will be found in the future. Plan accordingly.Re:Crushing Crowds (Score:2)
That's a really bad analogy. The Internet is nothing like a crowded subway car, packets don't just bump into your external firewall by random chance. It's deterministic, somebody sent them for a reason, whether by mistake or by malice.
Having my machine scanned by cracked boxes and script kiddies, forgetting for a moment the limited number of professional crackers, is definately something that I would wish to bring to the attention of the IP owner. It's common courtesy and not "retarded". It's also definately not something to get your undies in a twist about, and not something that should cause you to forswear the Internet over.
Just like the "Real World(tm)" the Internet is full of garbage and assholes, gee . . . Imagine that.
Re:Pardon me? (Score:2)
You both should quit fiddling with your analogies, it's totally pointless. I believe that it is called "Arguing over Symantecs" 8^).
TCP ECN + active FTP == false positives (Score:2)
Active FTP looks like a port scan because all the "PORT" activity causes FTP to use many different sequential TCP ports to be used.
What to look for. (Score:2)
Although there is much furor over portscanning, I do NOT have a problem with it. Sure, my sniffers log it, and report it, of course.. it may be important information later.
Sounds like your admins feel like a straight guy in a gay bar... 'Why are all these guys looking at me! Make them stop!'
Admins who get uptight over portscans need to get a life.
Well.. (Score:2)
The point of ident was *never* to be a form of authentication, it was only a mechanism to find out which user was associated with a network connection, for email, mainly. As you say, if you trust the machine, you can trust ident....
The continual insistence on ident by EFNet is the stupidest thing I've ever seen, it serves absolutely NO purpose whatsoever, yet they insist on it.
Unknown servers (Score:2)
Of course, a little virtual host and mod_rewrite magic later they weren't generating 404s, they were getting rather unflattering images sent back. The problem fixed itself soon after that.
Re:Yup, there really are that many bad admins... (Score:2)
Just out of curiosity: how do you configure a firewall for those kinds of protocol? The principle of those protocols (Sun RPC, Java RMI, DCOM) is that the client does a first connection to a "naming service" (i.e. portmapper, RMI registry, etc.) which is on a fixed port, and then learns from that "naming service" which port the actual service uses. The latter being variable of course, which makes it tough to allow through the firewall.
Your remark seems to suggest that there is a general way of allowing those kinds of connections. Does it only work for specific RPC-like protocols, or does it also work in the general case? Wouldn't the firewall need to parse the actual "RPC-like" protocol to do it?
Yup. You'll need some kind of stateful firewall to do this right. The sad thing is that, to the best of my knowledge, no stateful firewall on the market deals with sunrpc or DCOM in a stateful manner. *sigh*
We had the problem here at work (both with java RMI and DCOM), and yes, we did eventually resort to opening everything between 1024 and 65535. If there is a cleaner way (i.e. a more selective way) to do it, I'd be interested.
Sometimes you can limit the range of ports that an RPC-like service will use at the cost of limiting the number of concurrent connections. Doing this, you could shift the RPC range up to about 60000-65000 or something, well out of the way of other services you would like to unconditionally block (X11, rplayd, Back Orifice, NetBus, Napster spring to mind, depending on administrative tastes). Yes, you're still letting a bunch of random connections through, but at least there's unlikely to be anything listening. Of course, if you're concerned about "Inside Jobs" (and you probably should be...) then this probably won't cut the mustard either. Life's a bitch. :(
Re:Likely cause (Score:3)
You'll have to blame more than the newly minted MCSE -- they don't know enough to check logs.
I should know, I've got one.
Re:There is a certification that does this. (Score:2)
True story:
A friend of mine works at a company near UC Davis, and had to interview 20-30 UC Davis students applying for a part time position. This campany makes network devices, so a resonable knowledge of networking was needed. Every single one of them was asked what a netmask is, and not a single one got it right. This was among a sample of students of all years.
So don't feel discouraged because you can't get a job with your shiny CS degree. You only have to proove yourself against the hordes of CS graduates with no clue.
Re:identd needs to die anyway. (Score:2)
Re:Pardon me? (Score:2)
A single connection request often indicates an automated scanner. Particularly with the linux worms, I will get a single packet every few days to different address in our range.
It could also be someone mistyping an IP or port, or some lemur doing <img src="http://somehost:53/foo">, or any number of things.
Whether I chase it up depends on the port. Current favourites are 53, 111, 515, 21 etc.
A TCP connection to port 53 could be someone looking for a zone transfer. That isn't anything to hide, you are publishing it to the world anyway.
I trust your RPC service (port 111) has suitable access controls that declines unauthorized access attempts. But it is not good to consider such connections "attacks," what if some new whizbang Internet P2P application uses RPC (ignoring the merits of using it). Are those users all of a sudden criminals because they had the nerve to ask your host if it could talk a particular protocol?
I do send an email to obvious scanners, mostly the owner hasn't a clue what is going on, and hopefully they will learn a bit about security and close the more targeted holes. In this case notification helps the user and (very slightly) reduces the easy meat for crackers.
Not having them lynched sets you apart from other admins apparently.
Crushing Crowds (Score:4)
Like on a crowded subway car, people bump into each other on the Internet. Connection refused? Pardon me.
Ideally the person at the receiving end should understand and get over it. After all, they have sent their share of bad connection requests too.
Now we have paranoid admins who cry foul whenever someone sends one lousy connection request, or sends on strange packet, or whatever. If you can't handle a crowded subway car, don't get on it. Likewise, if you can't handle sharing the Internet, don't get on it.
In that vein, port scanning isn't too horrible. If you don't want people to see what you are running, get off the Internet. Otherwise, you just have a storefront on a busy street where people can see if the store is open or closed.
Retarded administration causes more problems than port scanning ever will.
Scanlogd Logs SuSE's Yast as an "attack", too (Score:2)
Here's part of my scanlogd output, on my SuSE Linux box, when I did some package updating:
May 15 07:12:33 boxen scanlogd: 192.168.1.90 to 202.58.118.12 ports 4385, 4391, 4397, 4409, 4413, 4424, 4425,May 29 06:28:05 boxen scanlogd: 192.168.1.90 to 202.58.118.12 ports 1510, 1514, 1520, 1523, 1525, 1527, 1532,
Jun 3 22:07:02 boxen scanlogd: 192.168.1.90 to 202.58.118.12 ports 1741, 1743, 1745, 1747, 1748, 1750, 1752,
Jun 10 14:54:39 boxen scanlogd: 192.168.1.90 to 202.58.118.12 ports 3226, 3228, 3230, 3233, 3237, 3242, 3244,
202.58.118.12 is ftp2.suse.com -- but if I'm dumb, I won't know why an FTP session went through that many ports. Post something big on your website, at the very top, saying something like "click here if you think this box is attacking you."
But, face it. People are getting downright racist about packets. Any unknown packet is a bad packet, and it's just there to do something evil, and unimaginably bad.
Re:Not admins (Score:2)
But more to the point.. *why must* an FTP server run identd? To help debug what user connected? Well diddums, most machines don't run identds these days, not unless you're connecting to IRC all the time. The first thing that's wrong is bothering with identd checks on the FTP server; the next thing is having borked firewalls, and lastly, having lusers who use said borked firewalls. Save the whole issue, don't request the blinking lookup!
~Tim
--
Re:Blame the Users (Score:2)
Good and Bad... (Score:3)
On the other hand, the place I used to work at had a load-balancer, and someone reconfigured one of the parameters that had an unfortunate side effect: sometimes the back-end machines would talk directly to the client machines instead of the load balancer.
for example, a client would contact our load balancer VIP, which would rewrite the dest address and forward it to the back end machine:
1.1.1.1 --> 2.0.0.1 (vip) ----> 3.0.0.1
client[load balancer][back end machines]
Sometimes the load balancer would time out the association between the client and the back-end machine, but the back-end machine wasn't done with the connection. The misconfiguration allowed these packets to be forwarded on unmolested. So the client machine (only expecting packets from the 1.1.1.1 to 2.0.0.1 session) would get a replies from the "cracker machine" 3.0.0.1. This would trip all the firewall bells and whistles and we would get angry emails.
It was "pretty interesting" to get these uncensored email messages from the nice girls over in customer service. However, a couple people gave us excerpts from their firewall logs and we eventually figured it out.
Make 1/2 the symptom go away.. (Score:2)
It won't stop morons who complain about active FTP sessions, but it should cut down on the Ident lookup complaints.. (Do you really need Ident info anyway?)
Doh ! security is a process, not a product ! (Score:3)
If the key question is "What should administrators really be watching for if they are concerned with potential hostile activity over the net? " - then, this assumes a lot of things of the administrators .. to whom I would like to address these 8 questions
We build and install networks for corporate clients and our experience is that the answers to the above questions is generally - "No"
We therefore advocate an ongoing process of risk assessment and penetration testing leading to a consultants report.
If the report indicates that they are an "at risk" target, then an ongoing, outsourced IDS service is offered,
Of course, this is assuming that a corporate security policy is in place. Again, generally the answer to THAT question is either "No, we don't have one" , or some feeble "Well, I know how the firewall is configured, and I wrote all the router access-lists .."
I'll stop the "Security is a process, not a product" rant at this point.
The point I really want to make is that before the slashdot-admins go racing into Tripwire, Snort, Netranger and nmap-land, they should take a long hard look at these questions and answer them with critical honesty.
RE: Ident through NAT (Score:3)
You have a good point about NAT and ident. Let me address one situation where I had to deal with this:
- I set up an OpenBSD NAT box for a friend of mine, who happens to be an IRC (Undernet) junkie. Most (if not all) of the Undernet servers
- require ident before completing a connection. I would have just forwarded the port 113 if his room-mate didn't want to do the same thing...
To answer your question, ident certainly has value in a NAT environment. It can be a pain to implement (look into TIRCProxy, it does more than just IRC), but once established, it provides some accounting of who has done what. This can be the difference between pulling your hair out and simply plonking a user. I don't see this being much help in a business environment... but it certainly has recreational applications.but he did. Dammit.
That left me searching for something to make IRC work through NAT, and I found the "Transparent IRC Proxy [klaki.net]." It (optionally in conjunction with identd) handles ident requests, and returns a proper response based on entries in /var/run. These entries are quite simple -- they're just files named "user-n.n.n.n" and containing just the name to be returned for ident. Easy enough...
It makes DCC work again, it enables ident to properly identify NAT'd users, and (as long as you find an Undernet server that allows more than one connection per host) it allows two people to be on at the same time. End of problem.
NAT is a necessary evil right now. Hopefully, once IPv6 is in widespread use, ISPs will no longer be as stingy with the address space... and then it'll be a simple function of routing. Until then, I hope this helps.
Re:identd needs to die anyway. (Score:4)
Ident has its uses...
- IRC (your point)
- The previously mentioned email servers
- uh.... something else...
- (this space for rent!)
Seriously though, there are actually useful applications for identd, and most involve making sure you legitimately use the machine in question, and it's not just redirecting traffic on a certain port. I can't name another service that fills the niche that ident does -- I always thought of it as the internet's version of a BBS call-back. Everything else I know is on a case-by-case basis, and nowhere near as ubiquitous as ident is. That is ident's power.Also, current use is a far cry from the original intent of the daemon -- that's for sure. There was a time when an ident reply contained a valid email address. I know there are still some valid answers out there, but I know I've never taken an ident reply seriously. These days, either you get a reply (and the info is probably garbage), or you don't.
You can thank the those windows users (like myself at times) for that. Heck, when I first started using IRC, I had no idea what ident was, and I didn't mess with mIRC's settings... thus, whatever you saw was nearly the same as ten thousand others, and even more useless.
The fact that sysadmins now treat ident requests as 'attempted crack attempts' or (potentially) 'hostile network connections' says
- They don't appreciate the use of identd
- It's too much work to maintain and use it
- It's another port open on the firewall to that mean, nasty internet
- They're privacy freaks, and you don't need to know the username, you privacy-invading corporate whore, you!
You know, Wakko... I can't say I disagree with you. But do you have another idea for a lightweight 'that connection was authorized, here's who is accountable' mechanism?(Pick one, pick 'em all, your choice!)
Re:Blame the Users (Score:2)
But no compliants about telnet. An unfortunate problem of "Wingate Scanners" used on some IRC networks is that they probe TC port 23.
Things to do with smb portscans (Score:2)
Using the conclusion that if their computer is scanning me on these ports without their knowlegde (hey, not *everybody's* a script kiddie knowingly) I then fire windows explorer up and attempt to connect to the IP with SMB.
If I connect, I check out their shares and if there is a printer available, I install it on my system then print them a message. If I can't find a printer, I drop them a text file in their startup folder.
Normally something like :
I find this passes the time nicely on those slow afternoons.
I had a user of a computer I dropped this note onto get in touch, and he said I shoulda seen the look on his face when this note came out his laser printer.
He has secured his system now
Just doing my little bit to help
** Windows has detected a mouse movement.
Re:identd needs to die anyway. (Score:4)
The current IDENTD information is useless for the 'remote' site, but it can be invaluable to the 'local' site if a complaint is received. Not everyone is a single-user PC - if you're running a host with multiple users this can give you valuable information about who could be responsible. (Or at the least, who might have had their account cracked.)
There's also some proposals floating around to extend the IDENTD payload to include real authentication information. Having IDENTD pass something like an X.509 digital certificate that you can check might actually be stronger than using SSL/TLS-enhanced FTP that only uses anonymous connections.
!= System Administrator (Score:2)
I suspect that this is the case - ignorant linux users trying to be cool and intelligent with their new-found interest. To no fault of their own, really - they're simply not informed yet.
-------
Caimlas
Re:Blame the Users (Score:2)
I code on a irc daemon for a large network, and I get forwarded emails from people who accuse the network of "attacking" them with ident. These people need to learn about the risks and understand why these products say that ident can be a security problem (it "leaks" information about your username if configured correctly) and why it probably isn't in this case (irc uses it for a weak form of identification, and on a windows machine it's probably what you put in the "what do you want to show as your ident?" box)
OT: blame personal firewalls (Score:2)
This exact same problem, except with windoze luzers instead of supposedly clued linux luzers, blew up at an ISP here. The sysadmins had configured most machines to never send IDENT, but the secondary DNS/backup mailserver were overlooked. During the migration to a new power circuit, the primary was removed from the net[uptime 183 days], and everyone switched over to the secondary. The support lines were clogged with windoze luzers running ZoneAlarm, BlackIce, or Norton. Complaints of "every time I check my email, your machine tries to hack into mine" started to stack up. Since the sysops had the monday off after working the entire weekend, it wasn't until today the problem was fixed.
I heard that the practical joker support guy told the most whingey luzer that failing to respond to IDENT was a serious violation of the law, as only 133t h4x0r5 would try to hide their identity. He pointed the cluzer to RFC821 and a few others, and told him if he continued to block port 113 with an illegal h4x0r firewall, they would ToS him. Luzer went away, presumably chastised.
I'll have to shout the monks some liquid recovery tonight.
the AC
Re:You think this is stupid? (Score:4)
And you thought you were being funny, didn't you?
Re:Pardon me? (Score:2)
A zone transfer *is* something to hide. The only people who should be looking for a zone transfer are your secondaries. Either they are already allowed, or you have none. No one else should be requesting a zone transfer. Allowing them is stupid because you now allow in any bugs that are associated with dns zone transfers.
There are FAR FAR too many known attacks against both bind and rpc to assume that either of these are accidents! Should I assume that some luser is not trying to attack when I see ports: 31337, 27374, 12345?
I scan my home logs everyday. I see tons of attempts on all of these ports. I pretty much ignore them because I know that they're not succeeding. But that isn't the point. They are attacks. IMHO SensitivePortHits - Accidents is about equal to SensitivePortHits.
--
Re:Pardon me? (Score:2)
You've never been responsible for administering a secure system have you? If you have, then you're miserable at it. Read some. I'd recommend "Firewalls & Internet Security" [aw.com] by Cheswick & Bellovin. Or "Building Internet Firewalls" [oreilly.com] by Chapman & Zwickey. Both of these books describe one of the primary security priniciples: "least privilege". In short it says, don't allow anything that you don't have to.
If you have to allow DNS queries, then you have to. But just because you have to allow those queries doesn't mean you should also allow zone xfer. It's quite simple arithmetic: the number of security holes in DNS queries is less than the number of security holes in DNS queries + the number of secrurity holes in DNS zone transfers.
No, but when people come poking at my alarm system to see what happens, especially when they have no reason for doing it, I can't help but assume that they're trying to figure out my weaknesses for some other reason.
Your analogy is collosally bad. It assumes that you can look at my computer, without it impacting my computer. In the store analogy, you are of course correct, simply looking at the store to see if its closed is not criminal. But looking at my computer, requires that you actively use bandwidth that I PAID FOR, and make use of computing equipment that I PAID FOR. You are already impacting my expenses. You should have *no* expectation that I'm providing DNS zone transfers, therefore you should not go looking. You should also not probe my syslog ports, nor my printer ports, nor my RPC ports.
Looking to see if the store is closed is one thing. Peeking through the window to see where the safe is kept is another thing altogther.
You are an id10t. 31337 is the TCP connect port for BackOriface. 27374 is the TCP connect port for SubSeven. These are remote controllable trojan horses that have been widely spread through email virii. Anyone connecting on those ports, should by default be seen as hostile.
The original intention of the Internet also included the idea that no for profit organizations should be on the internet. The original intention of the internet included bugs. So, according to you, we should simply drop all prudence because someone 30 years ago couldn't forsee everything that would be happening today?
No. I think the deal here is that you want to continue running your port scans and justify it under the heading of "well it's just the way the Internet is sposed to work". Maybe. But do that to my machines and I will make trouble for you. Don't like it? I don't care.
--
Re:Likely cause (Score:2)
Working as a consultant for an ISP for a while, I had to handle complaints about perfectly legitimate ICMP Unreachable Fragmentation Required messages being returned, by nimrod sysadmins who apparently programmed their routers and firewalls by the "ride madly in all directions" method. ("Don't Fragment" bit set? Duh. Expect them then...)
Re:Blame the Users (Score:3)
This is a sign they copied the "how to log suspicious connections" man page info associated with TCP wrappers (I forget which man page exactly - inetd? hosts.allow? hosts.deny?). The example given tries to safe_finger any detected rogue connection except other fingers (which could cause and endless loop of mutual fingering to start).
I don't know if it is a good or a bad thing (in terms of what this /. article is about) that the example usually fails to work on Linux distributions I've used, notably Red Hat, because TCP wrappers was compiled with options that need a different format.
But: To anyone else out there that uses the example in hosts.deny - guess what? Because TCP wrappers errors out on that line you let the connection in as a result - it never gets to the usual "ALL: ALL: DENY" at the end!
Re:Information is the key (Score:2)
Isn't everyone an expert. I've been a firewall engineer while I studied (and still study) for my CCIE, and I can determing what's what. I've used Cisco Pix, Gauntlet, CP-1, Netscreens, you name it, and not once have I decided to ring the alarm because of connection attempts.
This is typical of people who don't understand networking, and security, period. Look before you leap is the old saying. So how is a simple connection, remember they're not a complete handshaking connection, going to cause you security issues? I've been so tired of hearing the typical bs. It's like when I'm on IRC, and some jackass swears someone is portscanning them for checking ports 8080, 3128, 80, when all thats being done is a quick proxy check,
Solution, don't get on the net if you're paranoid. Many things can seem to be intrusions, if you don't know how to weed them out, and especially if it's your job too, maybe you should take some classes in networking, and or security.
Cause, Effect, Solution (Score:4)
First it was port-scanning, now it seems that admins are crying wolf at any unknown client that connects to their network. Now I'm all for a dose of healthy paranoia, but is this going overboard?
You should have included somewhere on your documents, perhaps the FAQ, as to what exactly is being done by the client to ease the fears of clueless admins who ph34r j00. Seriously, place a quick Q&A as to why it connects to your site, for those who are too stupid to lsof|grep TCP && lsof|grep UDP to see nothing is happening.
After than make an autoresponder that points them to the url, after that case closed. Should they continue to harass you, then create a template complaint letter including what your program does, then fire it off to them and their upstream, and or bosses, to let them know your program is not some uber 31337 h4x0rspyw4r3 program on a mission.
I'm sure after they realize how stupid their concerns are, they'll piss off, or their bosses will rip em for being clueless admins.
Re:Blame the Users (Score:2)
Well, that would be me...Seriously, a single attempt is probably not enough to warrant the attention of the sysop. However, you say it was an "old shell". That would imply that you had no real business being there in the first place...right?
Take for example a recently released (and disgruntled employee). How often is somebody released from a company and the IT department is the last to know? Just why did that former employee log into an account that should have been terminated (just like they were)? As studies have shown, most attacks against corporate systems are by disgruntled workers. Personally, the admin who caught you should be commended for due diligence.
But, when is "enough" enough all ready? Do I freak on IDENT connections? No. Do I give a rats ass about ftp connections? Not until I see a repeated pattern or coupled with other activity (such as a full nmap SYN scan). Telnet or SSH attempts? I'm a little more wary and more opt to keep a closer watch. Of course, we should all be running SSH anyway if you leave our public interfaces accessible...right?
Now, onto the subject of port scans. If my computer where a house and a cop saw you going door to door checking the locks, you can be damned sure they'd stop you. It's called "probable cause". Since the laws on the books make it very hard to stop network attacks, the only real recourse is to report the attacks to their ISP. If their ISP is responsive, they are probably knocked offline for 24 hours or so. If it was innoculous, their access is restored. If not, then the little bastards have to find another ISP. Piss 'em off? Tough. That's one less cracker I have to deal with during their "cooling off" period.
Paranoia (Score:2)
Which would acomplish nothing of note.
The thread seems to be "educate the users and admins, and life will be good." But where does it start? Another module in the rubber stamp MCSE that they will promptly forget? Big bold headers in the Personal Firewall manual (that the (l)user will never really read) saying "Not every connection is hostile!"
Who's going to teach people?
(l)users don't read
I guess the addage is true: Some people really are too stupid to use the internet...
Re:Yup, there really are that many bad admins... (Score:2)
Just out of curiosity: how do you configure a firewall for those kinds of protocol? The principle of those protocols (Sun RPC, Java RMI, DCOM) is that the client does a first connection to a "naming service" (i.e. portmapper, RMI registry, etc.) which is on a fixed port, and then learns from that "naming service" which port the actual service uses. The latter being variable of course, which makes it tough to allow through the firewall.
Your remark seems to suggest that there is a general way of allowing those kinds of connections. Does it only work for specific RPC-like protocols, or does it also work in the general case? Wouldn't the firewall need to parse the actual "RPC-like" protocol to do it? We had the problem here at work (both with java RMI and DCOM), and yes, we did eventually resort to opening everything between 1024 and 65535. If there is a cleaner way (i.e. a more selective way) to do it, I'd be interested.
Just for the script kiddies that may be listening: no, this is not our Internet firewall; it is just a firewall between two internal machines... Don't ask me why they put it there, sometimes our security department is a little bit paranoid...
Re:Yup, there really are that many bad admins... (Score:2)
I see. However, in our case, this wouldn't help, as the machine supplying the DCOM services and the RMI services are known in advance
Actually, wouldn't this "established" be a security hole in its own right? An attacker could make a connection to port 80 of the corporate Webserver (allowed because that's where http listens), and then make another one to port 23 (allowed, because of the already established connection to port 80).
Re:identd needs to die anyway. (Score:2)
I've never understood why ident responses aren't all the same "The connection in question has been logged." (or maybe just "0")
Then, if a human actually determines that there is a need for this info, he contacts the admin of the other box and has him get it out of the log.
Something like:
To: postmaster@bad.guy
From: Joe_Admin@good.guy
Subject: What gives?
Hey, postmaster, whoever made the connection from bad.guy to good.guy:23 is a bad guy. You should delete his account.
So, postmaster looks at the log (generated only because good.guy made an "ident request") and sees who the real bad guy is.
In my head I call this shydent.
-Peter
Re:Yup, there really are that many bad admins... (Score:3)
*sigh*
Oh, which add solaris to the mix. With the new GUI installer I have seen people who are scared of a unix command line point and click their way through the Solaris 8 install.
These "enabling" installers that are around these days REALLY scare me.
it's not the admins that are emailing you (Score:5)
- have more pressing issues to resolve than failed identd queries (e.g. exhaustive network probing, exploit attempts, etc.)
- have a clue (i.e. that an identd query probably corresponds to a client connection, and that identd lookups at a regular interval are probably from a cron job or similar)
When I ran a single workstation on my desk in college, I had plenty of time to write huffy emails each time a line was added to- screen the network with a firewall
- run an IDS (Snort http://www.snort.org)
- (largely) ignore all the crud that bangs into the firewall each day
Here's what this lets me do with the scenario described above:When I run end-of-period reporting against the IDS logs, the nightly identd query shows up as a traffic spike. That night, I set the network sniffer to log all traffic to and from the "suspicious" external host/network. Bingo! The outgoing FTP client connection is logged as well. The owner of the offending workstation gets a phone call to find out if they know about their cron-job.
Zork and telnet as 'attempted unauthorized entry' (Score:4)
After a quick Google search, I located a link to a Zork server at University of Wisconsin, Eau Claire. The link was on an official university page about computing history.
I tried connecting to it, but, not surprisingly, it failed. I tried from another machine, still no luck. End of story.
Or so I thought. A few days later, I get a notice from my ISP warning me for trying to crack a machine, the machine I was telnetting to at UWEC... Luckly for me, my ISP is geek friendly, and my connection was not terminated on the spot.
I was pretty pissed, so I tracked down the email of the stupid a#$%!, incompetent and amateur admin responsible for notifying my ISP. I sent him a long, formal rebuke of his position that I was attempting 'unauthorized entry' and vaguelly threatened legal action if he did not retract his email. Needless to say he did.
However, how many other people, less internet savvy than me, would innocently click on some link found in a search, triggering a termination of their internet connection for no good reason? For me, loosing my internet connection would me a loss of tens of thousands of dollars that I earn doing remote development. Not to mention the damage to my professional reputation that would occur if I were thought of as a 'cracker'. Given that a large chunk of my consulting work involves security, that would be very hard to overcome.
I think that people who are admins need to be realistic. If you put a machine on the net, you will get people connecting to it in ways you don't expect (ports 139 and 53 come to mind...). If you react like the admin did at UWEC to harmless and random connections, then you will eventually do damage to either someone's business or reputation (or both). And that could very well lead to a lawsuit.
My servers get portscan about 2-3 times a day from various random IPs worldwide, I'm sure most of them have fairly hostile intents. The fact is that the net has become MUCH more hostile in the last five years and has MANY more clueless users. If you can't accept that, can't build procedures and systems that can handle that, then you are in the wrong business.
Quit now.
-- CKM
internet systems architect - scalability - commerce
Re: Ident through NAT (Score:2)
wow, that's a lot of trouble to go through for identd. personally i just use either fake identd [freshmeat.net] or null identd [freshmeat.net]. both allow you to have ident send an arbitrary string that satifies IRC servers.
both of these utilities are a testiment to how useless ident is for any purpose. it's far too easy to fake an ident response.
- j
Re:Likely cause (Score:2)
Personally, I don't consider a connection "hostile" unless there's an actual connection made (thank You Wietse, TCPWrappers is a Godsend) from an unauthorized host, or
As for the "healthy dose of paranoia," I've been informed that this is a professional requirement for a Unix admin
Regards,
ninewands
Re:Yup, there really are that many bad admins... (Score:2)
Only thing wrong with this sentence is that it restates the obvious.
In my own personal experience, I'd say that 1 in 20 are worth the space that they occupy. One in 100 would fall into what I would classify as a true senior level admin.
I think you're a tad bit over-optimistic. I regard a TRUE senior Unix admin to be a "Unix God" type
The rest of them are just an accident waiting to happen.
I'm sort of a mid-level Unix admin and still find myself feeling this way.
[SNIP the firewall stuff. It's an amusing story, but not relevant to what I'm writing]
The really sad thing is that most of these admins pull 60-80K/yr (in the us) and think that they know everything. Ah, the ignorance of youth (even the 40+ year old ones who still dont have a clue). You see, the more you know, the more you know that you dont know everything.
Here's MY point. The more I learn, the more I learn how LITTLE I know. Hell, here lately, I've even found myself reading "man ls" and "man ps" at work looking for nuances
The hard part for me is that with all of the gui's now dominating the server market, the level of knowledge required to get a system up and running is getting lower and lower. A trained monkey can install NT and most of the linux based distros out there nowadays.
This is not bad
And as soon as they can do that, they add 'system admin' to their resume and try and go for the big bucks. And they can play that game till something serious comes up and they discover what vi is and then they discover that they have no idea of what single user mode is or how fsck works. At that point the game is over and the company that they work for discovers that they didnt hire a senior level admin, they hired a trained monkey.
This is the employer's own fault for giving the HR drones the authority to "screen" applicants. This results in the hiring official only meeting those who fit through the HR dept's round hole. Because of this, the newly-minted MCSE (or Sun Certified System Admin) makes it through while the ancient geek who beta-tested Windows 2.0 but never bothered with certs doesn't
[SNIP most of the rest]
In the mean time, all we can do is hope that companies start to find some way to tell when an admin really knows their shit and when they just know how to walk through the mandrake gui install.
The only way this is going to happen is for the technical managers to take back the initial screening of candidates from the HR drones. As long as your candidates have to fit in the cookie cutter to get past square one all you'll get is interchangeable parts
Regards,
ninewands
Re:Shitty ISPs (Score:3)
When I was on the Helldesk, I got a call from a user who wanted to know why her e-mail didn't work. She had installed Norton's PF and her neighbor, "who's a computer pro at ***** Co." had configured it for her. Of course, he blocked OUTgoing traffic on ports 110 and 25, so she couldn't connect to our POP3 and SMTP servers
Because of company policy, I was prohibited from walking her thru the fix, so I told her what needed to be done and told her to have her neighbor fix it.
Re:identd needs to die anyway. (Score:2)
Actually, it's a (mild) security risk. From the nmap(1) [insecure.org] man page:
Nmap allows one to do exactly that with the -I option.
Re:identd needs to die anyway. (Score:4)
If you ask me, identd is nothing more than a waste of bandwidth. Someone, please prove me wrong.
ident is useful because it allows you to ask a trusted computer which of its users is making a connection. As a practical example, I use ident to authenticate users to PostgreSQL databases.
The details: my system uses Apache's SUEXEC to run different virtual hosts under different UNIX users. Since the information from identd can be relied on (it's trusted since it's localhost and fakeid support is turned off) I use pg_hba.conf and pg_ident.conf to configure what UNIX users can connect to what databases as what PostgreSQL users. Then end effect is, I don't have to embed passwords in my CGIs where I would have to otherwise. I could even seperate the SQL server to a different machine and still not have to specify passwords, as long as SQL machine trusts the webserver (it would, since I would own them both) and the network between (I would have them on the same subnet).
Re:Yup, there really are that many bad admins... (Score:3)
It's a little known fact that Ken Thompson added fucntionality to ps and ls which occassionally adds or removes an option at random from executable and man page. This allows, over time, for more possibilities than there are characters available.
An experienced user will usually be able to schedule their work so as to fit in with the functionality changes.
_O_
What I love... (Score:5)
Education, Education, Education (Score:5)
Maybe it's just me, but wouldn't it make more sense (perhaps with "Internet 2" or any of these other projects) to create infallible network protocols/tools that can't be used for malaciousness? Or is this logically impossible?
It's not a logical impossibility. Practically, however, it is impossible - IP only works because it is a nice lightweight, easily-routed network protocol. If one were to extend IP or redesign it to try and prevent any misuse, you would almost certainly find it became too heavyweight for it to work successfully at the global level. Not to mention that someone would eventually find some minor chink in its armour and start exploiting that instead...
However, there's all sorts of things that one can do to make the IP world a safer place. Number one, and probably the best example, would be for all network admins (and router manufacturers) to turn on source route verification by default at their border routers at the very least. What this does is get the router to verify that the source address of a packet headed to an external destination is in fact inside the netblock that the router 'owns' before forwarding it to the next hop. If every network admin would do this, then packets with a spoofed source address would never get any further than their nearest border router, and the internet as a whole would be an awful lot safer. This isn't a new idea and the capability to do it is probably in every router made in the last 5 years at least. Certainly any modern Linux kernel can do it. However, some manufacturers of both router hardware and software routing solutions still insist on keeping it set off by default, and combined with clueless network admins who don't know to switch it on, the problem remains.
The problem is thus not one of inadequate technology (although IPv6 addresses some security concerns too) but rather one of education...
Re:Paranoia (Score:3)
"Who's going to teach people?"
and then you say,
"I guess the addage is true: Some people really are too stupid to use the internet..."
You wouldn't work for me for very long. You start by talking down and being condescending to novice administrators, then proceed to bash the MCSE certification and all the while saying .. Some people are too stupid to use the internet.
Not a very well thought out and educated post. You'd rather talk down to your fellow administrators then help educate them? Let me guess, you are one of those types that sit on #linux and laugh at every question asked and say RTFM?
I might suggest some firewall and packet filtering resources, even prepare some type of form letter to send out to administrators that inquire as to the source of packets to their network. Or prepare a web link documenting the services (active FTP, Gnutella, etc.) These are all quite constructive options.
Do me a favor, save Slashdot and our readers bandwidth and don't post.
-Pat
You got attacked on port 25! (Score:4)
When they send you email about identd, send email to their ISP complaining about unauthorized use of port 25.
(You may want to read RFC 821 [faqs.org] if you don't get the joke.)
READ: TCP/IP Illustrated guide = informed paranoia (Score:5)
Firewalls for Flamers (Score:4)
The paranoia goes beyond casual users. I cant ping outside of our LAN at work. Our admin never could explain the reasoning for it, but its very annoying.
An actual conversation with a friend of mine:
Me: "Hello"
Them: "YES HELLO! I installed a firewall and its blocking all kinds of stuff!"
Me: "Yeah, what?"
Them: "UDP, ICMP, some packets, hackers... bad stuff"
Me: "Why are you blocking UDP?"
Them: "Because you should always use TCP, its better"
Eh....
Yup, there really are that many bad admins... (Score:5)
Let me tell you, there really are not that many good ones out there.
In my own personal experience, I'd say that 1 in 20 are worth the space that they occupy. One in 100 would fall into what I would classify as a true senior level admin. The rest of them are just an accident waiting to happen. All of them go around trying to sell themselves as 'senior unix | network system administrators'
The problem is that many of these places setup the firewall and block everything. all ICMP packets included. they dont take the time to learn what they should block and what the consequences are. they just block everything. Then when something does not work, they open things up till it does. For a good time, check out the firewall config of an admin who setup an exchange server that sits behind a firewall. Chances are they had no clue what the 'established' keyword was and just allowed ports 1024 through 64k. (in the cases where their firewall did not automatically recognize that exchange works in a fashion similar to rpc)
The really sad thing is that most of these admins pull 60-80K/yr (in the us) and think that they know everything. Ah, the ignorance of youth (even the 40+ year old ones who still dont have a clue). You see, the more you know, the more you know that you dont know everything.
The hard part for me is that with all of the gui's now dominating the server market, the level of knowledge required to get a system up and running is getting lower and lower. A trained monkey can install NT and most of the linux based distros out there nowadays. And as soon as they can do that, they add 'system admin' to their resume and try and go for the big bucks. And they can play that game till something serious comes up and they discover what vi is and then they discover that they have no idea of what single user mode is or how fsck works. At that point the game is over and the company that they work for discovers that they didnt hire a senior level admin, they hired a trained monkey.
So yes, you are screwed. If your ISP is nice, you can send them an email telling them to discard any emails that they get of 'attacks' from your ftp servers. If it goes to the right network admin (one of the 100) then you can probably sit back, smile and respond with an automatic 'hey stupid, please read rfc bla, bla and bla and then write back when you get a clue as to how ftp works and what your firewall is doing.'
In the mean time, all we can do is hope that companies start to find some way to tell when an admin really knows their shit and when they just know how to walk through the mandrake gui install.
Re:You think this is stupid? (Score:5)
I had sent an email to my wife and mistyped her address.
...are there really that many ignorant... (Score:5)
Re:Likely cause (Score:3)
While working at an ISP, we received a demand from the Supreme Courts, complete with logs, that required us to stop "attempting to break in" to their network. Oddly, they were only concerned with our nameserver (thousands of customers, dozens of servers, and they're worried about our dedicated nameserver??)
Twice we threw their request back, pointing out that these were low-volume, and actually being BLOCKED by their firewall. Curiously, they were all UDP port 53, and coming from all over the Net.
When they (twice) refused to believe us, and then pointed out that it was still occurring (predominately late in the afternoon, especially Friday), we pointed out that that these were probably legitimate DNS requests, being blocked by an over-paranoid firewall.
In the end, the administrator told us he understood that it was not an attack, but was at a loss how to explain this to the manager who started all the grief in the first place. Eventually, at our gentle suggestion, he simply turned off logging of those particular packets.
The manager then saw that the logs were void of "attacks", and his reports to upper management were clear. Clue was redefined, and duly distributed.
So, do not be too quick to blame the poor sysadmin! Often, all they need is a little non-technical assistance.
Dear Sir, (Score:4)
Re:And the vendors, too (Score:3)
Setup the WBEM HTTP server to automatically configure local IP addresses as part of the ADMINISTRATOR group. This means that any user with access to the local console will be granted full access to the WBEM components, without being challenged for a username and password. (ON)
Automatically delete user directories that have not been accessed within the last days. This is an effective mechanism for only keeping information on the system for active users. (ON) (WTF! Oops, last years holiday photos just disappeared. Junior, did you delete dad's pr0n collection?)
Allow the WBEM HTTP server to participate in HTTP auto-discovery of managed nodes. If enabled, the WBEM HTTP server will broadcast HTTP auto-discovery packets every (default 1) minute(s).
Allow the WBEM HTTM server to participate in HTTP auto-discovery of managed nodes as a Master HMMD. (ON) (This probably means something, but not to the average compaq customer)
Re:What I love... (Score:3)
What a bunch of losers! Everybody knows that the internet is Internet Explorer.
And the vendors, too (Score:4)
Anyone can point their web browser to the luser's machine, and have a look at the HW, even kick off HW diagnostics. Wonder how many of these eventually end up as script kiddie fodder.
Re:Ok so how do I manage a firewall? (Score:3)
and then maybe go to here. [c0wz.com]
Vertical
9 out of 10 men who have tried Camels prefer women!