On the Definition of a Hostile Network Connection?
"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?"
The Internet is a two-way medium, people forget that a lot. Some protocols make more significant use of that fact than others.
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.
--
And that would be bad because? Help me out here, I must be missing something...
If you ask me, identd is nothing more than a waste of bandwidth. Someone, please prove me wrong.
--
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
For years clueful IT people have been saying that end users should be more conscious of their security. Now that people are actually showing signs of doing this (albeit in a silly manner) they get criticised?
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.
Thanks. I really, really needed that image.
my favourite "you are hacking me" story is the guy who registered with the Linux Counter using an email account on his home machine, and then complained that I was hacking his home machine because I was connecting to port 25 every half hour....his email server was not turned on.
As a previous poster pointed out, I think this is most likely do to the boatload of personal firewall software out there. A lot of people who go buy Norton's firewall, use BlackIce, ZoneAlarm or whatever see that "A computer has tried to connect to your machine via FTP" and panic. I do deskside support and I get people who worry that they've done something "illegal" when they get the BSOD (no I'm NOT joking). The simple answer seems to be you've got people who don't know what the hell they're doing installing/using firewalls.
..
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.
I WAS reporting scans and probes of my networks on a daily basis.
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.
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.
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.
On one hand I'm GLAD people complain. I hope that more people are called on the table for what they do. Yeah, it can be a mistake - some people don't understand enough about networking protocols to debug what's going on.
.. 3.0.0.9
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.
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.
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." 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.
"...America's great minds of today, teaching America's great minds of tomorrow. Poor bastards." -- A Beautiful Min
And you thought you were being funny, didn't you?
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.
Want Root?
Yup, have to agree with you. Of course it isn't just bad admins, it is bad technology workers in general. I have moved into Network/System admin full time now, but last summer I had the fun of interviewing people for software development positions. I think I interviewed about 50 folks over 2 months, and there were I think 2 that we considered, and they weren't what I would call senior.
*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.
- 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.
After seeing the story about ESR's Zork/Adventure like configuration interface, I decided to see if I could find a Zork or Adventure server.
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
-- I don't have a cool sig.
What the AC says is true. and I don't think a 2 hour renewal period for dynamic IPs is unreasonably short, especially since a renewal only requires the exchange of 4 or 5 packets. The truth of the matter is that administering any kind of firewall competently requires more understanding and effort than MOST ISPs lusers want to invest.
... (SOME pro this is ... ). She refused to believe the firewall was the problem until I had her disable it and check her mail. Surprise ... it worked.
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.
utter rubbish
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_
_O_
.|< The named which can be named is not the true named
What, me worry?
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...
"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
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 if you don't get the joke.)
I think Admins who jump at this type of traffic need to read TCP/IP illustrated guide, because it demonstrates a lack of understanding of what their logs are saying. If you don't understand that book, you should not even bother monitoring the logs or being an Admin in a tcp/ip networked environment for that matter, anymore than an iliterate man should be a proof reader. My 2 cents.
Show me an effect without cause and then I'll believe in chaos.
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....
Over the past few years, I've had the opportunity to interview quite a few folks for the position of network and system administrators.
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.
I had sent an email to my wife and mistyped her address.
The default page in the Debian Apache package contains our logo. As a result, we are regularly accused of defacing Web pages when someone bungles a configuration change. I wonder how often time-A.timefreq.bldrdoc.gov gets accused of "attacks" as a result of the default configuration of my chrony package.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
It is not just the kiddies or fresh sysadmins full of self-importance who are stressing over this stuff.
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.
With each breath in, a flower somewhere opens; with each breath out, a flower withers away. In between lies beauty.
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)
-- Another senseless waste of fine bytes.
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.
-- Another senseless waste of fine bytes.
Well, I'd start here.
and then maybe go to here.
Vertical
9 out of 10 men who have tried Camels prefer women!
72 CD D7 52 D0 7E D8 47 44 91 D5 84 D1 59 F1 A9-This is my 128bit integer. There are many like it, but this one is mine.